long-term GPG signing key

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com