[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Copying smart cards. Was: A PKI Question: PKCS11-> PKCS12
I can see Anders way of doing things if the key o the card was only
being used for signing. Thus, when a new device is instantiated by the
CA, the cert on the old device can be put on a revocation list. The
signature check mechanism can still validate signatures done using the
old device as long as they are before the revocation date.
However, if I use the key on the card for encryption, then I would
really like to move my key to a newer safer, better card. Or I may want
to consolidate more than one private key onto a card.
I envision, having keys from an employer, a bank, federal or state
government identifying keys; all on the same card. They should,
however, be protected with separate pins, so that I can unlock a
particular key without cross contamination.
>>> Hal Lockhart <hal.lockhart@xxxxxxxxxxxxx> 11/28/01 09:32AM >>>
So you get a new cert and a new key pair. In what sense is this a
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@xxxxxxxxx]
> Sent: Tuesday, November 27, 2001 2:31 PM
> To: jim.essig@xxxxxxxxxxxxxxxx; raghavh@xxxxxxxxxxxxxxx
> Cc: ietf-pkix@xxxxxxx
> Subject: Copying smart cards. Was: A PKI Question: PKCS11-> PKCS12
> This is how I envision that you could make a "copy" of a
> smart PKI-card
> in a secure way:
> Using the original smart card (with cert. + priv. key) you
> authenticate to
> the CA. Based on the login the CA *could* allow you to do a
> request using a new "fresh" card with built-in key-gen.
> There are PKIX-efforts like SACRED that seems to address your
> whish but I
> think that the above is a better way to do it, as does not
> need export of private keys.
> In addition you can always trace an authentication or signing
> to a particular
> ----- Original Message -----
> From: <jim.essig@xxxxxxxxxxxxxxxx>
> To: <raghavh@xxxxxxxxxxxxxxx>
> Cc: <ietf-pkix@xxxxxxx>
> Sent: Tuesday, November 27, 2001 19:24
> Subject: Re: A PKI Question: PKCS11-> PKCS12
> The purpose of storing a private key in a smart card, is
> exactly that "to
> jail it". By being able to move the private key to another
> device you run
> the risk of a malicious user having a copy of your private
> key and using
> that private key to impersonate you. The reason to have a
> smart card is to
> provide a secure means to transport, store and use your
> private key for
> authentication and/or encryption. A Smart card user may have
> a legitimate
> "want" to move their key to another smart card, but this
> would circumuvent
> the point of the smart card. The purpose is not to just be able to
> transport the key, otherwise everyone would use 3.5" floppies.
> Hope this answered your question.
> "RAGHAVENDRAN H. (SSG) - CTD, Chennai." <raghavh@xxxxxxxxxxxxxxx>
> @mail.imc.org on 11/27/2001 11:17:19 AM
> Sent by: owner-ietf-pkix@xxxxxxxxxxxx
> To: ietf-pkix@xxxxxxx
> Subject: A PKI Question: PKCS11-> PKCS12
> Hi List:
> Sorry this may be off the list, but I thought this is the
> best "PKI" place
> to ask this question :-)
> Myself and my friend had an discussion in which he says that
> when I put a
> private key/certificate pair into a smart card device (such
> as GPK 4000),
> is impossible to read the information and create a PKCS12
> file (disk based)
> out of it.
> I find it mighty strange. For example, I might want to swap my
> certificate/key pair from one smart card to another and I
> might want to do
> it via the PKCS12 format.
> Can anybody say whether this is possible or not?
> Some of my friends say that it "may be" possible to export only the
> Certificate and not the private key associated with it. I
> don't see sense
> any of this argument.
> In fact, what is the point in jailing the private key for
> life in a single
> smart card? This argument is totally contrary to logical thinking.
> Pls. guys, I'd be grateful if you could answer this question.
> The information transmitted is intended only for the person
> or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other
> use of, or
> taking of any action in reliance upon, this information by persons
> entities other than the intended recipient is prohibited.
> If you received
> this in error, please contact the sender and delete the
> material from any