Re: x.509 v3 Certificates and Compatbility

Stefan,

I would recommend use of the Certificate Policies extension to further
assist in selecting appropriate certificates.  A critical Certificate
Policies extension should ensure that the certificate is used only for
the purpose for which it is intended.

Dave S.

Stefan Santesson wrote:
> 
> 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@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
> >
> >
> 
>     !
> >!
> >!
> >
> 
> 
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson                <stefan@xxxxxxxxxxx>
> 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
> -------------------------------------------------------------------

-- 
David Simonetti, Booz·Allen & Hamilton Inc.