Bob,
Some comments on your recent message:
While we are thinking of better terms, I do like the
explanation Steve Crocker offered for "syntactic"
vs. "semantic" than cross-certification. It has seemed
to me that the IPRA is performing a type of syntactic
cross-certification, but that there is not yet any
effective or agreed-to semantic content to the
certificates.
I argue against Steve Crocker's "semantic cross-certification" because
the underlying mechanism available in TISPEM has nothing to do with
PCAs certifying one another in any fashion. The mechanism allows a
user to acquire a set of PCA public keys, e.g., by some out of band
means, which means that none of the PCAs is involved in certifying any
other PCA at all. This has nothing to do with cross-certification of
any sort, and thus using the term "cross-certification," even with some
sort of qualifier, is misleading.
The following thoughts occur to me as a result
of your (Kent's) comments:
1. I can affix a pejorative label "Bad Guys R
Them" to any PCA I like, as a local matter,
whether or not I have confirmed the bad guys'
certificate or not. The IPRA does provide
some value here, by at least confirming that
I am blacklisting the right ("wrong?") people.
Yes, that's right!
2. I don't even have to display any DN or PCA
policy name at all -- I can just let the good
ones go through and reject the bad ones. So
mail-based application programs can operate
automatically, with minimal intervention.
An application, rather than interpersonal email, could take this
approach using ACLs. A PEM-compliant, interpersonal email application
does need to display some form of ID for the PCA and the originator,
as per RFC 1422.
3. The default can be to label all PCAs as bad
guys, and add individual PCAs as good guys.
This tends to bring us back to the HOSTS.TXT
approach, but there would probably only be
two or three entries in the table in most cases.
That is an acceptable burden.
Yes, this is a typical approach to access control, i.e., start with an
empty list and add the folks you authorize.
4. I can define all CAs as bad guys for the purpose
of encrypted communication, so that I don't
accidentally send an encrypted message to the
wrong person or company do to a mistake in
addressing, and then add individual CAs or even
individual users to the permitted list, for example
if my company is teamed with another company
that might normally be a competitor.
If yor made use of access control on outbound messages, this would
work. I observed earlier that PEM explicitly states (in 1421) that
access control is NOT an offered service. MSP does offer rule-based
access control, and it offers various means for building mail relays
that enforce rule and/or identity-based access control using the
sender's or workstation's ID or authorization as a basis for an access
control decision. MSP was designed for a different environment and
thus makes explicit provisions for different security services.
For example, if the President chooses to implement
a local policy for White House staff that prevents
encrypted communication with someone who
refuses to adequately identity himself, e.g.,
someone certified under the Persona PCA,
(not an unreasonable policy, I should think)
that would not prohibit someone who is certified
under the Persona PCA from receiving and
authenticating a digitally signed message from
President(_at_)WhiteHouse(_dot_)GOV(_dot_)
I'll avoid commenting on the policy aspects of this proposal, but one
could construct a system that would effectively limit the ability
of users within an organization to communicate with users outside,
although MSP is better suited to this than is PEM.
Did you get that backwards, or am I misreading you? It certainly
seems that PEM is structured to support identity-based systems,
if anything. I'm just trying to improve the level of trust in the
identity mechanism.
Whoops! yes, I got the statement backwards about IBAC and RBAC.
<lots of omitted text>
Bob, I think it would be fine for you to develop the system you
described, with affidavits, notaries, etc. It is clearly an
application that goes well beyond what PEM aspires to, but PEM and the
certification infrastructure may still provide a building block for
your more elaborate system. I don't know if it is appropriate to
address the issues you raise about that system on this maling list.
However, I don't think it is appropriate to modify PEM in ways that
cause it to loose existing functionality that may be of interest to
the general Internet community, in order to support the specific
application you envision. I hope that PEM can provide a basis for a
wide range of "mail-enabled" applications, but there may be
limitations on how diverse a set of applications we can support
without undulying complicating PEM or undermining its essential
features.
Steve