RE: x.509 v3 Certificates and Compatbility

Bob,
You reach the conclusion:

"and you'll bein to see why I doubt that they are all going to fit on a
single smart card!"

But you do not need to store all the CERTIFICATES on the smart card, only
the private keys. And many of the certificates would share the same key
pair, so the number of keys to store will be OK for the smart card.

In our draft Swedish standard for storing keys and certificates on smart
cards, each key has an associated table with a list of certificate pointers,
which either contain a  file reference on the card, or a URL to an external
file or directory where the card holder's additional certificates can be
found.

So I agree with your other conclusion: "this is a very real consideration
when designing directory storage 
and access mechanisms".

Hans

-----Original Message-----
From: Bob Jueneman [mailto:BJUENEMAN@xxxxxxxxxx]
Sent: Monday, August 17, 1998 10:11 PM
To: ietf-pkix@xxxxxxx; bradh_1998@xxxxxxxxx
Subject: Re: x.509 v3 Certificates and Compatbility


Brad,

Your question is quite reasonable. In fact, I went through such
an analsysis with respect to our own PKI product just last week.

Michael Smith has provided one answer, but consider the following:

1. You may need to correspond with various people throughout 
the world, and they with you.  Some of those people (a steadily
decreasing number, it seems) may be unrestricted in terms of what kind of 
crypto they have available to them.  In order to support those people
you may need to offer several different kinds of key lengths that
people can choose between, including 2048 bit, 1024 bit,
and 512 bit.

2. Some users, vendors, and/or standards groups may have a particular
bias for or against some particular algorithm, perhaps because of patent
considerations, technical strength issues, national pride, time/space
tradeoffs, etc. As a result, you may need to support RSA, DSS, elliptic
curves,
Skipjack/KEA, Red Pike, GOST, etc., etc., together with all of the various
key length variations.

3.  Some countries won't allow the use of encryption unless the traffic in 
both directions is accessible to the governmen authorities through some
form of key escrow.  Therefore, even if your government doesn't require
key escrow, you may be forced to use it to communicate securely (sic)
with someone in France, for example.  So you may have to escrow a set 
of keys for that prupose, for example, but you would probably not want to 
use those keys for any other purpose.

4.  For export/import/usage controls reasons, it is desirable to
separate the use of encryption and digital signature keys, since digital 
signature (only) keys generally receive a more favorable export treatment.

5.  The digital signature vs. nonrepudiation key usage argument is
voluminous.
Let me just say that it wouldn't be a good idea to use the same key pair for

authentication (say to your favorite www.sex.com web site) as is used 
for signing an important legal document.

6.  There are key roll-over and other issues that will have to be dealt
with.

7.  You may have different roles -- personal, employee, secretary of the 
bowling league, etc.

Bottom line:  considering only RSA, DSS, and ECC for signing, plus RSA
and D-H for encryption, plus a couple more for mixed usage a la SSL, times
three for different key lengths, and not including any role-based
authentication 
or key escrow considerations, it would not surprise me to see someone with 
on the order of 20 certificates.  Now throw in the restricted use
certificates, 
such as those used for SET and perhaps issued by different banks,
certificates 
containing proprietary attributes that may be used by your company, etc.,
and you'll bein to see why I doubt that they are all going to fit on a
single smart card!

BTW, this is a very real consideration when designing directory storage 
and access mechanisms.  

Bob


Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@xxxxxxxxxx

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home."


>>> Mike Smith <mfsmith@xxxxxxxxxxxxx> 08/13 4:54 PM >>>
Domains of trust.  If your single cert came from a single source that
EVERYONE (worldwide) trusted (and who indemnified ALL who relied on the
certs they issued and that their authentication practices met or exceeded
those in other domains of trust) and they issued all the rights to you at
once, then, maybe that single cert could be practical.  However, I'm still
not sure I would trust it for anything other than issuing a cert to you to
do business from me.

michael
>>> brad h <bradh_1998@xxxxxxxxx> 08/13 2:46 PM >>>
I have a question that the group might be able to help me out with. 
I've been researching this question but have not yet been able to come
up with an answer.

I was wondering why a person would have to have more than one x.509 v3
certificate?  From what I understand they should all be inter-operable.

If you have a x.509 v3 cert shouldn't you be able to add extensions
for each type of device/solution that you're trying to access (ex.
SSL, S/Mime, VPN, PKI, etc.)?

Brad



 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com 

 
!
!