Re: Certificate Policies (was Re: Trivial PKI Question)

[lynn.wheeler@xxxxxxxxxxxxx]

a similar argument was used with regard to plastics cards turned smartcards
.... however the most common failure was lost/stolen wallet containing all
such cards. there was absolutely no difference with management issues
whether there was a signle card or multiple cards .... for the most common
failure/exploit.

postulated was that the next most common failure (fraud, exploit,
availability, etc) might be hardware failure. however, the hardware failure
scenarios statistics didn't mandate a one-for-one mapping between token &
function .... it would just indicate that some might want
no-single-point-of-failure (two tokens, or at most three).

I would assert that if you need/require multiple certificates .... that
there is effectively nearly the same management process ... regardless of
whether a single key or multiple keys are involved.  You have to a mapping
between key to which certificate .... whether it is one-to-one or
one-to-many .... and you have to have a notification process for each
certificate. The issue then isn't the management of the information .... it
is just how many that might have to be notified for each key compromise ...
not the management problem of keeping track of all that might have to be
notified. It is slightly different if the information hasn't been managed
and it is necessary to reconstruct it after a compromise ... then if there
is only a one-to-one mapping .... then the scope of reconstruction may not
be as bad ... since the search for key-to-certificate mapping stops after
the correct certificate has been identified ... and the search for
notification process stops ... after the process for the specific
certificate is found.

issue with regard multiple or single key compromise .... would be if the
compromise modes have common components. For instance are all private keys
carried in the same hardware token or same encrypted file. If the most
common compromise/failure mode for keys .... are common multiple key
failure ... aka attack on encrypted file containing all private keys ....
then all certificates have to be revoked .... regardless of whether there
is a one-to-one policy or a one-to-many policy is allowed (aka similar to
the most common failure mode for cards .... the lost/stolen of wallet/purse
... where all cards are taken .... and there is no differentiation in this
failure mode whether there were single card or multiple cards .... all
cards fail). semantic note: "common" is used in the sense of "most
frequent" ... as well as the sense of "affectiing all keys".

I would also strongly assert that many policies are left over from
shared-secret key policies .... each infrastructure requiring a unique key
because of vulnerabilities specifically associated with shared-secret key.

I would contend that many of the vulnerabilities significantly changed
transitioning from shared-secret key infrastructure to public key
infrastructure .... and the vulnerability thresholds needed for various
organizations would still be met if the same public key were used in
different infrastructures ... aka many infrastructures never bothered
really redoing failure/vulnerability analysis. Possibly in the transition
from shared-secret to public; some bureaucrat just says that there is a
policy regarding keys .... and of course all keys are the same.
Bureaucratic policies have a life of their own.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


Al Arsenault <awa1@xxxxxxxxxxx> on 3/13/2003 7:40 am wrote:

><snip>
> * When using multiple CA-s, what prevents you from issuing multiple
> certificates to the same key?
>

>From a technical standpoint, typically nothing prevents this.  It's not
commonly done because:

    a.  There's more of a management problem; e.g., if the key is ever
compromised for whatever reason, you have to track down ALL of the
certificates it was bound to and revoke them;  and

    b.  Policies typically restrict it.

But it could easily be done (and has in some specialized cases).

                Al Arsenault
                Chief Security Architect
                Diversinet Corp.