Re: A brief comparison of email encryption protocols
Mark S Feldman (feldman@tis.com)
Thu, 22 Feb 1996 18:49:55 -0500
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5434.825032983.2@tis.com>
> Certainly PEM mandated the use of X.509 certificates, and the flaws in
> the V1 version were thereby magnified and finally corrected with the
> V3 definition. If all of the time and effort that wne into the PEM
> discussions accomplished nothing else, that was still a notable
> accomplishment, for now we have an infrastructure that we can make
> real progress on.
PEM discussions and the development and use of PEM implementations
provided much knowledge. MOSS, S/MIME, and PGP have all benefited
from the lessons learned. I was attempting to point out to Raph
Levien, who wants more standardization with respect to trusting
certificates, that PEM did have standardization and it failed partly
because it was too inflexible.
> PEM did NOT mandate the use of a single, trusted root. Far to the
> contrary. It explictly acknowledged the need for multiple, independent
> domains of identity assurance, called Policy Certification
> Authorities, or PCAs, that would establish a standard around which
> others of a similar inclination could gather.
The following is an excerpt from RFC1422:
The infrastructure specified in this document establishes a single
root for all certification within the Internet, the Internet Policy
Registration Authority (IPRA). The IPRA establishes global policies,
described in this document, which apply to all certification effected
under this hierarchy. Beneath IPRA root are Policy Certification
Authorities (PCAs), each of which establishes and publishes (in the
form of an informational RFC) its policies for registration of users
or organizations. Each PCA is certified by the IPRA. (It is
desirable that there be a relatively small number of PCAs, each with
a substantively different policy, to facilitate user familiarity with
the set of PCA policies. However there is no explicit requirement
that the set of PCAs be limited in this fashion.) Below PCAs,
Certification Authorities (CAs) will be established to certify users
and subordinate organizational entities (e.g., departments, offices,
subsidiaries, etc.).
> But there never was ANY expectation that it would be possible to
> bootstrap "trust" up to the IPRA.
I think we may be using "trust" in different ways. By following a
certificate chain up to the IPRA, bindings between keys and the
subjects identified in the certificate can be "trusted" [1] to the
extent that you accept ("trust" [2]) the policy for the PCA that is in
that chain. My take is that you agree with the use of "trust" for [2]
and not [1].
> The IPRA served one primary and one secondary function. It provided
> a means of syntactically validating the public keys of the PCAs,
> thereby potentially easing the problem of providing out-of-band
> verification for those different domains.
Yes. This is the "trust" to which I was alluding.
> But there was never any requirement that a given PCA register with
> the IPRA,
Yes, there was. Multiple, disjoint hierarchies were an afterthought
and not included in the PEM RFCs, though some implementations, like
TIS/PEM, supported them. With support for multiple, disjoint
hierarchies, RFC1422 becomes a subset.
> nor were any guarantees ever made or even implied that the IPRA would
> enforce any notion of "trust" between potentially competing, and
> possibly even warring factions. I'm sure that to this day Jeff
> Schiller would be equally happy to register the KGB and CIA PCAs, the
> Mafia and the FBI/Interpol, macys and Gimbels, and the IRA and the
> English government, all in one great big happy
> family. Would that mean that they would be willing to "trust" each
> other, just because their keys were centrally listed and registered?
No, but they could all validate chains back to the IPRA (syntactic
trust, if you will). Whether or not they would "trust" the end user's
certificate would also depend on the policy of the PCA being used
(semantic trust, if you will).
> Don't be silly!
I'm not the one who include the KGB, CIA, Mafia, FBI/Interpol, Macys
and Gimbels, the IRA, and the English government in an example:-)
> The secondary function it was supposed to solve is still a major
> problem. If oridinary individuals, or Residential Persons in X.500
> jargon, are to be identified in a manner that is considered globally
> unambiguous, then some form of hierarchical name registration would be
> required. Since the various states seemed to be no more eager to rush
> in and deploy an effective name registration fucntiuon than anyone
> else, it was recognized that someone would have to play tie-breaker in
> the event two people claimed the same name. This becomes even more of
> a pressing issue if, for privacy reasons, people do not want to
> disclose their full residential street address. I submit we still have
> this problem, and the only effective way to guarantee uniqueness
> without violating privacy is to use a CA name plus serialNumber
> approach in the DN, relegating the non-unique commonName to
> alternateName.
Well, there's always the post office. They seem to want to get into
this business and most people can be identified by a combination of
their name and postal address. As for not wanting to disclose full,
residential addresses, the post office is also used to dealing with
post office boxes, general delivery, etc. Of course, some parties
will not be party to transactions unless they do know your address
(party poopers) -- try to get a driver's license without an address
and then tell me how to do it. By the same token, and, I believe,
agreeing with you, my credit, phone, and ATM cards do not include my
address, nor would I expect their certificate counterparts to.
> But back to the issue of the trusted root. I certainly recall
> extensive discussions with Steve Kent and others regarding various
> IMPLEMENTATION OPTIONS for managing an end-user specified and
> controlled cache of trusted certificates, commencing with the user's
> own. No one had a problem with that, and that provided the end user,
> the person who ultimately has to make the real decision as to whom he
> trusts, with the ability to add as many single individuals, small
> hierarchies, or even large cross-linked hierarchies that one
> could reasonably ask for.
All true, but that's not PEM. MOSS provides support for X.509
certificates without mandating use of the IPRA. IMPLEMENTATION
OPTIONS, as you describe, are flexible and available under MOSS. For
example, TIS/MOSS allows you to place trust in any person or point in
a hierarchy. If you want the keep with the PEM model with TIS/MOSS,
you need only place trust in your own public key and the IPRA. The
former is implementation-specific and used to cryptographically
protect the user's database against tampering.
> What PEM didn't do was:
> 1. Support the PGP notion of transitive trust.
...
> 2. Support the notion of one CA or one individual belonging to two
> or more certificate hierarchies.
...
> The REAL problem with PEM, I submit, was the fact that despite our own
> predelictions, there simply wasn't sufficient market demand for a
> commercial security product. People scarffed up the free PGP, to be
> sure -- perhaps as a toy, and perhaps to sort of stick a finger in the
> Establishment's eye -- but how many people do you see frequently
> _using_ it even now, much less four or five years ago. MIME
> compatibility was of considerable interest to the cutting edge
> Internet techie and visionariess, but was an insignificant nit with
> respect to PEM's lack of acceptance.
I agree with everything you say up to a point. The market demand for
secure multi-media mail is now there and growing. We get a steady
stream of queries. Unfortunately, the cost (development, integration,
documentation, packaging) to add security to email packages is still
higher than most mail user agent vendors are willing to pay without a
known, visible market which can easily be included in their
accountants' spreadsheets. Even if a few enlightened mail program
vendors add security, users then have trouble because not enough mail
programs on the various platforms they use provide those security
services, so interoperability is non-existent. A chicken and egg
problem.
One way to short-circuit the chicken end egg/bootstrapping problem is
RFC1847 (Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted). If support for RFC1847, which is cheap and easy
for any MIME-aware user agent, was adopted by email vendors, security
packages could easily and seamlessly be added after the fact. Users
interested in security could purchase security packages, which might
implement MOSS, PGP, or even S/MIME if it were modified, and have them
work with their off the shelf mail programs. It's the same "helper
application" model used by MIME and many web browsers.
Mark
------- =_aaaaaaaaaa0
Content-Type: application/moss-signature
Content-ID: <5434.825032983.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID: PK,MHcwCgYEVQgBAQICAwADaQAwZgJhAKJzafITUAG5mJfm5I2TPHzYFvzW=
X6VjoFu6n3IWeFdIkw6F1mcJuGrMiASE26EbgO47WImp4CJiRiocwoPb5upi9G2znfUvgigvXD=
IG08D6t6NC5gmWJ7Pvfm00PZx8YQIBAw=3D=3D,EN,1,feldman@tis.com
MIC-Info: RSA-MD5,RSA,aJd8gVjEUUtj/9x4Fn5AP8eR1zyPw/fgoc6YzoR4kmV9wlcuTrjs=
E4iEl12pNfiSbKSrWqsf/fE1N8kjJB2SgT3neSQ4h2791M4M8NwZp9JfVmekwcmgoJCLhyq0p1=
+1
------- =_aaaaaaaaaa0--