Re: [IETF-PKIX] Multiple certificates for same key?

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Tony Bartoletti <azb@llnl.gov>
>
> > From: kent@bbn.com
> >
> >Wrong mailing list.  What you said above is the SPKI notion, but it's not
> >the PKIX notion, of the semantics of the subject name field in a
> >certificate.
> >
> >Steve
>
> I agree with your characterization of subject name SPKI vis-a-vis PKIX.
>
> Dan makes a secondary point, in that the cost of carrying different keys
> for every usage (identification or authorization, I suppose) be weighed
> against the potential privacy concern of having one key (especially in
> the case of an identity role) employed so widely that tracking usage on
> the one key produces a virtual dossier on the owner.


Tony's characterization is eloquent enough that it cannot be improved
upon, but merely restated.  By following the "wallet and paper signature"
model and having a single public key which announces "This Is Me!", users
would be voluntarily adopting the very thing they refuse to have
imposed upon them externally: a national ID.

My primary objection to multiple certification is the lack of handling
flexibility, not usage tracking.  If certificates are analogous to the
contents of a wallet, then I would like to be able to dynamically decide
what to carry in my wallet depending on where I'm going.  Normally I'd
carry everything, for convenience.  But if I'm going on a trip, I'd
remove the cards I'm not expecting to need so that if the wallet is
lost or stolen, I don't have to cancel everything.

In a token or key database, if every certificate's copy of the
private key has the same value (or in Paul Koning's model, which I
haven't heard of being supported in commercially available tokens or
applications, every certificate refers to the same storage location for
the private key), then the assignment of certificates to storage
modules is done once at issuance.  But if every certificate uses a
different private key, then those keys can be moved in and out of the
storage module as needed to accommodate where the module will be used.
I might normally want to keep my "AMEX Platinum" key on my smartcard,
but if I were going to plug that smartcard into a mall kiosk or an IETF
terminal room machine, I'd rather take the AMEX key off and leave just
an S/MIME email key on the card.

The third objection to multiple certification is that it leads
inexorably to a permanent key that cannot be updated.  Although it is
impossible for a single CA to verify that a key has not been certified
somewhere else, it is certainly possible and often desirable for that
CA to ensure that the key is changed at renewal.  But if a single key
is used for all certificates, and the validity dates for all CAs are
not synchronized, then it is impossible for any CA to rekey it's own
subjects' certificates, much less establish rekey periods that are
appropriate for the purpose of the certificates.

In summary, the disadvantages of a shared key across certificates include:

* inability of the user to change the contents of a storage module
* inability for any CA to establish a policy of rekeying on reissuance
* enables usage tracking
* not supported by current applications (counterexamples welcome)

The advantages include:

* might save memory (if each cert doesn't keep it's own copy of the
  private key).


With regard to comments that a standard requiring users not to share
keys is "unenforceable":  so is any standard recommending behavior that
is in the user's interest.  No one is going to jail for failing
to eat their Recommended Daily Allowance of Vitamin A.  But it is
nonetheless useful to publish RDA numbers ("standards") for vitamins
and minerals to allow consumers to make educated decisions based on
information published by nutrition experts and food producers.

PKIX is an information resource, not just a technical interoperability
specification.  Let's write security considerations that provide some
useful guidance on choosing a key sharing policy.

Dave Kemp