On Sat 2015-07-25 08:56:09 -0400, Paul Wouters wrote:
[ dkg wrote: ]
I looked at it with Petr Spacek after the meeting, and i plan on
providing Paul with a more detailed review shortly.
Greatly appreciated!
heh, fsvo "shortly" :/
i'm not subscribed to dane(_at_)ietf(_dot_)org, feel free to forward if you
think
this would be useful.
key discovery vs key validation
-------------------------------
As an optional key discovery mechanism for OpenPGP, i think this
proposal has merit. I share Watson's concerns about "smuggling in a
different trust model", but i have no complaints about DNSSEC validation
being used as a corroborative validation mechanism, should clients
choose to accept it for validation purposes. For clients that *don't*
choose to accept it for validation purposes, they should validate the
keys via their usual mechanisms, and rely on OPENPGPKEY records solely
for discovery purposes.
metadata leakage
----------------
I'm a little concerned about the potential for metadata leakage -- i
don't want my MUAs to do DNS lookups every time i try to send mail to
someone whose keys i dont have. Until DPRIVE is a reality (and maybe
even after that) the DNS leaks much more information than my typical MUA
-> MSA connection. (i like the metadata channel minimization offered by
draft-moore-smtp-addrquery for that reason).
localpart mangling
------------------
I have no strong preference for base32 vs. digested localpart for the
hostname. Digested localparts require a little bit more work to invert
than base32, but given the low entropy of typical normalized localparts,
they don't provide a lot of protection against a determined attacker.
I'm slightly more concerned with e-mail address length limits on base32
than on digested localparts -- a long localpart plus a long domain name
could make for a very large DNS label, whereas a fixed digest should
give us a fixed bound on size.
In either case, some canonicalization will be required (before base32 or
digest, whichever is chosen). fwiw, i believe that case normalization
of the localpart is pragmatic for today's networks, despite not being
within the letter of the RFC. I would advise clients to downcase before
doing a lookup.
The main advantage for base32 over digested localpart seems to be for
synthesized OPENPGPKEY records in an online-signing DNSSEC-capable
server. I don't believe this is a significant advantage for a key
discovery mechanism for OpenPGP, because i believe some people will want
to verify the OpenPGP certificate itself, regardless of its DNSSEC
status, and the OpenPGP certificate won't have wildcards in it.
RDATA content/structure
-----------------------
The -03 spec §2.1 currently suggests that the RDATA should be an
"RFC4880 OpenPGP public keyring", but RFC 4880 doesn't define a "public
keyring" in any reusable way (see
https://tools.ietf.org/html/rfc4880#section-3.6).
§ 2.2 says:
The RDATA Wire Format consists of a single OpenPGP public key as
defined in Section 5.5.1.1 of [RFC4880]. Note that this format is
without ASCII armor or base64 encoding.
But 5.5.1.1 is *just* a public key packet. This is not a useful record
to store.
Instead what you want is probably exactly one "Transferable Public Key"
(https://tools.ietf.org/html/rfc4880#section-11.1), which is the
standard for the composable OpenPGP certificate format. But see the
"Filtered Certificates" section below for more detail.
Key Transitions
---------------
While i say "exactly one" Transferable Public Key, i'm assuming that the
DNS is OK with serving multiple OPENPGPKEY records at a single label.
This would be necessary for people to be able to handle a key
transition. Some examples are:
0) Alice makes a new stronger primary key that she wants people to know
about, while she continues to use her older, better-known key for
several months.
1) Bob makes a new primary key using a new key algorithm (e.g. ECC)
that he knows won't be universally supported. He publishes it
alongside his more traditional (e.g. RSA) key.
2) Carol's longstanding key has been compromised. She revokes it,
makes a new key, and wants to publish both the revoked certificate
as well as her new cert.
I think all of these cases can be served by multiple OPENPGPKEY records.
Filtered Certificates
---------------------
Given that some users have aggregated OpenPGP certificates that are
quite large (my own is currently ~475KB), we don't want to require
people to publish their entire certificate in the DNS. Because OpenPGP
certificates ("transferable public keys) are composable (they consist of
a series of packets, many of which can be dropped), a reasonable policy
for filtering the certificate for size purposes should be suggested.
At a minimum, the OPENPGPKEY record for alice(_at_)example(_dot_)com MUST
contain:
* primary key X
- one User ID Y, SHOULD match 'alice(_at_)example(_dot_)com'
- self-signature from X, binding X to Y.
[ note: I do not believe we need to require that the User ID MUST match
the looked-up record, though it's obviously preferable to a validator
if it does. ]
This extremely minimal record might not provide an encryption-capable
subkey, though, and the primary key may not be encryption-capable
itself.
So a more sensible transferable public key would also include all
relevant subkeys:
* primary key X
- one User ID Y, SHOULD match 'alice(_at_)example(_dot_)com'
- self-signature from X, binding Y to X.
- encryption-capable subkey Z
- self-signature from X, binding Z to X.
- [ other subkeys if relevant ...]
Owners of the record may also want to include some up-to-date
third-party certifications which they think would be helpful for
validation, which would result in:
* primary key X
- one User ID Y, SHOULD match 'alice(_at_)example(_dot_)com'
- self-signature from X, binding Y to X.
- third-party certification from V, binding Y to X
- [ other third-party certifications if relevant ...]
- encryption-capable subkey Z
- self-signature from X, binding Z to X.
- [ other subkeys if relevant ...]
So when preparing these records for a specific OPENPGPKEYDATA with the
goal of minimizing certificate size, a normal user would normally want
to:
0) where one User ID from their cert matches the looked-up address,
strip away non-matching User IDs and any certifications (self-sigs
or third-party certs) associated with them
1) strip away all User Attribute packets and associated certifications
2) strip away all expired subkeys (may want to keep revoked subkeys if
they were revoked prior to their preferred expiration to ensure that
correspondents know they are properly revoked)
3) strip away all but the most recent self-sig for the remaining user
IDs and subkeys
4) (optionally) strip away any uninteresting/unimportant third-party
User ID certifications. This is a value judgement that will be made
imperfectly, since the person creating the record doesn't know the
trust model of the recipient. At the very least, the RDATA owner
should strip all third-party ceritifcations which have been
superceded by other certifications from the same third-party, as
well as any expired third-party certs. Other useful filtering rules
might include the date of the third-party cert (recent certs are
better), strength of the third-party cert (stronger keys are
better), the size of the third-party cert (smaller certs are
better), "connectedness" of the third-party making the cert
(e.g. based on some measurement of presence in the WoT strong set),
or some domain-specific policy (e.g. always include third-party
certs from the organization's internal CA key)
With GnuPG, you can achieve a rough minimization with:
gpg --export-options export-minimal,no-export-attributes $PGPFPR >
opengpgpkey.pgp
(this still exports expired subkeys and alternate User IDs, so further
filtering could be done to make the record even smaller)
Applying the most extreme of these minimization rules (with no
third-party certifications whatever) my own OpenPGP certificate (with a
single large primary key, a relatively long User ID, and three large
subkeys) is < 4KiB.
For even the largest ECC keys (nistp521) with a cert with distinct
primary key and subkey, the filtered/minimized cert is well below 1KiB.
does this make sense? I'm happy to discuss it further.
Regards,
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp