Policy-Discussion

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

Beware! Long message.

Before I get too much more involved, I should understand the model of the
current policy design! 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. One can register wild flower names, for all
they care, so long as one uses an architecture of registration that
satisfied the criteria.

----------


Reading the policy I learn

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 link to the certificate of incorporation, issued presumably by a
governmental authority, no longer resolves. 

1.3. The second paragraph is clear. Legal persons can be issued cert, and a
list of common types of such persons is provided. The first paragraph is
meaningless (so far). I don't know what a user is, or comprehend the notion
of an assured user. 

1.3.1. Decide on the term Certification Authority, or Certificate Authority.
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.

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.

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 service operated by CAcert Inc) or a reference to something else?

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)

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.

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 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.

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

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

2.1 implies that a root cert is not "issued" by cacert. This would require
audit investigation. A root cert is either a cert or not, and is either
issued or not. The original VeriSign CPS was not much better on this,
introducting the notion of "self-signed public key" to get around the
issuing problem for root public keys.

2.3 is very confusing, because certs and CRL patterns are distinguished.
Assuming one claims that a CRL is a mobile snapshot of a portion of the
records in the cert repository, that is issued for use/reliance, why would
publication of cert records be handled difference in terminology than crl
records? Certs are published as soon as "available". Available is not
defined. For example, is cert publication dependent on the subscriber first
accepting the cert? That is issuing and publication are distinct events,
designed that way precisely to allow a process of acceptance to occur (and
to be signaled implicitely to relying parties who can only rely post
publication - not post issuing.)

3.1.1 the naming schema and architecture looks ok. Im looking generally,
only - noting that the author clearly understands the need for rules in DN
construction, according to the naming authority subfunction of a CA.

3.1.2 is a bit worrying. Meaningfulness was meant to be a way of reference
the assurance standards of others, even if the CA/RA used its own scheme for
verifying the identity of subscribing users.

3.1.5 introduces the notion of DN expiration or revocation - this would be
an audit red flag. There would be a big wooptedo about the role of the NA
subfunction within the CA, and which set of accuracy claims dominate - the
DN records, or the cert records.

3.2.1 would be a killer red flag.

In 3.2 generally (addressing "'Verification' of identity" there is a
replacement of the term verification for authentication. One would now spend
a fair amount of money educating the auditor about the term switch between
the template and the policy. Auditors love this excuse to charge. They do
nothing, but get paid to listen to denotational analysis.

3.2.3 the language is unclear. There seems to be an exception to the claim
that trust information is not published. But I cannot understand it. I do
believe that the notion of :level of trust: is metricated as trust points. 

3.3 doesn't address the topic. It states what the initial issuing period is.
It doesn't say what happens upon natural expiry.

3.3.2 needs refinement. Upon new authentication (aka identity verification
in PKIX terms) post revocation, can a user obtain a cert with the public key
that is present is a revoked cert?


OK that's enough first impression analysis, for now. The policy is readable.
But its not auditable (at reasonable cost). 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. 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. Just audit the root key
function. 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. 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.