To: Steve Kent <kent(_at_)COM(_dot_)BBN>
cc: P(_dot_)Williams(_at_)uk(_dot_)ac(_dot_)ucl(_dot_)cs,
pem-dev(_at_)com(_dot_)tis
In-reply-to: Your message of "Wed, 11 Mar 92 10:18:00 EST."
--------
>From: Steve Kent <kent(_at_)COM(_dot_)BBN>
>Date: Wed, 11 Mar 92 10:18:00 -0500
I spent all day Thursday talking to European nations' National Research
Network Managers(Assistants) at the EEC about the impact of secure
X.400(88) piloting upon their resources and operational procedures.
Some of PEM-DEV know of this group as RARE WG8.
The major Euro-OSI/Internet philosophical split on the issue of naming
is clearly also having consequences upon our different bases of design
of certification profiles and procedures to X.509 with consequent
impact upon the potential of X.400 UA-UA security services subset to
interwork/gateway with PEM, whilst continuing to provide legal
notarization services via non-repudiation of origin security service.
I argue this however no more, as this is not a discussion forum.
I do feel useful by abstracting and commenting on the conseqeunces of
all the salient points of your reply which substantiate the above
statement. This is done to assist the RFC commenting process.
Peter Williams
-------------
PEM provides a service facilitated by the "CA DN conflict avoidance
databases."
An entry in either of these databases indicates an intent to issue a
certificate by a PCA or CA.
The database is such that it will NOT accept duplicate DNs with
identical public keys, so it enforces "some" level of DN conflict
resolution, although the real responsibility is that of the PCAs or
(PW:) residential CAs.
Such databases are accessed only by PCAs and residential CAs, not by
ALL CAs or by ANY users. Consequently query load does not affect
seriously the performance of a centralized database. PW: Consequently,
the number of residential users on whose behalf access is made to the
database in order to indicate an intent to issue a (multiple)
certificate is qualitativly small.
Once any <naming> conflict is resolved, the residential user can be
certified (ie. issued with a certificate) and an entry made for him in
the database. PW: The certificate is issued before database update;
therefore the database does not constitute name-certification unless 1)
it is trusted, 2) it serializes query/updates on a name to ensure no
multiple update of identical information, as required by X.509/6.3 in
support of non-revocation of origin. Such certificates are thus also in
technical violation of X.509.
PW: Authenticity, as a less strong and not-legally-notarized signing
process, can be throught of as ensuring the uniqueness of {name,
public-key} pair. The above database appears to have this objective
primarily in mind.
The uniqueness of the names of organizational users and subordinate
organizational CAs is ensured by the DN subordination rule of the ICA
policy. PW: PEM considers the process of verification of entitlement
to use DNs to be an offline process to (offline) CA services.
Logically, also when verifying subordination of name. PEM RFCs
explicitely recognise the security design requirement of ensuring (all)
DN uniqueness.
PW: The access protocol to the database uses Message Transfer
services. The MTS and Database UA will be trusted for secure
delivery.
Conclusion: PW: I fail to be convinced that the database mechanism will
certify the uniqueness of DNs. I do not believe the above abstracts are
even attempting to assert this fact. However, this requirement
underpins the non-repudiation security service. If the PEM design can
be evluated to the secure by re. providing trusted UA for the
databases, then I feel (but only intuitively) that PEM authenticity
services are provided for by this means, by virtue of the provision of
avoidance of {name, public-component} duplicate pairs.