"Vivek Chadha" <[EMAIL PROTECTED]> writes: > "When I attempt to import the CA cert to the smartcard, why does'nt the > NSS create a 'new' cert in the token store (on the smartcard)? Instead, > you just see a copy over of the CA cert to the token store" > > I think the reason is that when you attempt to move a CA cert, you do > not have its corresponding private key and the NSS will not let you > 'own' the CA cert. The smartcard is a secure storage for only the certs > that the individual entity owns. The 'public' CA cert is exactly > that...'public' so there is no reason to move it elsewhere.
hardware token is nominal a secure storage for private key ... from PAIN * privacy (sometimes CAIN & confidentiality) * authentication * integrity * non-repudiation you are specifically looking at privacy and confidentiality for the private key. asymmetric key cryptography is the technology ... what one key of a key pair encodes, the other of the key pair decodes (differentiated from symmetric key cryptography where the same key is used for encoding and decoding). there is a business process defined called public key, where one of the keys (of a key pair) is labeled "public" and freely distributed. The other key is labled "private" and is kept confidential aned never divulged. layered on this is another business process called digital signature. the originator computes a hash of a message, encodes the hash with their private key. they then transmit the original message and the attached "digita signature". the recipient decodes the digital signature with the public key, recomputes the message hash and compares the two hash values (the recomputed and the decoded). if they are equal, then the recipient can assume 1) the message hasn't been altered and 2) "something you have" authentication (aka the sender has access to and use of the corresponding private key) ... aka from 3-factor authentication * something you have * something you know * something you are most business operations have long standing and well established relationship management infrastructures. they use such relationship management infrastructures to record things about the relationship (address, current account balance, permissions, etc) as well as authentication material ... in the past, frequently shared-secret (mother's maiden name, SSN, pin or password). however, it is also possible to use well established and long standing relationship management infrastructures to also record public key as authentication material. the advantage that public keys have over shared-secrets is that with shared-secrets people with access to the relationship management infrastructure can also use the shared-secret authentication material for impersonation. the public key can only be used for authentication (and not impersonation). there was a report in the last year or so that something like 70 percent of account/identity theft involves insiders. business processes also have a requirement that their relationship management repository has *integrity* (from PAIN) .... aka that they can trust the information contained in the relationship management repository (in addition, there is frequently *confidentiality( requirements if the repository contains shared-secret authentication material, since that information could be used to impersonate). there are additional business processes which has an original design point of offline email from the ealy 80s. this has several pieces; digital certificates, certification authorities, PKI, etc. In the early 80s, a recipient dialed their local (electronic) post office, exchanged email and hung up. they now were potentially faced with processing first time communication from a total stranger (and had no recourse to local or other information about the total stranger). The total stranger registers their public key and other information in a relationship management infrastructure run by a certification authority. The certification authority then creates specially formated a digitally signed message called a digital certificate (containing the registered information). Now a stranger, with first time communication, creates a message, digitally signs it and sends off the message, the digital signature and the digital certificate. first off, a recipient has expended their *trusted* repository to include the authentication public keys of some number of these certification authorities. when the recipient receives a first time, digitally signed message from a total stranger ... with an attached digital certificate ... they then can use the CA's public key (from their *trusted* repository) to validate the (digital signature on the) digital certificate. then they can use the sender's public key from the digital certificate to validate the message's digital signature. they they use the additional information contained in the digital certificate (copied from the certification authority's relationship management repository) in the processing of first time communication from a total stranger. this is an alternative to the recipient already having the stranger's public key directly registered in the recipient's relationship management infrastructure. the digital certificate format is sometimes convenient for transporting CA public keys ... with the objective that they are sent to a relying party who then can load the associated public key into their *trusted* relationship repository. they typically aren't digital certificates in the business process definition since they are frequently self-signed and the receiving relying party must perform some other process before deciding to load the associated public key into their *trusted* relationship repository. In the early 90s, you were finding some certification authorities looking at grossly overloading x.509 identity certificates with personal information (because they weren't able to predict who the recipients were going to be and/or what their requirements might be when dealing with total stranger). In such PKI/CA business process, these recipients are also referred to as relying parties (because they are relying on the information supplied by the certification authorities in the digital certificate). In the mid-90s, you started to see some institutions realizing that x.509 identity certificates, grossly overloaded with personal information, represented significant privacy and liability issues. In this time-frame you saw some retrenchment to relying-party-only certificates. These relying-party-only certificates effectively contained some sort of database lookup index (like an account number) and a public key. Howevere it is trivial to show that such relying-party-only certificates are redundant and superfluous i.e. by definition, the relying party already has access to all the necessary information in their relationship management infrastructure. In some PKI/CA payment initiatives from the mid-90s, they also found out that such relying-party-only certificates represented severe payload bloat. The typical payment message size is on the order of 60-80 bytes while the relying-party-only certificate overhead ran 4k-12k bytes. Not only was it trivial to show that such relying-party-only certificates were redundant and superfluous, but they also represented a factor of 100 times increase in payload bloat (which is pretty significant for something not serving any useful purpose). -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
