Peter Williams writes:
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.
)
I've always construed PEM as addressing a pair of dual goals: (1) that an
originator should be able to generate a message in such a way that only its
intended recipients can extract its content, and (2) that a recipient should be
able to determine that a particular originator and no one else sent a message.
MIC-ONLY and MIC-CLEAR messages provide for cases where only (2) and not (1) is
desired. Within the CA-based public-key model, and independent of whether CAs
are structured hierarchically or otherwise, there is no requirement that CAs
hold the private keys of the individuals they certify.
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.)
The only number fixed by the current architecture is that there's 1 ICA; the
term "TLCA" is obsolete. The design center assumption is that the number of
PCAs will be relatively small and the number of CAs relatively large, but the
architecture allows the actual numbers to adjust as a market develops.
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?
I don't see any technical reason why a single PCA can't serve subscriber CAs in
multiple countries; if this is politically achievable, it would help to
contribute to the desired one:many PCA:CA fanout.
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?
A goal of the PCA-based architecture design is that PEM-UAs are always able to
determine when a PCA boundary is crossed in the course of validating a
certification path, and no PEM-legal path traverses more than two PCAs. Since
PCAs are to register documentation of the policies they enforce, an interested
user can always determine the policy (in the local PCA case) or policies (in
the inter-PCA case) applicable to the validation of a message. If the number
of PCAs remains relatively small, individual users won't have to be exposed to
so many policy statements as to be snowed. I think this represents a
reasonable compromise between a desire for universal connectivity without
prearrangement on the one hand and a desire for knowledge about applicability
of adminstrative policies on the other.
--jl