On Mon, Jun 1, 2015 at 3:19 PM, Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:
On Mon, 1 Jun 2015 19:40, dkg(_at_)fifthhorseman(_dot_)net said:
I think i'm still not convinced by this -- can you give an example of
what kind of confusion you're hoping to avoid?
Alice reads her 40 hex digit fingerprints on the phone using oldtool;
Bob comapres it using his newtool, which shows a different fingerprint.
Both don't know anything about fingerprint details but have been advised
to compare them character by character. Their conclusion will be that
this is not the right key.
This is a good point that I had not considered earlier but turns out is
covered in my UDF proposal which guarantees that the leading digit of a UDF
fingerprint is M or S and thus an invalid hex digit :)
There are two issues that I believe we should separate:
1) The method of constructing the fingerprint
2) The method of constructing what is fingerprinted.
The first can be set in stone for a century or more. The second must be
changeable.
Right now we are discussing a v5 key packet format. It would be foolish to
imagine it is going to be the last. We should expect the key packet format
to change albeit infrequently. A new version every ten years or so.
We should also expect and encourage people to fork the key packet format if
that is necessary for their particular application. I am currently using
fingerprints to S/MIME and DNSSEC but I have absolutely no interest in
using the OpenPGP format there and I am certain that those communities
won't either.
This separation is achieved by the construct:
UDF = Base32d (H ( <Content-Type> + ':' + H (Content)))
Lets say that we are working only with OpenPGP keybindings and we are doing
OpenPGPv8. We have three different keybindings that we might encounter
application/openpgp-keybindingv5
application/openpgp-keybindingv7
application/openpgp-keybindingv8
Easy enough to cycle through all three to see if we have a match.
Alternatively, put a version identifier field in the keybinding and we can
use just one identifier.
The reason I think this is going to matter a lot is because I use
fingerprints to specify a root of trust in any identifier. So for example,
let us say you want to say 'go to www.example.com validating the entries
via the DLV root with fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J':
www.example.com.MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J
With this type of construct, I can deploy a DNSSEC hierarchy that is
entirely under my control. No control for 'non-profits' whose million a
year head has told me a stone cold lie to my face.
I also want to be able to use strong email addresses for PGP and S/MIME
without the user having to know which is going to be used.
The PPE Key manager is almost done. Run the keymanager and it will
automatically enable Windows Live Mail to use S/MIME to send and receive
end-to-end encrypted with absolutely no additional user interaction.
Under the covers, we create a new email address, a 'strong' email address
of the form:
<fingerprint>?<username>@<domain-name>
Where <fingerprint> is the fingerprint of a trust root under which the
intended recipient's email encryption preferences are set. Obviously, one
of those preferences can be 'send S/MIME mail version X encrypted under
cert Y'. But I also intend to add 'send OpenPGP mail version P encrypted
under key Q'.
The point is that the end user does not need to know whether their email
client is doing OpenPGP or S/MIME or whatever next gen mail system we do.
And so the fingerprint format should not make a commitment to one single
specification.
I believe we have at minimum two types of content that we want to take
fingerprints of:
* Code distributions
* Keys
For keys, I believe there are at least four format families that may be
encountered.
* OpenPGP
* PKIX Certificate / KeyInfo
* DNSSEC
* Whatever JSON based scheme replaces all the above.
So what I think the charter should give as deliverables are:
1) A new Key package format for OpenPGP keys.
2) A fingerprint mechanism that is content neutral with OpenPGP as the
initial use case.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp