I suppose like many, I entered into the practitionar part of the
Open Systems security field only since a sea-change - of only a small
number of years ago - which opened up this research area for all to
consider. I look into the area with the vigour of opportunity, rather
than any knowledge or understanding.
So, lots of high-level questions and anxieties follow - for which, Im sure,
opinions, at least, must exist :
What needs did folk consider themselves addressing when the PSRG/IETF
process of RFC production started? And what were the perceived
requirements for actual security and confidence for IPM services?
( Scanning pem-dev for the last 2 years, I have picked up the idea
that *real* privacy and security of mail is of paramount importance;
the state is not to know the content, at least within the bounds
of open literature on cryptanalysis, or unless it can get the users'
keys out of the hierarchical CAs by warrant or similar. I remember
a pressure campaign to counter attempts to insist that CAs would NOT
be legally required to maintain issued keys.
)
What does the IAB/PEM-WG plan/aim/expect the size of PEM mail UA and
CA community to be? In what sort of timescale? (I once had the
impression that there would be 1 TLCA, 3 PCA, and a large number of CAs.)
One recent PEM-oriented (draft) report into the area predicts that
"eventually" circa 20 PCAs in 50 different countries (total 1000) will,
with the organizational aid of a number of TLCAs, serve different
communities at differing levels of assurance (though without any
justification for this prediction.) Does this conform to
expectations of scaling and size?
It is clear that users will have, under such an operational scheme,
possibly multiple certificates. By communicating with parties
certified under the same TLCA/PCA, communicants will be able to "know"
their own confidence in the keys, and thereby the security of the
interchange.
But what happens in the contrary case? - where users are in different
assurance domains? What confidence should they have of that same
security? While PEM-UAs do avoid the need to project
certificationPaths to Users as Steve Kent recently reinforced, will 2
arbitary PEM-UAs be required instead to inform their users of, and
otherwise manage, the assurance/trust possibilities of the operational
assurance "environment" in which the communicants are actually
working?
I can imagine that two communicants who have a real need to interchange
securely will take measures to negotiate the minimum mutual assurance
level they require, then exchange the appropriate certificates issued
probably by the same CA, or PCA sub-tree, or TLCA sub-tree. But even I
know that this is an example of a closed domain - whose technology and
security procedures needed to satisfy security requirements is already
well understood. But this is the special, rather than the general case
which heterogenous open systems must always address.
My concern is that PEM originally strove to avoid all this; in moving
the policy design towards PCAs and then to multiple TLCAs, these
problematical interworking-assurance issues all come flooding back. Or,
"transitivity" by the back-door. Not transitivity of unbounded
cross-certificates enabling rouge CAs to create total security chaos,
but rather transitivity, within the CA o PCA o (TLCA o TLCA) o PCA o CA
assurance "relation" in which I, the user, have no reason to believe
that, in general, any of the TLCA/PCA, PCA/PCA, PCA/CA certification
functors was well-carried out, or continues to be maintained according
to the published word-policy!
I understand that PCAs can certify any CA, as can any TLCA certify any
PCA without hierachy of naming constraints. Isnt *this* a general
trust/assurance graph? If so can the community afford the DN
management requirements which PEM makes and requires, given that
certainly this latter issue is mega-contentious. (remember Stef's remarks at
Cambridge IETF.)