Skip to Content.
Sympa Menu

cacert-policy - Re: [CAcert-Policy] Policy on Organisation Assurance -- work-in-progress

Subject: Policy-Discussion

List archive

Re: [CAcert-Policy] Policy on Organisation Assurance -- work-in-progress


Chronological Thread 
  • From: Jens Paul <cacert AT canyonsport.de>
  • To: Policy-Discussion <cacert-policy AT lists.cacert.org>
  • Subject: Re: [CAcert-Policy] Policy on Organisation Assurance -- work-in-progress
  • Date: Sat, 15 Sep 2007 11:40:30 +0200
  • List-archive: <http://lists.cacert.org/cgi-bin/mailman/private/cacert-policy>
  • List-id: Policy-Discussion <cacert-policy.lists.cacert.org>
  • Organization: CAcert Inc.

Hi,

>>
>>> OK, so let's work through that from a policy perspective.
>>> Can you define high-risk organisations?  
>>>       
>> I currently would say Fortune500 (but applied not just for american 
>> companies, 
>> but also to all other areas of the planet, and to all other kinds of 
>> organisations) + larger Financial institutions
>> Another way of definition we could try is "Well-known trademark"
>>     
>
>
> Hmmm... I would have said those involved in finance and
> ecommerce.  But I guess we wouldn't be able to define it in 
> the policy, right?
>
> So the best that could be said is "OAO defines a high-risk 
> profile."
>
> Then, high-risk of what?  If the answer is ecommerce, then 
> the CPS grumbles about that, and the line has always been 
> that identity is assurered, not motives & intentions.
>   
We can make a statement about "high-risk", but we shouldn't define it.
If we do so, me might get in trouble if something goes wrong ... like
"Why wasn't this defined as a high-risk environment? It has the same
characteristics as ..."

>   
>>> There is a difference between it being in a policy and in
>>> guidelines managed by the OAO.  If the issue is
>>> substantially subjective, gut-feel, then it could be in
>>> guidelines.
>>>       
>> Well, I guess we have to put it into the policy as optional, otherwise we 
>> might get problems when an OA wants to do such a visit, and the 
>> Organisation 
>> says that this isn´t covered by the Policy ...
>>     
>
>
> Hmm... that takes us back to the question of whether we can
> decline to assure someone.  With an individual, an Assurer
> can always just set 0 points.  Why would it be any harder 
> with a organisation?
>
> Is there a custom that an Assurer can only conduct the 
> checks permitted in policy?
>   
I think he can. We ask for document copies which can HELP us to validate
the data on the form. We do not say that it is the only form of
validation. If an OA decides to make a visit in order to validate data,
he could do it. If the company does not like him to visit them, they
have the right to do it. If then the OA says he wasn't able to 100%
validate it due to that situation, he just fails the OA request.

Whenever one has doubts, he has the right to decline assurance. As long
as our Assurers / OAs are individuals without employment at CAcert, they
will always have that right!

>>>> (And btw, I think I found another problem with EV here: The CA´s offer EV
>>>> optionally to their customers, they don´t enforce it for high-risk
>>>> customers.
>>>>         
>>> That would require a definition for high-risk customers ...
>>> and/or we might then be agreeing that the CA can define
>>> security for the customer.  
>>>       
>> High-Risk organisations are those that are willing to pay for EV.
>>     
>
> Well, that's a definition that the commercial CA would love 
> and cherish :)
>   
lol .... I would say: those who are willing to pay do (a) need something
we can't offer (like insurance, etc) or (b) they wanna make their lives
easier by having someone to point at.

>   
>>>> I heard that DNS Registrars are automatically enforcing additional checks
>>>> to high-risk domains. (There was a story once where I think Gmail slipped
>>>> through since the systems hadn´t classified the specific gmail domain as
>>>> high-risk, so the protections didn´t applied. But that was just a single
>>>> case, and in general those mechanisms work.)
>>>>         
>>> Right.  Adding additional checks is a good idea, if we can
>>> describe when and why.
>>>       
>> When: When we get a request for an organisation that is classified 
>> High-Risk
>> Why: To protect against advanced impersonation attacks
>>     
>
>
> OK, so what's the suggestion for a policy change?
>
>     "OAO can define additional checks in
>     response to emerging threats."
>   

Back to reality:

An organisation which we would define as "high risk" definetely has a
security audit, like ISO 27001 or BSI audit or whatever. One of the
points within such an audit is the relationship towards contractors.
Within that "relationship-definition" there is at least defined that (a)
Service-Level-Agreements (SLA) are in place with a a guranteed service
time and (b) the contractor is liable to a certain amount of money
(depends of the area his products are used in.
So, if a high risk organisation is considering doing an OA and using
CAcert certs (not adding the root key but using the certs!) the security
officer there is doing an extremely bad job and they will probably face
some severe problems in the future. And CAcert shouldn't be part of
those problems :-)

So, yes, that policy change sounds good, but we shouldn't define
high-risk organisations and how to deal with them.

Jens

begin:vcard
fn:Jens Paul
n:Paul;Jens
org:CAcert Inc.
email;internet:cacert AT canyonsport.de
title:CAcert Education Officer
x-mozilla-html:TRUE
version:2.1
end:vcard




Archive powered by MHonArc 2.6.16.

Top of Page