Guus Sliepen wrote: > By default, GPG creates a signing key and an encryption key. The signing > key is used both for signing other keys (including self-signing your own > keys), and for signing documents (like emails). However, it is possible > to "split" the signing key into a master key that you only use to sign > other keys, and a key dedicated to signing documents. You can revoke the > latter key and create a new one whenever you want, the master key is > still valid. Also, when people sign your key, they sign your master key, > not the subkeys. The signatures you accumulated will also still be > valid. You can also keep the master key safely tucked away on an old > laptop that you keep in a safe, and only export the subkeys to your > workstation. That way the master key is very safe.
as in previous post ... i assert that fundamental digital signature verification is an authentication operation http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing keys and doesn't (by itself) carry with it characteristics of human signature, read, understood, approves, agrees, and/or authorizes. the PKI & CA hiearchical infrastructures does tend to add those attributes to digital signature operations ... creating an equiivalence between certification digital signatures (and the private keys that produce such digital signatures) and the validity of the information being certified. if you are starting to create a class of private keys that start to carry the attribute of whether something is true or not (i.e. the information being certified) ... then there can start to become some confusion between the difference between the private key as an authentication mechanism and the use of the private key as whether something is true or not. I would assert that authentication private keys can be treated like a much better password technology ... not having various of the shared-secret vulnerabilities and other shortcomings. it is when you start equating private keys with certification and truth characteristics that you move into a completely different risk and threat domain. the other foray into embellishing private keys and digital signatures with human signature type characteristics was the non-repudiation activity. however, it is now commoningly accepted that to embellish digital signatures with non-repudiation attributes requires a whole lot of additional business processes ... not the simple operation of generating an authentication digital signature. the whole scenario of digital signing of public keys ... is a matter of the entity performing the digital signing doing an authentication operation ... but that the entity is certifying the truth of some value ... typically related to the public key. that is a whole business process infrastructure that has to be layered on top of digital signatures (in much the same way to actually achieve non-repudiation a whole business process infrastructure has to be created that is built above any authentication digital signature). the other characteristics is that stale, static certification ... paper or digitally signed electronic bits ... are characteristic of the offline age ... where an entity could present the certificate representing the truth of some information; as opposed to the relying party having their own access to the truth of the same information. in the transition to an online world, it is becoming less & less coming that relying parties won't have access to the truth of some piece of information (making certificates and credentials less and less meaningful). the corollary is that digitally signed certificates and private keys embellished with certification and truth characteristics become less and less meaningful. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]