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.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp