Subject: [openpgp] Fingerprints

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Apr 2015 09:23:18 -0400

On Fri, Apr 10, 2015 at 7:38 AM, Stephen Farrell
<[email-masked]> wrote:
>
>
> Hiya, here's the 2nd thread, starting from DKG's list. Please
> discuss... (We don't need +1's for this, just tweaks, corrections,
> additions etc.) If someone wanted to put this on github or
> somewhere else the group can edit it, that'd also be fine.
>
> Ta,
> S.
>
> a) update the fingerprint format (avoid inclusion of creation date, use
>    stronger digest algorithm; i'm dubious about embedding algorithm
>    agility in the fingerprint itself, but explicit version info in the
>    fingerprint might be reasonable so we don't have to keep guessing by
>    fpr structure for future versions)

I would like to get started on this bit ASAP as it is the one that has
the most long term consequences.

There is no need to have an algorithm field, a version field is
sufficient because we should only be using one algorithm at a given
time. There is no need for a length field either.

Right now, I am using a one byte version field for my scheme.

I am also using SHA512 and truncating to 128 bits, then base 32
encoding. The rationale for this is

* Case sensitivity breaks in many applications where fingerprints
might be used. Reading over the telephone, putting them in the DNS,
etc.

* Fingerprints are the root of trust, there is an outside chance that
SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits
is a lot harder because it has 80 rounds rather than 64.

* The birthday attack is not relevant, nor are key substitution
attacks for most situations where you might want to use a fingerprint.
Occasionally however, they do matter. Using SHA-2-512 and truncating
makes it possible to 'upgrade' the fingerprint by just adding back the
bits that were omitted. This has particular advantages when enrolling
fingerprints in a TRANS like log. We can enroll the full 512 bit
fingerprint without impact on things like business cards.

The bit that will probably be controversial is how I am calculating
them, over an X.509v3 KeyInfo block. There is method to the madness
however:

First, fingerprints and key hashes are appearing in many different
IETF specs. We have them in HTTP key pinning and in many other specs.
I would like to be able to use one key fingerprint in any situation.
Adding a key or fingerprint into an identifier allows it to be
'hardened', basically we have a self authenticating identifier. This
is very powerful.

To have one fingerprint format that supports every protocol requires
that we have a single registry of identifiers that can be used for any
protocol. There will always be an OID for any protocol the IETF uses
and this mechanism requires no maintenance by either IETF or IANA. If
people want to use vanity crypto, they can and they don't need to come
to us with a draft. They don't get to claim IETF endorsement either.

As a practical matter, the impact on coding is virtually nil. The
conversion between the ASCII and byte format of OIDs is a bit of a
pain but it results in a byte sequence that can just be prepended to
the key bytes. It is not necessary to implement a DER encoder just to
calculate KeyInfo blobs any more than it is necessary to do this for
implementing PKCS #1 for RSA.

Low level crypto has always involved bits of ad-hoc ASN.1 and probably
always will. And quite often it turns out that even the crypto
libraries that contain full ASN.1 parser/encoders implement these
particular structures by hand.

Now if the group really wants to do something different, then I could
do that. But I want to start shipping my stuff and getting people
using the code.

If people really can't stomach ASN.1 code then we could do some other
key format. But the problem then becomes having to specify how to
express new algorithms in that format.

---

From: Werner Koch <[email-masked]>
Date: Fri, 10 Apr 2015 15:57:18 +0200

> sufficient because we should only be using one algorithm at a given

Right.  However an algorithm field is as good as a version field because
they have the same purpose in this context.  An algorithm field saves us
a mapping to the actual algorithm.  Recall that OpenPGP uses an
one-octet indentifier and not an OID.

> time. There is no need for a length field either.

Agreed.

It is often useful to have a keyid to quickly (but insecure) refer to a
key.  I suggest to take it from the fingerprint bytes 1 to 4 (ignoring
the algorithm byte).  There is no need for a long keyid.  However, we
may also suggest a use like in git where you may abbreviate it as you
like - however the keyid should be non-normative because the protocol
should not make any use of it.

> encoding. The rationale for this is

Because there are several versions of BASE-32 I suggest the use of
z-base-32 which is used by Tahoe-LAFS and ZRTP.  The truncation length of
the hash should be match a best match for the base 32 encoding.

> is a lot harder because it has 80 rounds rather than 64.

I think that should be discussed in the context of the new default hash
algorithm.

> them, over an X.509v3 KeyInfo block. There is method to the madness

X.509 has no definition for a fingerprint but OpenPG already uses a well
defined method to compute the fingerprint.  You can't compare the two
protocols or define a unique fingerprint method.

> key format. But the problem then becomes having to specify how to

We want to do an rfc4880bis and not an entire new protocol.  Thus any
ASN.1 encoding is not an option.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 10 Apr 2015 10:58:11 -0400

> one-octet indentifier and not an OID.

I'm with Werner on this one.  There's not a significant difference
between a version field and an algorithm field.  Either option adds a
single byte to the data structure, but using a version field requires
additional lookup map (from fingerprint version # to hash algorithm).

Maybe that's useful to make sure an attacker doesn't use a "bad" hash
algorithm for a fingerprint?  But I'd rather just use the hash algorithm
directly.

> should not make any use of it.

I presume here you are referring to the "printed" fingerprint, and not
the "internal" fingerprint?  Internally we'd still use the full length,
right?  Or would we need to somehow know when (and how) to truncate the
hash?

> the hash should be match a best match for the base 32 encoding.

Similarly, I think we should be clear that we're talking about two
different things here.  Internally (e.g. in a signature packet) it
should be the binary result, not hex- or base-32 encoded.

> protocols or define a unique fingerprint method.

I think "how you take the fingerprint of an X509 key block" should be
out of scope for the OpenPGP WG.  I think that you can (and should)
write a separate document that does that.

> ASN.1 encoding is not an option.

Ditto.  If the goal here is to have the same key material result in the
same fingerprint regardless of whether it's encoded in OpenPGP or X.509,
I think the answer is going to be "X.509 people are going to need to
convert their key material to OpenPGP packet format and feed into the
hash algorithm".  I see no other way, and frankly any other way is
madness (for the OpenPGP group).

I'm sure Phill wont like that answer, but I think it's the right answer
for this (potential) working group.

>    Werner

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Apr 2015 11:15:28 -0400

> the hash should be match a best match for the base 32 encoding.

That is the one I am using already. Truncating to a multiple of 5 bits makes
sense to me (32 = 2^5). If we truncate to a multiple of 5 characters as well,
we can break at the segment boundaries:

100 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx

125 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

200 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

250 bit fingerprint:
opgp:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

The version field will steal a few bits. We might want to consider using
a 5 bit field rather than 8 and set it up so that the first character gives
the version number. Future generations can always decide to add bits
if they start to run out.

> I think that should be discussed in the context of the new default hash

OK, fair enough.

> protocols or define a unique fingerprint method.

The objective here is to be able to establish the fingerprint as the interface
between the trust model and the protocol.

X.509 does not have that concept at the moment. But introducing that
concept into the PKIX world is how I think we can get to convergence between
the two models.

> ASN.1 encoding is not an option.

For approved algorithms, I really don't care. I will need to implement
the existing
key format in any case.

What I would like to avoid is having to review drafts describing vanity crypto.

The fingerprint is going to need to include some sort of algorithm
identifier key
in the data being hashed to prevent algorithm substitution attacks. So
one option
would be to specify how to encode the algorithms we plan to approve and
recommend and then reserve one code for 'X.509 KeyInfo Blob' just treating
it as an algorithm.

Then when the Russians come looking to get a PGP RFC issued describing
how to use GOST, the NSA come along wanting code points for Suites A, B and C,
Fred comes round with Power One Time Pad, etc. etc. They can be told they
don't need it.

This has the major advantage that there would be no need to shift away from
the existing one byte registries and it would reduce the risk of having them
filled up with junk.

One of the things I would like the IETF to adopt as a general policy
is to have one
Mandatory to Implement algorithm and one backup algorithm that are supported by
all IETF crypto protocols that are in active use and to avoid having
working groups
dragging on for five years after they were really finished as people bikeshed
algorithm choices.

---

From: Werner Koch <[email-masked]>
Date: Fri, 10 Apr 2015 17:26:47 +0200

> right?  Or would we need to somehow know when (and how) to truncate the

Sure, just for the printed one.  Internally we should alway use the full
fingerprint with algorithm id.  If we want to have the smallest possible
signature it is possible to not emit the new IssuerFingerprint signature
subpacket.

> should be the binary result, not hex- or base-32 encoded.

Sure.  Although this is not part of the wire format it is important to
have a standard on how a fingerprint is presented to the user.

Shalom-Salam,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Apr 2015 11:36:16 -0400

> algorithm for a fingerprint?  But I'd rather just use the hash algorithm

Well if we are all going to use the same algorithm, having the leading byte
be 8 (SHA-2-256) or 10 (SHA-2-512) versus 0 hardly makes a difference.

In fact I could continue to use 0 for my OID based scheme and achieve
interop :)

The only downside of this approach is that divergence is easier.

> right?  Or would we need to somehow know when (and how) to truncate the

We would need something to tell us how many bits we should require in
particular circumstances.

So for example, if I am wanting to send you an email, I should probably
require at least 100 bits. If I am deciding whether to accept a request to
connect to my home network from a set top box, 25 bits is probably
sufficient as only one device is likely to be making a request at a time and
a 1 in a million chance of being fooled is probably OK.

> should be the binary result, not hex- or base-32 encoded.

Yes, definitely. Base32 is just for display.

> write a separate document that does that.

As long as the identifier is reserved in the OpenPGP registry so there is
no risk of ambiguity, that is OK.

I think that where any draft is discussed is really an issue for the AD and
the WG chairs. It might well be simpler for me if it is outside the WG.

> for this (potential) working group.

Phill cares more about the timing of a decision rather than what the
decision is.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Fri, 10 Apr 2015 23:37:17 +0200

On Fri, 2015-04-10 at 15:57 +0200, Werner Koch wrote: 
> Right.
Why? Isn't that exactly what the past has taught us? That using one
fixed fingerprint algo leads into all kinds of troubles?
And not just from the engineering side (i.e. that applications simply
take it for granted that the data will be SHA1, e.g. when parsing output
of programs).
Looking at other areas (e.g. SSH) tendency seems to be rather to support
multiple fingerprint algos, and people can chose what they want.

And from the crypto side, we also see how bad it was/is, to have fixed
algos,... first with MD5 now with SHA1.
It's simply naive to believe that current or future algos won't meet the
same fate ultimately.

> key.
And it caused also issues, when people *did* assume they'd be secure.

> I think that should be discussed in the context of the new default hash
SHA2 and Keccak?

Cheers.

---

From: Werner Koch <[email-masked]>
Date: Sat, 11 Apr 2015 12:46:48 +0200

> fixed fingerprint algo leads into all kinds of troubles?

Trouble with a fingerprint?  I am interested to hear about such a case.
(ssh's default use of MD5 does not count).

> And it caused also issues, when people *did* assume they'd be secure.

Yeah, similar to the common behaviour of only comparing the first and
last 2 bytes of SHA-1 fingerprints and checksums.

Shalom-Salam,

   Werner

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 11 Apr 2015 17:42:15 +0200

> (ssh's default use of MD5 does not count).
Isn't it one main reasons for all these efforts now to get rid of SHA1
on OpenPGP?

Cheers,
Chris.

---

From: Tom Ritter <[email-masked]>
Date: Sun, 12 Apr 2015 22:11:56 -0500

> additional lookup map (from fingerprint version # to hash algorithm).

Well, say we choose SHA-3, and say Algorithm 1 is SHA-3.  In 5 years,
where we learned our lesson and want to hash a different set of data
for the fingerprint, but SHA-3 is still fine, wouldn't that be a
problem?

-tom

---

From: Werner Koch <[email-masked]>
Date: Mon, 13 Apr 2015 09:41:38 +0200

> for the fingerprint, but SHA-3 is still fine, wouldn't that be a

That would require a new key packet format anyway and any old key can't
be used with that.

Shalom-Salam,

   Werner

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 13 Apr 2015 17:40:45 +0200

> That would require a new key packet format anyway and any old key can't
Wouldn't it be possible to make that completely independent of the used
fingerprint?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Apr 2015 13:32:22 -0400

I think what the discussion of the fingerprint issue is demonstrating
is that there is actually a semantic difference between the hash
algorithm ID and the fingerprint ID.

While this does not make a difference to the bits on the wire, we
should probably maintain the distinction or else confusion will be
introduced.

It is settled practice that if you are going to sign any important
piece of data then you had better sign (Content-Type + Data) and not
just Data. Otherwise there is a substitution attack waiting. The same
principle applies to fingerprints.

With a fingerprint we have to distinguish:

1) The hash algorithm used to create a fingerprint
2) The packaging format that converts
     (AlgorithmID, PublicKeyBytes) -> PackedBytes

Right now (2) is a PGP format. But it is not impossible that we would
want to switch to a different format down the road. The chief
limitation in the PGP format is that all the slots and structures are
essentially fixed. The chief benefit of JSON is that it the slots in a
structure are not fixed and unlike previous attempts (ASN.1, XML)
making use of the extension mechanism does not completely suck.

Given the way fingerprints are used, there is an intense pressure to
use a single algorithm for everything. That is why I think that we
should pick either SHA-2-512 or SHA-3-512 and truncate as necessary.

As a practical matter, I could care less about the code points people
choose. But this really is a separate registry from the hash
algorithms.

We don't need to do anything to identify legacy fingerprints because
they are a different size. But totting up all the expected needs, I
can only see the need for 3 entries in the next 20 years, maximum:

Code, Packaging, Algorithm

10, PGP, SHA-?-512
0, X.509 KeyInfo, SHA-2-512
42, JSON-y, SHA-3-512

The type 10 fingerprint would be used for all keys that have a PGP
algorithm identifier code assigned and type 0 would be used for vanity
crypto, etc.

I picked 10 for PGP because that is the code for the SHA-2-512
algorithm which I think is probably the best choice right now and 42
for some future packing because why not and 0 because that is what I
am using now.

I don't think we are likely to need code 42 for a decade. It is the
sort of thing that you do AFTER all the other structures are
converted. And even then only if you have to.

But the point is that this is a registry with 3 entries maximum. It is
not equivalent to the hash registry.

---

From: ianG <[email-masked]>
Date: Mon, 13 Apr 2015 18:58:39 +0100

> should pick either SHA-2-512 or SHA-3-512 and truncate as necessary.

If SHA-2-512, then I'm happy to truncate as necessary.

If SHA-3, it is a sponge function internally so it is designed to do the 
"truncation" or rather "expansion" already and it'd be a shame not to 
use that feature directly.

(as an aside, I think we should go with Keccak entirely as it'll be out 
soon enough in NIST form as SHA-3, and it has substantial other benefits.)

iang

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Mon, 13 Apr 2015 20:14:15 +0200

+1

On 04/13/2015 07:58 PM, ianG wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Apr 2015 20:36:11 -0400

On Mon, Apr 13, 2015 at 1:58 PM, ianG <[email-masked]> wrote:
> "truncation" or rather "expansion" already and it'd be a shame not to use
> that feature directly.

It makes no difference to the security and requires specific features
most libraries are unlikely to support. Digging in to the internal
functions of crypto algorithms is very much to be avoided.

Besides which, it loses the convenience of small fingerprints being
the first few digits of a long one.

---

From: Stephen Paul Weber <[email-masked]>
Date: Wed, 15 Apr 2015 08:51:05 -0500

>one-octet indentifier and not an OID.

And it could save specifying versions somewhere seperately from the 
algorithm identifiers that already exist.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Apr 2015 12:40:03 -0400

A while back, Stephen and I and some others worked on the 'ni' scheme
which is 'naming things with hashes':

https://tools.ietf.org/html/rfc6920

Now I don't suggest we adopt that approach directly for PGP. But I do
wonder why we assume that the only thing it makes sense to name in
this way is going to be a public key.

Hashes are really flexible and they are simple to implement. That is
not true of any PKI, PGP included. So signing binary applications with
PGP is not necessarily a substitute for having a fingerprint of that
application. The same is true when we are dealing with attachments in
many cases.

Which got me thinking, why not leverage MIME content types and make
them a part of the fingerprint scheme?

fingerprint = "application/pgp-key-binary:" + <data-blob>
fingerprint = "application/pkix-keyinfo:" + <data-blob>
fingerprint = "application/trans-log:" + <data-blob>

or:

fingerprint = "application/java:" + <data-blob>
fingerprint = "application/cli:" + <data-blob>
fingerprint = "application/zip:" + <data-blob>

One of the major advantages of this scheme is that if we were to
decide on a future PKI where all the data structures were encoded in
JSON or XML or whatever, we can use the same scheme without having to
revise the version number at all.

Verifiers need to know what they are verifying of course. But that is
usually obvious from the context and is easily specified in any
situation where it isn't.

The impact of this approach on PGP is almost nothing. All it means is
you have to push the string "application/pgp-key-binary:" or whatever
through the hash before the data.

We are certainly going to change the algorithm. So this is not
breaking backwards compatibility.

Making this a fixed string rather than a header eliminates the need
for canonicalization and stops people turning this into a Christmas
tree for their favorite hacks.

I am also thinking that overloading the hash registry is a really bad
idea. To be useful, fingerprints really need to be as consistent as
possible. It is really desirable that everyone uses the same algorithm
(with possibly different truncation lengths).

32 different possible values is probably enough and consumes one
character in Base32. We might want to choose a memorable character (P,
X, Q, whatever). I am assuming a base of 0.

Using truncation rather than the 'spongeworthy' property of SHA3 means
that it is obvious at a glance that the following all relate to the
same thing:

95 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA

145 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T

195 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM

245 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM-YHE4T-SYJQM

95 bits is arguably borderline for a fingerprint but it is about the
limit of what can be fitted onto a business card.

Now lets imagine that I have someone's business card in front of me
and I try to send them an email that I really want to be sent
encrypted and the machine comes back telling me it has verified the
sender key as AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM-YHE4T-SYJQM.
I can look at the card and quickly see that the first five blocks are
correct and lock this into my personal key store.

Given timing, I suggest we define code points for BOTH the SHA-2-512
and SHA-3-512 algorithms now and decide which to make mandatory at a
later date. We should have exactly one mandatory algorithm and exactly
one backup for all crypto algorithms.

---

From: Jon Callas <[email-masked]>
Date: Wed, 15 Apr 2015 12:11:13 -0700

There was a proposal that floated around that defined an extended fingerprint to be an algorithm number followed by the actual bits.

For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary representation. There's an obvious way to truncate that as well -- just decide if you truncate little-endian or big. (Personally, despite being a little-endian bigot, this is a place where network byte order is even to me the obvious win.)

The major advantage of this is that you can define it and then you never have to change it again. We don't have to have any arguments over what hash function is proper to use, etc. An implementation can decide to support or not support whatever.

	Jon

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 15 Apr 2015 22:04:22 +0200

On Wed, 2015-04-15 at 12:11 -0700, Jon Callas wrote:
> There was a proposal that floated around that defined an extended
> fingerprint to be an algorithm number followed by the actual bits.
> For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary
> representation. There's an obvious way to truncate that as well --
> just decide if you truncate little-endian or big. (Personally, despite
> being a little-endian bigot, this is a place where network byte order
> is even to me the obvious win.)
> The major advantage of this is that you can define it and then you
> never have to change it again. We don't have to have any arguments
> over what hash function is proper to use, etc. An implementation can
> decide to support or not support whatever.
+1

But shouldn't one define better the number to be either a string?
Sure a one byte number with 255 possible future algorithms seem plenty
enough, but people also once thought that about 32bit IPv4 addresses,
two digit year numbers and so on.

:-)

Cheers,
Chris.

---

From: David Shaw <[email-masked]>
Date: Wed, 15 Apr 2015 16:21:22 -0400

> two digit year numbers and so on.

Using a string is fine, but even with numbers, there is no rule that the number has to be a single byte.  After enough years and algorithms added, it could be "100000:ABCDEF0123..."

Whether it's a string or number, there has to be a list for what number/string means what algorithm.  Once you have a list, it doesn't really matter if it's a string or a number.

David

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Apr 2015 16:46:22 -0400

>> is even to me the obvious win.)

The ni scheme I linked to does essentially that. What we are
discussing here is essentially the same thing only with a slightly
different syntax. It is not necessary to separate the algorithm ID
from the fingerprint.

> two digit year numbers and so on.

It isn't necessary. We just use the same trick Ken Thompson used to create UTF8.

Let us say we choose the first 5 bits to be the algorithm identifier
giving us a maximum of 32 code points

Now let us say that we have allocated 16 code points. This means that
any fingerprint which begins with the byte 00000xxx - 01111xxx has to
use one of those algorithms.

So when we get to code point number 17, we need to expand the
registry. instead of using just the first Base32 character we might
use the whole of the first byte which would give us 128 extra code
points. Or we might go to the first 10 bits which gives us 512 code
points.

I do not think it is at all likely we will exhaust the registry in our
lifetime. Since Rivest proposed MD4 in 1990 we have had four hash
algorithms that have been widely used, MD4, MD5, SHA-1 and SHA-2. If
we continue at the same pace it will take a century before we get up
to 16. And that is actually a pretty conservative estimate. Since 1995
we have only had two algorithms.

If we start a registry now with SHA-2 and SHA-3 defined, I see no
reason to expect any need to assign a new code point for another 20
years. It is now 14 years since AES was published and nobody expects
it to be replaced any time soon. Some people, including myself, think
we should have a competition for a second, stronger algorithm for use
as a backup but that is an entirely different matter.

If we consume one code point every 20 years it will be 1600 years
before we need to worry about going beyond the first byte. And even if
we were trying to burn code points as quickly as possible I can't see
the gaps between the RFCs being less than 2 years. So thats still 160.

As with every other key size debate, people can always say we might
need more but there is a tradeoff. At present fingerprints need to be
short to fit in with our legacy paper based systems. While it is
unlikely that issue will disappear in the next ten years, I don't
expect it to be relevant in 30.

And yes, Bill Gates did suggest 640Kb as the limit for RAM in the IBM
PC. But that was not a mistake as some folk imagine. The chip had a
hard limit of 1024Kb of memory (it did not have paging) and that had
to include the RAM, the ROM and the video memory. Allowing more memory
for programs would have prevented the use of bitmapped graphics cards.
It was an engineering tradeoff.

So is this.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 15 Apr 2015 22:57:36 +0200

> different syntax. It is not necessary to separate the algorithm ID
So in that ni scheme, is the algorithm id then hashed along with the
data?

> It isn't necessary. We just use the same trick Ken Thompson used to
Sure that's possible as well, but I think they only did this do be
compatible with ASCII... and it makes probably parsing a bit more
complex.

> we have only had two algorithms.
Well... it's always difficult to predict the future... probably you're
right, but why making it not generic enough to be one the safe side if
we can.

As I've said, we've had that already plenty of times, that people
expected something to be never exhausted and then things came completely
different.
So one should perhaps learn from the past =)

Cheers,
Chris

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 15 Apr 2015 22:57:41 +0200

On Wed, 2015-04-15 at 16:21 -0400, David Shaw wrote:
> Using a string is fine, but even with numbers, there is no rule that
> the number has to be a single byte.  After enough years and algorithms
> added, it could be "100000:ABCDEF0123..."
But numbers would make problems if we're using the binary representation
of the fingerprint (i.e. not the ASCII/UTF8 version of it).
How should one know where the algo type ends, 0x0 can't be used since it
may be part of the number.
So it can only be done if the algo type is defined to be a (null
terminated) string.

Cheers,
Chris.

---

From: Jon Callas <[email-masked]>
Date: Wed, 15 Apr 2015 14:04:34 -0700

> two digit year numbers and so on.

Congratulations, you've just invented OIDs. ;-)

	Jon

---

From: ianG <[email-masked]>
Date: Wed, 15 Apr 2015 22:33:10 +0100

> So one should perhaps learn from the past =)

IP#s are one per person, approx.  We're trying to get away from one 
algorithm per person, not encourage it ;)

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Apr 2015 18:10:51 -0400

> So in that ni scheme, is the algorithm id then hashed along with the

ni is a URI scheme designed to be used under the covers. It is not
really what I would want for a fingerprint.

> right, but why making it not generic enough to be one the safe side if

Because introducing syntactic crud makes the identifier much less
convenient and the whole point of a fingerprint is convenience.

As I demonstrated, the proposed scheme has more than enough generality
for our purposes which are thoroughly understood.

> So one should perhaps learn from the past =)

That has happened when people who did not bother to try to understand
the issue refused to listen to the informed opinions of those who did.
While I am prepared to engage in a discussion over whether the basis
of my estimates is reasonable or not, 'other people got it wrong,
therefore you will' is not an argument.

Unlike the people you are citing, I have actually played a significant
role in the deployment of two global scale infrastructures. While I
can't claim to be infallible, I can claim to know something of what I
am doing.

If the need ever arises, we can always cut a completely new set of
fingerprint identifiers by just slapping a URI prefix on the front. Or
use ni.

All we are talking about here is the human readable form of the
identifier. PGP is going to be using the binary data, JSON and XML
apps using the same fingerprint format should use URIs.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 16 Apr 2015 00:51:32 +0200

On Wed, 2015-04-15 at 22:33 +0100, ianG wrote: 
> IP#s are one per person, approx.
Well, looking at v6, it's actually gazillions of IPs per person ;-)

>   We're trying to get away from one 
Okay than take another example... e.g. registered port numbers.

Cheers,
Chris.

---

From: ianG <[email-masked]>
Date: Wed, 15 Apr 2015 23:58:26 +0100

> Okay than take another example... e.g. registered port numbers.

We can take multiple train engines if you like, or multiple mars rovers 
... all of these have reasons for being multiples, we need many of them, 
as many as we can afford.

We only ever need one fingerprint hash.  The reason we're forced to have 
more than one is because they wear out at a rate of one per decade.

So, as per PHB, 10 is like the maximum we'll ever see.  Even the one 
we've got isn't broken.  Hence, the smallest byte possible is all that 
is needed, and we still have plenty of room for expansion to two bytes.

Now, some might say computers don't care, and they'd be right if 
callous.  Fingerprints are for humans tho, and humans do care, and 
humans get all twisted up over the extra bytes.

For my humanity, even one byte of algorithm identification is one too 
many.  I'm quite happy to define the new fingerprint with unusual lengths.

iang

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 16 Apr 2015 01:03:03 +0200

On Tue, 2015-04-14 at 20:36 -0400, Phillip Hallam-Baker wrote: 
> It makes no difference to the security
Are sure with that? I thought to have once stumbled across some paper
which seemed to imply that a truncation leads to issues.
Can't find it right now, though,... so maybe my mind just betrays me.

Cheers.

---

From: Werner Koch <[email-masked]>
Date: Thu, 16 Apr 2015 09:09:49 +0200

> Sure a one byte number with 255 possible future algorithms seem plenty

All algorithm identifiers have by spec values below 128.  If in any
future time this number space is not sufficient, we can resort to the
TLV or UTF-8 tricks of using the high bit to encode larger numbers.  It
keeps our fingerprints as short as possible but give theoretical space
to extend it.

Short fingerprints are important; if they are getting too long they
won't serve a purpose because the public key could be used directly.

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Thu, 16 Apr 2015 11:39:37 -0400

> So it can only be done if the algo type is defined to be a (null

It's easy -- all algorithms are currently defined to be <= 127.  If we
need more than that we can use base-128 encoding.  I.e., the number is
self-length-encoded in a way that you always know when the number ends.

The benefit of using a number instead of a string is that in the vast
majority (probably 99.999%) of use cases we'll be within the 127-value
limitation so we can encode it in exactly one byte.  A string will
always require at least two bytes, and that only gives you ~52 options.

-derek

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Apr 2015 13:46:26 -0400

Responding to multiple threads, trying to inject some precision... If
people are happy with what I propose here, I can get a draft started.

Just to be clear here, there are two separate places where an
identifier might occur:

Fingerprint = <Fingerprint-ID> + Hash ( <Content-Type> , <Data> )

Registering a new <Fingerprint-ID> code should be rare.

We don't yet have consensus on whether <Content-Type> is needed but it
certainly does not hurt and adding it solves many of the problems that
would otherwise require us to cut a new <Fingerprint-ID>.

In this scheme there is no need to cut a new ID for the PKIX KeyInfo
blobs I want for vanity crypto or for a SAML assertion or a JOSE key
blob. Which means that we also have complete flexibility to introduce
a completely different PGP key format at a later date.

[Detail]

To be precise, the option is

Fingerprint = <Fingerprint-ID> + H( <Content-Type>,  <Data> )

Where H (c, d) might be Hash (c +d) or Hash (c + Hash (d)). Using the
second form allows existing hashes to be converted to data
fingerprints. And that can come in handy in a lot of situations.

And for completeness, and to get everything straight, let me add:

DisplayedFingerprint = Base32-ify (Fingerprint , n)
TruncatedFingerprint = Trunc (Fingerprint, n)
URIEncoding = <Prefix-TBS> + ":" + DisplayedFingerprint

Note that there is no need for a length on the Displayed fingerprint.

The precise definition of Base32-ify (x, n) and Trunc (x, n) are not
yet specified.

Since Base32 encodes 5 bytes at a time and this is not a multiple of
8, there is a possibility that the fingerprint does not 'round trip'
between ASCII and binary forms. We can discuss that in detail later
and the question of whether we want to include some sort of checksum
on each block. If we are working in blocks of 5 characters, we might
want to use one bit for a running parity which has the pleasing effect
that each 5 character block represents 3 binary bytes.

<Fingerprint-ID>

At the moment the consensus proposal seems to be that Fingerprint-ID
is a numeric code that has exactly two entries. I suggest:

96: SHA-2-512
144: SHA-3-512

These numbers are not completely random. While the codes themselves
don't matter, using 0x60 and 0x90 has the pleasing and convenient
effect that SHA-2-512 fingerprints will always start with the letter M
(for Merkle-Damgard) and SHA-3-512 fingerprints will always start with
the letter S (for Spongeworthy).

<Content-Type>

I suggest that we use a choice of either

<Mime-content-type> + ":"
<urn>

This does not need to be a closed registry. The only requirement is
that the identifiers be unique and unambiguous. In normal
circumstances the content type for a key in PGP format is simply
'application/pgp-key'.

Allowing any entry in the URN repository means we get OIDs for free:

Lets say you want to use Ed2555 and this does not (yet) have a PGP
number assigned:

http://www.ietf.org/mail-archive/web/openpgp/current/msg07321.html

The text representation of the OID is 1.3.6.1.4.1.11591.15.1. So the
content type identifier is "urn:oid:1.3.6.1.4.1.11591.15.1"

This approach is preferred over using the byte encoding of the OID
because it does not require an encoder.

People can use any crypto they like including experimental and vanity
crypto without any impact on the IETF or IANA.

<Prefix-TBS>

The group has not discussed a URI form of the fingerprint but
allocating a URI for any identifier should be routine. Given the key
role fingerprints play, it is obvious someone will want a URI
somewhere. Just defining the URI is probably enough to use the key
with SAML for example.

If specified, there should be exactly one prefix and it is probably
best if we define something that is neutral. Something like 'Uniform
Data Fingerprint' (UDF).

Security considerations:

Fingerprints are brittle. While it is very difficult to cause a
collision even with a short fingerprint, unintended variations in the
calculation of a fingerprint can occur unless great care is taken.

---

From: ianG <[email-masked]>
Date: Fri, 17 Apr 2015 15:24:47 +0100

On 16/04/2015 18:46 pm, Phillip Hallam-Baker wrote:

> is a numeric code that has exactly two entries.

I don't know why we'd do both.  I suppose it's because hashes are like 
mountains and seeing them, we have to walk up them.  If there are two, 
we have to walk up and down twice...

> I suggest:

In the unfortunate event that we allocate multiple hashes + numbers, 
then I suggest we also allocate an X that is to be used for closed, 
internal trials.  This way, people are less likely to homestead spots 
and then come to us with arguments about how they're using ABC and they 
don't want people to change and bla bla.

> the letter S (for Spongeworthy).

OK, cautious nod to the letters - although it would be pleasing if you 
could point to a web calculator that could lay out the conversions for 
those of us who've forgotten how do to hex-b32-ascii-dec in our head ;)

What is the extension strategy for when we've exhausted the 256 
possibilities in a byte?

(Yes I realise you didn't specify a byte, but I guess that's part of the 
question.)

We ourselves don't want more than a handful.  But if we open up the 
fingerprint standard to a wider audience, then austerity will be out the 
window.  What's our approach of the TLS group decides they want to add a 
few hundred?

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Apr 2015 12:59:43 -0400

On Fri, Apr 17, 2015 at 10:24 AM, ianG <[email-masked]> wrote:
> mountains and seeing them, we have to walk up them.  If there are two, we
> have to walk up and down twice...

It is very much the settled consensus now that proliferating crypto
algorithms is a bad thing. The security of a system is determined by
its weakest algorithm, not the strongest. So we need the number of
algorithms to be as small as possible.

The number of algorithms has to be greater than zero.

Systems that have a single algorithm that cannot be changed have also
resulted in real problems. People tend to hard code code paths in the
expectation that they will never change.

So for all those reasons, the approach that seems to work best as the
general rule is exactly one mandatory to implement and exactly one
recommended alternative as a backup.

Given that we only have two hash algorithms that are likely
candidates, the only real discussion is which of the two should be
mandatory to implement for use in OpenPGP. Which is a discussion we
can and should defer to later. Right now I can make a fairly good
argument that SHA-2 is the better pick based on the facts as they
stand today. I do not expect those facts to be the same in 18 months
time.

But right now I don't have SHA-3 implementations on my platform and
nor do many others. And I really don't want to spend time writing a
library or using code from other sources when I know that I am certain
to have a BSD/MIT licensed alternative from a well resourced vendor in
a short space of time.

>> I suggest:
>>
>> 96: SHA-2-512
>> 144: SHA-3-512
>
> In the unfortunate event that we allocate multiple hashes + numbers, then I
> suggest we also allocate an X that is to be used for closed, internal
> trials.  This way, people are less likely to homestead spots and then come
> to us with arguments about how they're using ABC and they don't want people
> to change and bla bla.

I don't think this is a problem. I very much doubt anyone will want to
argue for an algorithm that is not SHA-2 or SHA-3 and one of the main
reasons to choose the 512 bit versions and truncate is that it removes
the incentive to argue for one of the shorter versions.

The reason to pre-allocate the two spots now is precisely to remove
the incentive for homesteading. Right now I don't have SHA-3 but I
need something to test. We are definitely going to see homesteading if
we don't declare a spot for SHA-2.

> OK, cautious nod to the letters - although it would be pleasing if you could
> point to a web calculator that could lay out the conversions for those of us
> who've forgotten how do to hex-b32-ascii-dec in our head ;)

OK, using the Windows calculator in programmer mode:

96 decimal = 0x60 = 0110,0000
144 Decimal = 0x90 = 1001,0000

Base32 requires us to start with the most significant bits. So the
first characters are

01100 = 12 = 'M'
10010 = 18 = 'S'

The base32 encoding table is taken from: https://tools.ietf.org/html/rfc3548

This is not just the IETF encoding, it is I believe the same one that Phil Z.
proposed. And likely for the same reason - take the latin-1 alphabet first, then
discard the numbers 0, 1, 2 which are easily confused with O, I and Z.

I verified the analysis using these tools:
http://www.binaryhexconverter.com/decimal-to-binary-converter
http://tomeko.net/online_tools/hex_to_base32.php?lang=en

Note that I am not certain yet that we want to use Base32 encoding without
modification. We might well want to use a parity scheme so that the
fingerprint can be verified as it is typed.

Lets say we are using a fingerprint with six character blocks:

aaaaa-bbbbb-ccccc-ddddd-eeeee-fffff

We could make the least significant bit of block A a parity check
on the other bits of block A, the least significant of block B a parity check
on AB, the lsb of C a check on ABC, etc.

This adds quite a bit of robustness and allows the value to be checked
as it is typed. It is not a perfect check of course. But it is something. And
it might just be that six character blocks with parity checking has higher
user acceptability than five blocks without. So this might well strengthen
the system net.

> (Yes I realise you didn't specify a byte, but I guess that's part of the

The general answer is 'reserve half the code points in the initial registry
to extension schemes'. So I see two options:

1) Prepend the identifier to the hash value, this obviously requires the
identifiers be issued in byte aligned increments.

Fingerprint = ID + Hash

If Fingerprint [0] < 128, the first byte is the algorithm identifier
If Fingerprint [1] < 196, the lower 14 bits of the first two bytes
   are the algorithm identifier.

This gives 128 possible single byte identifiers and 16384 two byte
values. I do not feel the need to specify additional expansion capability
since we never came close to exhausting a 16 bit algorithm registry for
a single algorithm when we encouraged multiple algorithms (suites
are a different issue)

2) Make the topmost 5 bits the identifier.

This is actually simpler to implement on many platforms as it is easier
to overwrite the first byte of a buffer than prepending another buffer
This discards data from the hash value of course but that is inevitable
when a fingerprint is used.

> window.  What's our approach of the TLS group decides they want to add a few
> hundred?

The TLS group have run into problems because suites are a bad idea.

Choosing the strongest versions of the best of class Merkle-Damgard and
Spongeworthy algorithms should remove the incentive to proliferate.
I have never been in a situation where someone has been saying 'we
need a weaker algorithms'.

The COAP folk might want to use a rubbish algorithm 'for speed' of
course. But the only algorithm they are likely to agree on is SHA1
and that isn't a lot faster and there are all sorts of reasons why they
are going to be unable to make it their only algorithm.

---

From: ianG <[email-masked]>
Date: Fri, 17 Apr 2015 18:14:52 +0100

> always require at least two bytes, and that only gives you ~52 options.

I rather use numbers than strings because a number is typically far more 
controlled, which is important in a security context.  With strings, 
there's always room for manouvre.  Leaving that room in means people 
will abuse it.

In a sense, it's almost a signal - a number means it has to be exact & 
checked.  A string means it's up to the application to display and some 
higher layer to figure out and interpret.  All waste, all opportunity 
for trouble.

iang

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 17 Apr 2015 13:46:21 -0400

On Fri 2015-04-10 09:23:18 -0400, Phillip Hallam-Baker wrote:
> On Fri, Apr 10, 2015 at 7:38 AM, Stephen Farrell <[email-masked]> wrote:
>>
>> Hiya, here's the 2nd thread, starting from DKG's list.
>>

I've been chewing over this discussion for a while, and i find myself
coming out fairly conservative on this.  I think i'm leaning toward
something like a 200- or 250-bit truncation of a strong digest (sha-512
is fine with me) over a common representation of just the key material
(SubjectPublicKeyInfo is fine with me, though i understand the ASN.1
concerns).  I am ok with inferring fingerprint version by structure.  I
don't much care about the difference between hex (base16) and base32 --
base32 reduces the length by 20% and it introduces some extra confusion
when communicating the fingerprint by voice.

Here's my attempt at clarification for why i find myself in this
position:

As an exercise, i tried to write down all the places that i expect
fingerprints to be useful.  Perhaps surprisingly, i think there are not
that many good use cases for fingerprints.  I came up with:

 0) keyserver lookup -- Finding or retrieving a key on the basis of a
    fingerprint.  If you have hte fingerprint, you should be able to get
    a copy of the key.

 1) key verification -- I have a copy of a key that i think might be
    yours, and i want to confirm that it's yours without a mechanized
    byte-for-byte comparison of the entire key.  This covers the "put it
    on a slip of paper for out-of-band confirmation" use case.

Are there actually any other use cases for the fingerprint?

Truncated fingerprints (which we call keyids) are also used in some
workflows, for example, by some tools to provide a human-accessible
handle for the key.  I don't think this is appropriate, as i've argued
elsewhere:

 https://www.debian-administration.org/users/dkg/weblog/105

I should also be clear: i *don't* think we want a many different
fingerprint variants.  I actually don't think we want more than one for
OpenPGPv5.  And i don't think we should choose a design that will
encourage people to pick their favorite fingerprint algorithm.

Fingerprints are useful because everyone uses the same one.  I don't
want to put have to two v5 fingerprints on my business card for the same
key to satisfy two different fingerprint camps.  the transition period
where i need a v4 fingerprint and a v5 fingerprint is going to be bad
enough, let's not make that persistent.  If i put one form of a v5
fingerprint on mine, and you put another, then any implementation that
copes with them (keyservers; manual verifiers) will have to understand
and work with them both.

The fingerprint decisions i made came from these factors:

 * version detection: how do we know that this is fingerprint format X?

 * truncation: how long is the fingerprint?  Is it acceptable to
   truncate further?  If so, by how much?  Werner's note is also
   relevant here as we move to ECC keys:

     > Short fingerprints are important; if they are getting too long
     > they won't serve a purpose because the public key could be used
     > directly.

   If we use a 256-bit fingerprint for a 255-bit curve25519 key, what's
   the point?

 * digest algorithm; we need preimage resistance; we do not need
   collision resistance.

 * what material gets digested; at a minmum, this is:
    - the algorithm for the key (incl. any parameters)
    - public key values (mpi's, bitstrings)
      it's not clear to me that there is any advantage to adding
      anything else here.

 * what structure is used to frame the material before digest; v4 uses
   an approximation of the public key packet format as a framing device,
   but this ends up including the creation date.  we could use the ASN.1
   SubjectPublicKeyInfo format (as phb suggests), though some people are
   (probably understandably) allergic to ASN.1.  Or we could make up our
   own structure, yuck!

 * human-representable form of the digest: e.g. hex, base32, common
   hyphenation patterns, etc.  there are legibility/usability factors
   here that i don't know enough to comment on.

Did i miss any factors?

    --dkg

---

From: Derek Atkins <[email-masked]>
Date: Mon, 20 Apr 2015 11:17:22 -0400

> Are there actually any other use cases for the fingerprint?

Specified Revokers use the (binary) full fingerprint, not the
(truncated) keyID.

>  https://www.debian-administration.org/users/dkg/weblog/105

It's important to have a keyserver API to lookup a key based on the
keyID in a signature.

>  * version detection: how do we know that this is fingerprint format X?

Leading byte with the FPVNo.  (FingerPrint Version Number)

>  * digest algorithm; we need preimage resistance; we do not need

So you're saying we can stick with SHA1?  ;)

>       it's not clear to me that there is any advantage to adding

I still believe that the creation time (and key expiration time, if it
exists) should be included.

>    (probably understandably) allergic to ASN.1.  Or we could make up our

Personally I like the current framing (because I do believe the creation
date should be included).

>    here that i don't know enough to comment on.

I prefer either hex or base32.

-derek

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 20 Apr 2015 17:25:33 +0200

> exists) should be included.
I think the same accounts for the key usage flags. Or actually, we
should perhaps make primary keys to be generally certifying-only keys.

And specifying a expiration time (even if it's 0) should be mandatory.

Cheers.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 20 Apr 2015 11:35:06 -0400

> should perhaps make primary keys to be generally certifying-only keys.

I generally agree with this, modulo what I have written in
draft-atkins-openpgp-device-certificates that allows encryption-only
primary keys.

-derek

---

From: Vincent Breitmoser <[email-masked]>
Date: Mon, 20 Apr 2015 17:54:11 +0200

> Specified Revokers use the (binary) full fingerprint, not the

I would motion for designated revokers to use (or include) the full
public key. This allows verification of a revocation signature in
combination with a designated revoker certificate *without* the
requirement to retrieve, parse, and verify an entire other key, allows
supporting designated revokers without requiring the possibility to
retrieve keys during import. There are two downsides to consider:

- increased packet size. not by an order of magnitude though, and if
  this is a concern the designated revoker certificate can be published
  together with the revocation only

- incomplete verification of the designated revoker's key. if we fetch a
  key by fingerprint, it might have been revoked before the revocation
  was issued, invalidating the revocation signature. this still leaves
  the key in question in a very fishy state and it probably makes more
  sense than not to consider it revoked.

Another alternative would be adding the public key to the revocation
certificate as a subpacket.  Both options have the same downsides, and
none of them stands out as the natural choice to me.

 - V

---

From: Vincent Breitmoser <[email-masked]>
Date: Mon, 20 Apr 2015 18:18:55 +0200

On 20 Apr 2015, Christoph Anton Mitterer wrote:
>> I still believe that the creation time (and key expiration time, if
>> it exists) should be included.
> I think the same accounts for the key usage flags.

Definitely in favor of including key usage flags. I can't think of a
reason these should ever be mutable over the lifetime of a key, at least
in the incarnation of the key material identified by one fingerprint.

> Or actually, we should perhaps make primary keys to be generally
> certifying-only keys.

Not sure about that, primary keys with more than C capability can have
legitimate use cases.

 - V

---

From: Werner Koch <[email-masked]>
Date: Mon, 20 Apr 2015 20:37:35 +0200

> enough, let's not make that persistent.  If i put one form of a v5

I do not think that this is major problem.  For many years we had to
cope with the v3 and v4 fingerprints.  It was easy to explain that they
are similar but that 4-hex-nibble fingerprint are used with modern keys
and most folks like to be modern or own modern keys.

> copes with them (keyservers; manual verifiers) will have to understand

Right, that is not going to work.  It is worse enough that there is no
fingerprint standard for X.509 and we need to avoid it.  I understood
the proposal as to define a common fingerprint format which can be
re-used for a v6 key format.  The number of different ways to render a
string of hex digits is limited.

>    truncate further?  If so, by how much?  Werner's note is also
[...]
>    If we use a 256-bit fingerprint for a 255-bit curve25519 key, what's

BTW, there is another option: We could demand a specific subkey
(e.g. 256 bit ECDSA) which directly acts as the fingerprint.  This
fingerprint-key could then also be used for forthcoming distributed
naming systems.

>  * digest algorithm; we need preimage resistance; we do not need

Thus SHA-256 should be sufficient.

>       it's not clear to me that there is any advantage to adding

It has been discussed that a hard expiration date would be useful.

Having a creation date as part of the key allows to create a key from
the same key material but still be identified as a different key.  This
is for example useful if the key material is on a smartcard and you want
(e.g. due to company policy) two independent looking keys.

>    here that i don't know enough to comment on.

For a long time I pondered with the idea to suggest base32 for a v5 key
but meanwhile I think that hex digits are easier to read and spell over
noisy channels. 

 08-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcdef0

would fit into one line and is still not too hard to read.

Shalom-Salam,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Fri, 24 Apr 2015 12:11:04 -0700

> On Apr 20, 2015, at 8:25 AM, Christoph Anton Mitterer <[email-masked]> wrote:
> 
> * PGP - S/MIME Signed: 04/20/2015 at 08:25:33 AM
> 

That's there now. When Derek says "if it's there" he means that it could be there. Syntactically, a zero means no expiration.

> 
> * Christoph Anton Mitterer <[email-masked]>
> * Issuer: CAcert Inc.

	Jon

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 02:35:58 +0200

On Fri, 2015-04-24 at 12:11 -0700, Jon Callas wrote: 
> That's there now.
Again, I don't see where this would be specified, except for the
deprecated v3 keys.

It's not part of the v4 keys, and I can't recall a section which makes
the key exp sig subpacket mandatory.

Anyway, the idea for making it mandatory has less to do with the
immutable vs. mutable question... it's rather based on the idea that we
should IMHO try to strengthen and clarify the whole message format.
E.g. I think we should convert the critical-bit to be a non-critical
bit. e.g. everything is considered critical unless explicitly specified
not to be.

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 02:42:58 +0200

On Mon, 2015-04-20 at 20:37 +0200, Werner Koch wrote: 
> For a long time I pondered with the idea to suggest base32
In principle I'd agree, especially as it nicely solves that 0 vs. O
issue.

> meanwhile I think that hex digits are easier to read and spell over
> noisy channels.
Hmm,... well I have no strong opinion,... but I think with e.g. the ICAO
alphabet it should work fairly well - I mean this was made more or less
for exactly that purpose.

> would fit into one line and is still not too hard to read.
And what if we'd already move to a 512 bit hash? E.g. SHA3-512.

Also consider that people often write this to business cards and that
like, were space is more limited than on a computer system's line (e.g.
the 80 chars of traditional terminal).

Cheers,
Chris.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Sat, 25 Apr 2015 02:56:58 +0200

> Not sure about that, primary keys with more than C capability can have
But that in case makes a valid use case where one wants to change the
the usage flag.
E.g. consider you have a private key where you want to add/remove enc or
signing flags.

IMHO, having subkeys is extremely cheap, probably even for very lowcost
embedded systems (don't even the OpenPGP cards support multiple keys
these days).

So there should be no reason where you every really need to change the
usage of an existing primary/sub key,... just create a new one (which is
probably even more secure).

It may be even possible to let the keyservers benefit from this:
Conceptually the keyservers should never remove primary keys (and their
direct signature) for security reasons (this would mean one would also
loose revocations, etc.)
For historical reasons, I'd also say, they should never remove signing
subkeys (because another user may need it 20 years later to verify a
signature).
But in principle there's no strong reason to keep the enc keys after
these have been revoked or expired (of course the revocation and the
subkey binding sigs must be kept).

Cheers,
Chris.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 27 Apr 2015 10:24:11 -0400

Hi,

> the key exp sig subpacket mandatory.

I read 4880 again and I'm afraid I was wrong and you are correct; the
key expiration was removed in v4 keys.

Having the subpacket mandatory doesn't help, because the self-sig can
always be reissued.

> bit. e.g. everything is considered critical unless explicitly specified

With it being in the self-sig there is no way to make it immutable.  I
could take the top-level key packet and create a new self-sig on it with
a different key-expiration subpacket.  All other signatures on the key
will remain valid (because they don't include the self-sig), and the key
fingerprint wont change (because it doesn't include the selfsig, either).

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 27 Apr 2015 17:03:41 +0200

> key expiration was removed in v4 keys.
No worries :) 

> Having the subpacket mandatory doesn't help, because the self-sig can
Sure,.. I meant the key packet shouldn't be designed in such a way, that
"absence" of the expiration time field is interpreted as "infinite".
That one zero field doesn't harm and I think it's generally better to
explicitly store things.

> fingerprint wont change (because it doesn't include the selfsig, either).
Sure... that's what I'm trying to write since some days now :-)

---

From: Daniel Ranft <[email-masked]>
Date: Mon, 27 Apr 2015 18:03:23 +0200

// doing my premiere here on the mailing list :)

> the 80 chars of traditional terminal).

You could use a QR code for at least the business cards? We discussed something like that on the OpenPGP summit a couple of days ago.
The related documentation drafts can be found here: https://github.com/ModernPGP/QR

- --
Verschlüsseln Sie Ihre E-Mails mit gpg4o für Outlook | Encrypt your email with gpg4o
Meinen PGP-Schlüssel finden Sie auf hkp://pgp.mit.edu. Key-ID: A2B4B3EF
- -------------------------------------------------------------------------------------------------------------------
Daniel Ranft
Softwareentwickler

Giegerich & Partner GmbH  
Robert-Bosch-Straße 18 | D-63303 Dreieich
Tel. +49 6103 5881-50 | Fax +49 6103 5881-49
[email-masked] | http://www.giepa.de 

Geschäftsführer: Dipl.-Ing. (TU) Hans-Joachim Giegerich
Amtsgericht Offenbach/Main | HRB 33236

TeleTrusT Quality Seal  “IT Security made in Germany” www.teletrust.de/itsmig
- -------------------------------------------------------------------------------------------------------------------

---

From: Werner Koch <[email-masked]>
Date: Mon, 27 Apr 2015 18:23:17 +0200

> You could use a QR code for at least the business cards? We discussed something like that on the OpenPGP summit a couple of days ago.

During one session it was remarked that one of the larger participating
projects got research results on QR codes indicating that QR codes don't
work reliable for mass deployment.  Thus for backing up and syncing
private keys they use a letters and digits based code to seed a PRNG.

Shalom-Salam,

   Werner

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 27 Apr 2015 18:27:26 +0200

> The related documentation drafts can be found here: https://github.com/ModernPGP/QR
I personally don't like that very much:
Typically one will use his smartphone for scanning this, so one entrusts
an pretty insecure system (mostly running some proprietary closed code)
with telling you the true value of the FP.

Cheers,
Chris.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Apr 2015 13:58:08 -0400

> private keys they use a letters and digits based code to seed a PRNG.

I can't see the point of that.

Encryption of the private key works fine. We have many resources that
allow us to deposit chunks of data in the cloud and rely on them being
available in the future.

Note that here we are talking about THE cloud, not A cloud. While
there are many clouds for computing, archival storage of vital data is
an example of an application where the network effects come into play.

Encrypt the private key(s) under a symmetric key, split the symmetric
key into as many shares as you need. Print out the key shares on paper
and you are done.

---

From: Werner Koch <[email-masked]>
Date: Mon, 27 Apr 2015 22:34:18 +0200

> I can't see the point of that.

The point is that typing

  A3HT-378G-WE7Q-....

works more reliable than scanning QR codes.

> key into as many shares as you need. Print out the key shares on paper

Nobody talked about key splitting.

Salam-Shalom,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Apr 2015 16:57:40 -0400

> Nobody talked about key splitting.

It can be added to either.

The difference between the approaches is as follows

With generation from seed we take a secret s and then generate K(s)
which requires the generation of the key to be completely
standardized.

With encryption of the private key we generate and dispose of a random
number p and use it as a seed, generate K(p) and then archive an
encrypted version under symmetric key s.

I prefer the second reason because it can be applied to any public key
algorithm and does not require a specific generation approach. Now
admittedly when we get to ECC algorithms, generation is not exactly
complicated.

---

From: ianG <[email-masked]>
Date: Tue, 28 Apr 2015 12:16:08 +0100

>     here that i don't know enough to comment on.

Just on that, I recently went through an exercise where phones get 
introduced to phones.  Once introduced the phones can speak to servers 
directly naming their new friends and get high quality information in 
dense cryptographic form.  Users need not be bothered by the arcania.

But two people meeting for the first time is a bother, especially as 
there are no presentations of cryptographic information in the app at 
all, and we can't rely on the various bluetooth and so forth local 
interactions.

We tried some variants, and in the end, I settled on a 4-letter base26. 
  It is created on one phone (register on server) and typed into the 
other phone (lookup on server).

The base26 alpha was chosen because many phones have tiny keyboards 
which require hitting a meta key to get out to numerics.  This made the 
Base32, hex and other mixed alphanumerics a pain, it about doubled the 
workload and more than doubled the error rate.

A count of 4 characters was settled on because it was enough to provide 
some discrimination but not enough to seriously challenge the users. 
Users found 6 characters to be a bit testy (I include myself in this) 
whereas people felt that if they couldn't handle 4 characters felt they 
could blame themselves for the errors not the system.

iang

ps;  The codes themselves once created are only valid for an hour, 
suitable for a face to face meeting, so there is a lot more space available.

ps2;  4 uppercase letters was also used by the military back in the old 
pencil & paper tactical codes days.  At least my military.

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Tue, 28 Apr 2015 13:38:49 +0200

Speaking of that, we may want to specify a URL format for the
fingerprint which would facilitate the importing or checking of keys
through the intent mechanism (it has a different name in iOS, but it's
there). That way, QR codes would also become quite straightforward.

Cheers,

Daniel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 08:01:28 -0400

> there). That way, QR codes would also become quite straightforward.

Definitely. Which is why I want to have a format that means we only
need to go through this once...