ietf-openpgp
[Top] [All Lists]

Re: [openpgp] rfc3880bis - hard expiration time

2015-05-05 10:24:30
On Tue, May 5, 2015 at 9:43 AM, Derek Atkins <derek(_at_)ihtfp(_dot_)com> wrote:
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> writes:

Sorry, but that horse has already left the barn.  This is precisely
OpenPGP nomenclature.  A Key is a packet that contains a set of data,
part of which is what I would call the "Key Material" but it also
includes other data.

It is not the nomenclature of the field.

Umm, it is exactly the nomenclature PGP/OpenPGP has been using since,
oh, 1992.  It may not match the X509/PKIX world, but lucky for us we
don't have to do that.  :-D

I am pretty sure that Diffie, Rivest et. al. have been using the term
'key' to refer to a public key, a private key or a symmetric key and
nothing else since the mid 70s.

It is not a question of matching the PKIX world. Lauren Kohnfelder set
out the nomenclature back in the 80s.


People are getting confused. And no wonder. People don't know if what
you are talking about is a public key or a PGP 'key'. And you seem to
be getting confused yourself.

No, I know exactly what I'm talking about, but trying to explain it to
people that don't innately grok the (Open)PGP nomenclature requires the
use of additional phrases.  A PGP Key (aka Key) is a packet that
contains a version, algorithm, key material, creation date, etc.

Where we are now is that we have two PKIs that don't talk to each
other. That means we can't use keys from the PGP system with TLS and
we can't use keys from the PKIX system with PGP message formats. And
both cause problems.

I would really like to be able to use some sort of client side public
key based authentication with HTTPS web sites. That means using keys
that are in the user space. Do we really want to insist on the user
having to maintain two separate sets of keys for the different
protocols?

If you want to call a key packet a PGPKey, fine. But we are working in
a standards organization here and one of the things that requires us
to do is to ensure that our nomenclature is consistent across the
organization.


Key fingerprints are useful for far more than just email.

I am just working on setting up Web Service that is distributed across
a set of hosts. Now obviously for external purposes, those hosts are
going to acquire WebPKI certificates. But how do I authenticate the
host to either the CA or LRA?

The simplest solution is to use a public key pair. Lets say the
fingerprint of the public key is:

MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI

Lets also say that there is some TPM capability on the platform so
that I can store the private key on the platform in such a fashion
that I can issue instructions to make use of the key with the above
identifier but can't extract it from the machine without electron
microscope type effort.


So each host has a config file that looks something like:

{"Service" : "Confirmation",
 "HostKey" : "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI",
 "Domain" : "example.com",
 "CA" : {"dns" : "acme.example.com",
     {"root" : "SJE2U-OVCFK-JBVIS-S2JZD-EKURS-IJDVE"}}

And the ACME LRA server would have a config file containing a line
something like:

{Hosts : [
   "MGM2D-SNZRG-A4GGO-BQMM4-DQMRU-GBTDI",
   "MI5GT-ERCTJ-ZNFER-2BGRD-UOT2C-KFGU2-NCEKF",
   "MGVEV-KHIJK-EISK2-JJJU2-SSSIR-FU4SS-RJBBF",
   "MERCP-JZKEE-R2NGN-KE6WS-KKVGV-CWKUI"] }

The combination of these techniques allows me to address one of the
biggest headaches in TLS admin which is how to authenticate a host
before it has a certificate. By far the biggest reason for bad certs
is that admins lose control of their private keys. Automating the
process allows me to go to short lived certs (24 hour rollover).


The point of a certificate is to establish a trust relationship. That
is a different problem to setting up the underlying security
relationship.

Regardless of what you want to use to configure your external trust
relationship (PGP, PKIX, whatever), this is a different problem to
setting up the security relationships.

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp