Bob,
A fundamental concept of well-architected network protocols is
that of a canonical presentation format to facilitate interoperability
in a heterogeneous system environment. In the Internet, SMTP specifies
such a canonical encoding and PEM, because it was designed for use in
the SMTP environment, adopted that canonical form. Later, we added a
field (Content-Domain) which allows for carriage of other content types
that might employ different canonicalization rules. Thus, if there is a
demand to use compression or to send binary data of some form, there is
a place holder for specifying the compression algorithm, format, etc.
Steve
======== and another response ====================
To: jueneman%wotan(_at_)gte(_dot_)com
Subject: Re: Re: Articulation of PGP point of view?
Cc: pem-dev(_at_)tis(_dot_)com
---------
Bob,
You did a nice job of articulating the roles of the IPRA and PCAs in
your message to Ed, responding to the PGP/PEM certification differences.
However you stated that "The de facto assumption within the Privacy
Enhanced Mail community is that the entire certificate chain is
displayed for the user's edification for each message, and the user
makes a decision as to the believability of that message one at a time."
This is not correct. RFC 1421 makes it clear that the only data that
needs to be displayed is the PCA ID (e.g., DN or local alias) and the
originator's ID. Because of the name subordination rule, it is not
necessary to display a full certification path and I believe that such a
display would generally confuse users, or they would fail to pay
attention to it. This is one of the essential differences between PGP
and PEM, i.e., the complexity of managing the trust semantics.
Steve
================ and another reply =======================
To: jueneman%wotan(_at_)gte(_dot_)com
Subject: confusion?
Cc: pem-dev(_at_)tis(_dot_)com
----------------
Bob,
In response to Ted you stated "I believe that you are correct
about the RFC's assumption that only the DN is displayed, and not all of
the details about the certificate chain." Reread 1422 and you'll see
that the issue of what is displayed is not just an assumption, it is a
requirement.
Name subordination address multiple concerns, including
facilitating uniqueness in user names. However, a more important issue
is the security implications of rogue CAs and the related semantic issue
of who should certify whom. This is not supposed to be a problem in the
residential user case. A residential user PCA in the US might have the
DN: "C=US, S=CA, O=Business-R-Us, OU=Residential-User-PCA." However,
that PCA should create under it a set of CAs, e.g., "C=US,
S=Massachusetts" and "C=US, S=Utah." Note there is no name relation
between these CAs and the PCA, but that's OK by the 1422 rules. Then a
residential user might have a certificate of the form "C=US,
S=Massachusetts, L=Boston, PA = 19 North Square, CN= Paul Revere." In
fact, this example in included in 1422, with the difference that the CA
was more local, i.e., it went to the level of Boston, not just the state
(really commonwealth) of Massachusetts.
Steve
================ and yet anothe reply ============
To: jueneman%wotan(_at_)gte(_dot_)com
Subject: Multiple uses of public keys a hazard?
Cc: pem-dev(_at_)tis(_dot_)com
-----------
Bob,
Your example states:
One of the threats that was brought up fairly early in the PEM
architecture days was the possibility that if the user is allowed
to generate his own public/private keys (which seems like a good
idea, generally) and then bring the public key to the CA in the
form of a prototype certificate, then there was the possibility
that a devious user (that nasty Alice) might try to claim
authorship of a message originally signed by innocent Bob, by
taking Bob's public key and incorporating it in her own
certificate.
Is this a very serious threat? Alice cannot substantiate a claim of
authorship by later signing anything else using the same private key
used to sign the purloined document. Yes, Alice could claim that she
changed her key and no longer has the old private part, and with
appropriate timing of her purported loss, the CRL history will
substantiate that claim. To really understand the threat we need to
look at a concrete example, which you provide later.
For example, suppose that the user receives a certificate from
a PCA that is part of a "commercial" hierarchy, and he uses the
public key in that certificate to purchase some stock. Is there
any way that he could wait a day to see whether the stock goes
up or down, and then repudiate his purchase by claiming that
the alleged signature was based on a Persona certificate
(that happened to have the same public key) that either wasn't
his or clearly wasn't intended for use for commercial
transactions?
The stock broker would have a signed message and a certification path
under a commercial PCA, plus the relevant CRLs. If the user tries to
repudiate this transaction, the existence of PERSONA certificate
containing his public key is not a relevant piece of evidence. The
proof used by the broker would rely on the PCA policy, which would
presumably include a requirement that the CA did a reliable job in
certifying the user (since this is a commercial quality PCA).
So, I really believe this is a red herring, although I agree that the
issues are subtle and require careful evaluation to come to that
conclusion.
Steve
=========== still another reply =====================
To: jueneman%wotan(_at_)gte(_dot_)com
Cc: pem-dev(_at_)tis(_dot_)com
-------------
Bob,
Just a few comments about your response to Ed. You state
Since the IPRA has not yet been established, we have that
situation now. I won't try to defend having an IPRA, as it adds
very little in the way of trust. It merely provides a means of
exchanging CRLs across PCA domains.
The IPRA facilitates CRL distribution and distribution of PCA public
keys. Moreover, the IPRA serves to ensure that PCAs live up to their
policy statements, i.e., should users demonstrate that a PCA is not
acting in a fashion consistent with its policy statement, the IPRA is
capable of decertifying the PCA. This also has the potential to put
some teeth into the common certification policy defined in 1422.
If you wish to set up a autonomous PCA that doesn't send its CRLs
to the IPRA, you are free to do so, and your PEM implementations
will still function correctly. The IETF may object if you claim
that your PCA is PEM-compliant, but lightening won't strike you
down.
Well, once the IPRA is up and running, a compliant PEM UA would reject a
message where the certification path fails to terminate with a PCA
certificate signed by the IPRA. Also, the CRLs for any CAs under the
non-affiliated PCA would not be globally available to other users
through the mechanisms defined in 1422. This too would be cause for
rejecting an incoming message from a user certified under a CA under
that PCA. Thus once the IPRA is operational and the existing PCAs are
signed up, non-affiliated PCAs will become islands apart from the rest
of the Internet certification system.
Steve
======== ibid. =======================
To: jueneman%wotan(_at_)gte(_dot_)com
Subject: Re: DN name mapping, redux
Cc: pem-dev(_at_)tis(_dot_)com,
-----------
Bob,
You asked "Maybe I should ask anyone who is more familiar with the
actual operation of X.500 than I am, exactly how an X.509 certificate
would be retrieved, and what the correlation is between the DN that is
used to do the searching and the DN that is contained within the X.509
certificate itself." The primary index used to find an entry in X.500
is precisely the DN and it is exactly that DN which one would expect to
find in a certificate stored in the directory entry. (One might find
other certificates in a directory entry, but the semantics of finding
these other certificates in a directory entry to which they do not
syntactically correspond is not always clear.) One can search for a
directory entry based on other (non-distinguished) entry attributes, but
the physical distribution of DSAs may make it very expensive to perform
such searches.
You go on to ask "Would we expect to find individual entries for each of
the various roles that an individual might play as DNs in the directory,
with the certificate that corresponds to that particular DN included
along with a number of other attributes such as postal address?" Yes,
each role could be represented by a separate organization role entity
and the certificate for that role would be stored in that entry. There
is a roleOccupant attribute that can be used to point to the entry
corresponding to the person currently filling the role.
I think these responses address your later questions.
Steve