Steve,
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.
Nolo contender, but I may be running out of words. I think the observation
Crocker made was valid, even if the words may have been looser than
was desirable. Would you like to offer a better characterization of this
issue?
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.
Forgive me for not having read it recently, but would this bar my email
processor or stand-along PEM filter from displaying a banner or other
indication of the default PCA (and perhaps acceptable DNs), and flagging
all others on an exception basis? If so, perhaps we should consider trying
to state the intent to positively identify the originator and the PCA in
the standard, but not dictate the "Look and Feel" of the human interface.
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 you 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.
I don't mean to quibble over word usage, but I don't regard what I have
been talking about as access control in the usual (Orange Book) sense.
Obviously an encrypted message offers a form of access control in some
sense -- if you don't have the designated user's private key, you can't
meaningfully access the message. PEM clearly doesn't offer Mandatory
Access Control based on security labels and levels of clearance, but
I think it can reasonably be used to implement a form of Discretionary
Access Control.
However, my primary concern is in the area of integrity and
trust, and here the Orange Book doesn't even mention the construct,
never mind defining useful terminology or techniques.
Somehow "Discretionary Belief Control" sounds too Orwellian, but
it at least gets the idea across. How about "Discretionary Integrity
Control"?
Again, since we don't (usually) talk about integrity clearances or
certification, I don't know whether we can talk about Mandatory
Integrity Controls in the usual sense of implementing rule-based
systems. But my attempt to confine my default granting of trust
to those users who have signed appropriate affidavits or otherwise
taken a positive step to assure me that their digital signature
actually MEANS something is one approach, and broadening this
to include a users group or Policy Hierarchy that endorses
such a mechanims is another.
I would be curious to know if MSP is capable of supporting such
concepts? Have they incorporate the AUTODIN Message Release
Authority function, for example?
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 lose 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.
I certainly hope and expect that PEM and the existing infrastructure
will be sufficient to support these kinds of applications. If I have
engaged ina certain amount of intellectual arm wrestling, it is only
to make sure that we really understand what we are talking about,
and as usual we have come up with ways of taking advantage of
the existing cpabilities to do new things. I admit that I still have
some doubts about the utility of the IPRA furnishing CRLs to all of the
PCAs throughout the world, but since I have no intention of offering
a PCA service I won't fight too hard -- I'll leave it to RSA and TIS.
By the way, would I be correct in assuming that we might see on the
of 5 or 6 PCAs per major country? (A Persona, a medium-security,
a commercial-security, a Governmental, perhaps a Notarial one, etc.?)
It seems somewhat, unlikely given the various laws of each country,
that we will be able to write meaningful Policies and contracts that
will work across borders, at least without a LOT of effort.