[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: x.509 v3 Certificates and Compatbility
All,
I agree with Bob.
We have come to the same conclusion. There may be several reasons
for having more than 1 certificate even for the same key usage.
More reasons may be:
- Different certificate policies
- Different integrity aspects (some personal information should not be
published while some shouldn't)
- Different validity periods for different personal data.
- Some attributes can't be certified by the same CA:s. (i.e. Bank account
and employment number)
etc. etc.
Compare with, gasoline cards, ID-cards, credit cards, library cards,
employment cards, medical cards. They are all "physical" certificates
certifying my connection with different attributes and privileges.
My concern is mainly. How do the certificate holder select the appropriate
certificate.
Suppose that the entity has two certificates with the same key usage. One
anonymous for his www.sex.com and one digital ID certificate for banking
applications over the internet. In both cases the applications is run over
http.
Will there be any suitable mechanisms that selects the appropriate
certificate. Is there any actions that can be taken by the server to help
the client to select the appropriate certificate or will the entity be
forced to select by him self?
Is there any one with a sound solution to this problem? Any opinion?
I would like to se a solution that doesn't require extra, non standard,
modules for the client.
/Stefan
At 02:11 PM 8/17/98 -0600, Bob Jueneman wrote:
>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@novell.com
>
>"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@zionsbank.com> 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@yahoo.com> 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
>
>
!
>!
>!
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------