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

[lars.gu.johansson@xxxxxxxxx]

Dave & Phill,

Some short replies...

dpkemp@missi.ncsc.mil wrote:
>
> > From: lars.gu.johansson@posten.se
> >
> > Some people have argued that there's too many security risks
> > involved when dealing with multiple certificates of the same
> > key that it should be prohibited (or at least not recommended :-).
> > I could give you many reasons why there shouldn't be any such
> > restrictions but let me just give you an alternative perspective.
>
> Please list some reasons for preferring multiple certificates per
> key - that is one of the critical items of information missing from
> the discussion so far.
>
> What precisely are the three or four most important advantages of
> multiple certification of keys?  Saving memory on tokens has already
> been mentioned.

My main point was that something that isn't prohibited should be
permitted. Most of the risks that have been discussed so far can
be handled by the policy. But if you want examples I can give you
some:

Saving memory is a valid reson but it can also be interpreted
as saving money. Setting up a PKI based on smart cards is quite
expensive (believe me) so the more certificates/roles that can be
bound to the same token the better. A lot of people are fed up with
how many different cards they have to carry in their wallet already.

I think everyone on this list sees the need for different certificates
(one being the integrity risks).

> Private key storage mechanisms and multiple certificates are
> separate issues.  When you have one security weakness (software
> key storage) it tends to exacerbate security problems in other
> areas (multiple certification).  But saying (or requiring) keys
> to always be stored on tokens does not make the other problems
> go away.  Sure, the private key(s) cannot be extracted from the
> token without perhaps destructive reverse engineering.  But the
> token can still be used by malicious applications to sign things
> the user didn't intend to have signed.  The only way to prevent
> that is to allow segregation of keys by purpose, and not store
> the sensitive keys on tokens that will be highly exposed.

I tend to agree with you that private key storage and multiple
certificates are somewhat separate issues. Perhaps my original
comment should be rehrased as: the security risks are CA's that
certify locally generated keys without careful checking of the
key holders identity.

Your comment on smart cards is in line with Phill's so I'll answer
them both below.

pbaker@verisign.com wrote:
>

[...]

>
> The ambiguity problem is considerably worse with a smart
> card than a soft certificate. The one declarative action that
> is possible with the chip in card format is to insert the device
> into a reader. Any variation in semantics must be captured
> by the terminal - which cannot be considered as secure as
> the card itself.

My intention is not to start a debate on the security of smart cards
vs. soft tokens. And I would definitively not like to suggest that
keys should be to always be stored on tokens. There is a need
for both.

However, as you both point out, there are risks with smart cards
as well (not worse than soft tokens though). There's always
something that you must put your trust on, your local workstation
being one example, but that is no different than with soft tokens.

> On the other hand I don't think we should wire any prohibition
> on dual certification of keys into the standard, the practical
> reason being that such a prohibition could not be enforced.
> People are bound to do it whether or not it is a good idea.
> Therefore it would not be a good thing for clients to rely on
> it not taking place.
>
> If there is not going to be an impact on the specififcation we
> do not need to discuss it.

I'm glad to see that we have the same opinion in this case.
I totally agree with you!

Kind regards,
/Lars Johansson
Sweden Post