Policy-Discussion

["Peter Williams" <home_pw AT msn.com>]

> 
> Are you on IRC (irc.cacert.org#cacert), ICQ, Skype?

I can resubscribe. Perhaps the peer-peer trading model has evolved beyond
the initial sex driver of novel infrastructures, in much the same way
VeriSign certs evolved beyond addressing the early adopters of SSL (the sex
sites) after a couple of years. 
 
> > While the browser companies require audit, they do
> > not require that there is any particular identification or assurance
> model
> > - that the management's model meet the WebTrust or _similar_ criteria
> for
> > such models is all they care about.
> 
> They do require it nowadays, I don´t think that you will still come away
> with
> that today.

OK. I'll look at the modern webtrust criteria. I have not reviewed it in 2
years, or more. I'd be surprised if there is a specific naming or
identification model: this would required standardized tests. If Webtrust
was able to create a public accounting standard which solves that problem
across the 52 US states, they will have created a miracle that has defeated
lot of other initiatives! 

Last time I heard, whether you are actually married or not, in the US,
depends on the state the relying party lives in; and thus a married female's
name change is valid and not valid at the same time. This make a common
identification model very hard to establish, uniformly.


> 
> > One can register wild flower names, for
> > all they care, so long as one uses an architecture of registration that
> > satisfied the criteria.
> 
> I wouldn´t say so.


> 
> > First, that a DoD institution has listed CAcert Inc with a number in its
> > listing tables. I happen to know that this is supposed to be an
> > institutional listing. The quality and accuracy of the listing is
> unknown,
> > but, its subject to US export rules (being a DARPA/NSF funded registry).
> > The policy should reference the naming policy of any authority upon
> which
> > it relies. I.e. point to the DoD/Internet RFC on that OID tree's
> > registration principles.
> 
> The OID´s are a global scheme. I don´t know at the moment, who invented
> it.

Oids use the primitive names architecture. I half remember (from 10 years
ago) that it was in the X.200 series from CCITT. It was the only part of
ISO/CCIT standards that Steve Crocker (author of RFC 1) ever said something
positive about, re X.509.

> They are mostly used to identify algorithms and certificate
> CAcert just registered the OID for CAcert, and can use any structure below
> it,
> but nothing of it is needed yet. (We didn´t invent any new certificate
> uses
> yet)

Hmm. But that particular IANA registry is for institutions - not cert
usages. Last time I checked, the PKIX registry for cert usages oids was
controlled by Russ Housely, personally, not IANA. (Russ is a long term NSA
contractor.) The IANA arc was originally defined to allow registered
institutions to define their own MIBs, in SNMP. But the real question is, to
an auditor given we have cited the value is: what checks did IANA apply
before assigning the primitive name (CACert oid arc)?

> > The link to the certificate of incorporation, issued presumably by a
> > governmental authority, no longer resolves.
> 
> Ah, you mean that link:
> http://www.cacert.org/index.php?id=35
> And that one:
> http://www.cacert.org/legal/incorporation.jpg
> 
> Ok, we will restore and refresh the links soon.


Good. Whether an organization is set up to be a CA, in those articles, is
audit relevant. It's not a necessary element, but is audit relevant when
assessing the management team's real involvement in the goals of the CA
service function. Such a property can _avoid_ the need for the board of the
institution to specifically empower the CEO (or equiv) with responsibility
for enforcement of the security policy, that goes alongside with the policy.
If the articles do not specify CA specific functions, one needs to test that
the board of the institution is really in control, on this issue.

(As CACert is a small non-profit, this may be easier to accomplish, than for
most companies, where obtaining a formal and suitable board level minute
takes a small act of god).

> 
> > The first paragraph is
> > meaningless (so far). I don't know what a user is, or comprehend the
> notion
> > of an assured user.
> 
> I am a german native speaker, and unfortunatley my english isn´t perfect.
> Could you try to explain, what exactly you mean?

The terms "user", "Relying party", "subscriber" are terms-of-art in the
commercial CA business, that MS is now addressing to further the MS Platform
Who is and who is not a "user" is relevant. The auditor will use std terms
of art to understand the technical terms used in the policy - mapping any
local technical terms onto well understood terms. So, when one uses a
technical term like "user" it needs to be very clearly used. Perhaps one
means something general (like website visitor), or its legally defined in
terms of the PKI model.

In general WebTrust auditors will use such as article 11 of
http://www.uncitral.org/english/workinggroups/wg_ec/wp-84.pdf for the notion
of reliance, and will carefully whether the term "user" means those who
possess an authorized signing device (See other article), or whether any
person may be a user who uses non-authorized signing devices to process a
cert - upon which they may rely or not. In some policies, a CA is itself a
user; in others, its only a relying party. Whether the policy intends IE
/Mozilla/Opera manufacturing companies to be a user or a relying party is
legally and thus a critically audit relevant disclosure. 

One should inspect the acceptance rules of the those companies in whose root
key stores we wish to deposit our root key - for use (or be potentially
relied upon) by those who create SSL, IPSEC, PGP crypto sessions. Then tune
the policy to suit those acceptance rules. An intent to have such
manufacturers rely on the cert, when they specifically don’t rely - as part
of accepting the root key - is an audit red flag, on the ground of
inconsistency!

Has anyone actually read the MS contract for root key inclusion, yet?


> (Did you took a look at the glossary at the end?)

Only later. I didn’t know there was a glossary at that point. It had not
been noted in any introduction. (Yes, I'm being a literalist, acting just
like the auditor will initially act). DO we want to spend 1h at 200USD/h
while they tell us to put a note about the glossary in the Introduction?
They will, quite happily, charge for that review, the notification to us of
this, the re-review service, and the writeup of notes to show management
responded to the auditor advice. Or, we can get it right, and avoid the
"game" that the audit companies will play, to generate revenue?
 
> > 1.3.1. Decide on the term Certification Authority, or Certificate
> > Authorityl. Don't mix, and flip flop between the two: makes the document
> > look silly. Either capitalize Authority, or don't, consistently re the
> > section title.
> 
> Ok, agreed. Which style would you prefer?

Don’t care. Use the X.509/PKIX form, seeing as we are acting in the Internet
space. All I care about is noting consistency. Otherwise, its another
200$... while they tell us to fix it.


> 
> > 1.3.2 a clear legal relationship exists between CAs and RAs. It exists,
> via
> > a clear assertion. I don't know what it is, but it is extant. The notion
> of
> > "runs" suggests that one who relies upon an RA is entitled to claim they
> > are relying upon the CA in that same respect. That is, a CA has implied
> > duties to the users of the RA's services.
> 
> Could you explain that too?

I was noting my simplistic interpretation of what the policy states, for
each major topic area in the PKIX template for policy disclosures. 

I'm noting, like the Auditor will, that there was a very specific legal
relationship disclosure, between CAs and RAs. This policy is unusual: rather
than distance the CA from the acts of RAs (by creating non-agency relations)
this policy discloses that the CA is infact "Running" the RAs. This is very
relevant, and will be audit discussion topic. The businesss control the CA
now uses to ensure the RAs (that it runs) uphold the security policy etc
will be investigated. IF I were designing the audit tests, I would now ask
the obvious: hmm CA cert uses certain technical security measures on its
PCs, and "runs" the RAs, who probably use PC...so, lets test how the CA
management _ensure_ that the RA's PC are operationally at the same security
level as those PCs in the data center of the CA. Etc. After, all this is a
corollary of the disclosure, as far as Webtrust is concerned: and is thus
within the testing scope.

Whats the point? to audit the CACert, with this policy, creates the
obligation to now go and test a sample of the RAs. I.e. Add Cost, n * the
number of RAs used. If The RA is in Mongolia, add lots of travel cost, if
the auditor selects them as the test subject... 

Otherwise: redesign the policy, and its disclosures, to scope the audit, and
control the costs.


> (I don´t quite understand, wheter you give a general statement, do not
> understand something generally, or want to show us some specific problem
> in
> the Policy)
> (I´ll try to read it again tomorrow, perhaps I will understand it then)


In general, I made a first reading, noting what each disclosure point said,
as a person who has read many such policies, and can discriminate between
what they such policies actually say, technically. 

View the comments as they were intended: let me identify the issue in the
the section - just as an reviewing auditor will identify and seek
clarification on. And, as above, we can see what kinds of audit tests will
follow, by virtue of the disclosure and the issues that the disclosure
address. 

When designing policies, one need to carefully thing about controlling the
tests the auditor will apply, to establish whether the operations actually
meet the policy disclosures. Choose inappropriate business ad practices
disclosures and (A) costs skyrocket, (B) one can cause the auditor to reject
the assignment - as its impossible to adjuge the policy as conforming with
the (Webtrust) criteria used in the evaluation.

Bottom line: understand webtrust criteria, and the way the testing regime
works: work backwards when designing the policy.This doesn’t mean one has to
lose the novel and innovative constructs and models of this grassroots
enterprise! it just means: express them in std form.

> > 1.3.3 is very confusing. In subscribers (which we intended to mean those
> > who perform the legal act of subscription to a record service) we have a
> > listing of types of certs, that a CAcert issues. In not sure what CAcert
> > is, yet. Is the CA (a servi you ce operated by CAcert Inc) or a
> reference to
> > something else?
> 
> I think we should discuss that more directly, to clear those things.

Explicit reference to the subfunctions of a CA is advisable. There is its
policy management function, its security policy enforcement function, its
naming authority, its records management authority. While one is not
required to use such formalism: using it simply makes the audit much
easier...as the controls per function are delineated, and thus easier to
test, find the person responsible, test their cognizance of the
policy/practice rules, their technical formation in such a role, etc.

Again, note the experience talking.


> > 1.3.4 introduces the notion of "product", in its definition of reliance.
> > This is unusual: a certificate (by virtue of the required act of
> > subscription to a records authority) is normally the tangible embodiment
> of
> > a service - its not a product in its own right, and does not exist
> > independent of the issuer or the records system. Its merely a reference
> to
> > a listing in the cert repository, maintained by the legal records
> > management authority (a subfunction of the CA) (This feature is crucial
> to
> > the VeriSign CPS, note, and much of the legal value derives from
> > subscription jp)
> 
> Ok, I think I have understood that. Could you go into more detail?

Don’t define certs as products. Define them as a service. When a person gets
a cert, they are really just getting a (legal) reference back to the
management SERVICE, that CACert operates.

At a later stage, we will discuss the absence of a "relying party agreement"
in the policy disclosures. Much of the rationale for the use of service
legalisms is that it enables the CA to control (legally) those who may use
and those who may rely - and who may not be subject to a contract. The
auditor picks this up quickly (thanks to the VeriSign tutoring the world on
the topic), as it represents unaccountable liability risk for the CA. This
it relevant, because it begs the question: is the CA financially able to
continue business, if its sued, etc by someone who relies, but for whom
there is no contract controlling the legal risks....

Webtrust audits are tough. They turn you inside out! Lots of parties have
failed (having wasted 100k, learning they were unprepared, or incapable to
revising the rest of the company, to match the required security posture)


> > 1.4. CPS, vs CA policy, vs certificate policy. These terms seem to be
> using
> > with abandon, and not precisely. I sympathize, but its needs better
> > lawyering - one cannot introduce yet more confusion.
> 
> Hmm. To tell the truth, I also haven´t understood the exact
> differentiation
> between those yet. (I am not a lawyer, and I am not an english native
> speaker)

Best summary I can muster: 

CPS cover the practices SYSTEM - the operational security practices
(business controls, in auditese) the *Organization* shall use to satisfy the
rules of its cert policy. These include legal controls aswell as more
conventional security policy controls, for: physical security, personnel
security, logical, key management, records retention, business continuity,
disaster preparedness, IP and copyrights, sale of assets, etc, etc. 

Cert policy refers to the PKI system itself: how a TTP (in the PKIX sense of
the term) controls the behaviour of its subscribers, users and relying
parties so the PKI system itself has the assurance folks expect when sending
private banking data to their current account at the online bank.

CA policy is an unknown term. It may refer management disclosures about its
activities. It may represent, for example, management's assertions about the
corporation's compliance with the CPS and cert policy. Who knows!


> > 1.4 seems good in essence - definition a notion of appropriateness, and
> an
> > explicit prohibition regime. This is consistent with the doctrine of
> > usages. This is not to say I understand the rules, or the rationales.
> But
> > the policy architecture for usage definition is ok.
> 
> > 1.5.5. implies that the document is intended to be contractual - i.e.
> its
> > constructs are intended to be terms, that are "legally binding". Thus,
> the
> > document needs to satisfy good lawyering standards, for starters.
> 
> > Reading the definitions in 1.6, I still don't know what an CAcert
> assured
> > user is. The pattern user -> unassured user -> subscriber seems good a>
> though. (Although one is technically already a subscriber (to a non cert
> > record), once one has achieved unassured user status).
> 
> 
> > We finally get a definition of CAcert assured user, which unfortunately
> > refers to an undefined construct "registered user". Perhaps it fits
> between
> > unassured and subscribers, in the pattern. You visit, you sign up
> (register
> > and subscribe), someone updates a controlling assurance record, you
> > request/receive a certificate, and subscribe to a specific record (the
> > cert). This pattern is sound.
> 
> A "user" can surf the we bsite, and decide to register, and becomes a
> "registered user" then. The identity of a registered user is not verified.
> Then the user can become assured by meeting an assurer, showing the
> documents,
> and becoming an "assured user" that way.
> 
> Everyone can become a subscriber, who relies on a CAcert certificate

A subscriber to what? "can become", or "is"? These are the disclosure issues
that auditor will first ask about. Without having ever visited the website
in any sense can an S/MIME user "use" or rely upon the cert, offline, and,
is said user a subscriber, or not by virtue of THIS ACT? Conventional logic
says no. Said user would probably, say, well, I never sign up to anything.

Now, if I were a webtrust auditor, reading the policy, and learning this
intent about subscription from the management team, I would now investigate
the reliance policy - to assess the risk the corporation is under from such
relationships - which are non contractual, and thus open ended. I would ask
the team, to show HOW they are bounding that set of risks, given there are
an UNLIMITED number of such parties, and thus infinite financial and legal
risk. There are various reasonable responses - contracts are not the only
form or risk management: knowledge of them, is what Id be testing,
essentially. Assuming one showed knowledge, then Id ask "so why is it not in
the policy disclosure!!?"

Hope this helps.
> 
> > Notion of relying party is very strange. Legal reliance goes beyond use
> of
> > static facts, addressing the purpose for which the representations were
> > made.
> 
> Please explain.


Read the UNITRAL notion of reliance on a cert, cited above. It’s a well
discussed piece of legal reasoning, that is designed for you and me to read.
Asserting in a policy that a cert is nothing but a fact has copyright and
other legal implications. But, a decent auditor will test whether its really
true - that the cert is but a fact - as this very (legally technical) topic
was debated, and resolved in the industry, by many PKI specialists and the
UNITCRAL team creating a model law for international e-commerce. (Note,
CACert seems to on the losing end of that debate, from my reading, and this
is ripe for a big set of audit tests on this topic... (i.e. $$$ to the
auditor, lots of fees to CACert legal counsel for legal research...))


> > CAcert cert redistributor is really better handled as a special class of
> > relying party.
> 
> Why?

The policy seemed to disclaiming the Microsoft/Mozilla Foundation, Opera
Foundation, etc as a member of the PKI: subscriber, relying party, user, or
(intermediate) CA. That is, it seemed to be saying that they are not
representing anything to their licensees, by virtue of the inclusion of the
root key in their stores. This is not the case (for Microsoft Corporation). 

By asserting that such parties are relying parties (who rely mostly on the
Webtrust-verified attestation by management), we are clearing up just who is
going to be really using the results of the audit. This is of BIG CONCERN to
the audit community, who will charge by expected intended usage of the audit
results.



> 
> [...]
> 
> 
> > OK that's enough first impression analysis, for now. The policy is
> > readable. But its not auditable (at reasonable cost).
> 
> Ok.
> 
> > The auditor would
> > first charge an arm and a leg to get it in the form that they would
> > subsequently be willing to design tests of practices against.
> 
> Luckily that will not happen. :-)


Well so far, they will be licking their lips: Hoping CACert is yet another
unprepared CA that signs up for $50k of initial policy rewriting service,
and then opts out (losing 50K of value, because the process does not finish)
once they understand just what they were getting into. This is easy money
for the Big5 audit firms. Pure consultancy revenue, and zero liability. The
love these assignments.


> > An auditor
> > that does not insist on a major rewrite is not worth hiring, note.
> > The
> > first test of reputable audit standards is that the disclosures meet
> > documentation standards, per se. In this way, the auditor's peers can
> > evaluate the auditors own work quality, in reasonable fashion and two
> > auditors would reach the same conclusions, given the same evidence.
> 
> 
> > To proceed on the root key audit, one need to separate the CA function
> for
> > root keys/certs, and the CA function of CAcert.
> 
> Since CAcert only has one root key, and directly issues under that key, I
> am
> not sure, whether the policy really should be splitted.


Its arguable, and require detailed negotiation with the auditor, when
setting up the assignment. Some will, some will not accept this. For some,
its too small an assignment for such specialized staff, and they will walk
away.


> > Just audit the root key
> > function.
> 
> Why only the root key?

Because the set of management controls that need to be in scope is small,
and thus the set of audit tests is small, and thus the fees are small.

As the goal is to get the root key in MS browser, one FOCUSES and scopes the
assigment, to address the goal.


And, let me be blunt: no BIG5 auditor would even touch the rest of the CA
function. Its not worth the risk, being on the innovative end of policy
design. We *might* get the root key matter handled, though, if the
assignment was professionally negotiated.

There is one webtrust auditor, I know, who likes the innvotative end of CA
policy. And s/he might give us a look - BECAUSE its not just the same old
crap. But I would not waste the introduction, yet. S/he has to apply the
core standards first, and so far, we would fail, and waste an unique
opportunity.



> > There is NO NEED to include within the audit scope most of the
> > CACert function - just the root key CA, and its policy of issuing
> > intermediate certs.
> 
> Why?

Hopefully I made my recommendation and its rationale clearly, above.

 
> > CACert can be one licensed CA, of the root key
> > authority. Hopefully Im being clear: CAcert subscriber/user activites
> need
> > not fall within the set of management assertions that CACert Inc wishes
> to
> > represent to the auditor.  Just audit the root key authority, and write
> a
> > small custom policy for that function, formally separating the two part
> of
> > CAcert Inc.
> 
> I am quite sure, that the audit would have to include both the rootkey and
> the
> CA function, so I don´t think that we could gain anything by seperating
> them.


Ok. This is a fair position. I hope I made my of policy design and CA root
key audit experience available, and let it guide folks as they see fit.


-----

Next topic. So what's the state of the security policy documentation?
Assuming we got the policy together and auditable, the next big hit on time
is the definition of the business controls for all the usual areas of
operational security for IT Service company (enhanced considerably, because
of the very nature of a KMI CA!).

Unfortunately, this is where Webtrust criteria are less than perfect. One
needs to select an auditor that will willing to adjuge the operational
controls in light of the nature of the business.

If the business is to issue server certs that the MS browser user cannot
effectively distinguish from established CAs (like VeriSign, Go Daddy, etc),
at that point the auditor is likely to required similar levels of
operational security as VeriSign, etc.

Whilst this is a practical goal for CACert, for a limited scope function
like root key management, its REALLY hard (and expensive) for a whole CA
function spread across the Internet, on multiple IT systems. I'm not sure
what the resolve and resources of CACert are, here. But, Ill no doubt learn!
 
Best Regards!

Peter.


> Regards,
> Philipp Gühring
> 
> _______________________________________________
> Have you subscribed to our RSS News Feed yet?
> 
> CAcert-Policy mailing list
> CAcert-Policy AT lists.cacert.org
> http://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy