Re: [saag] presentation format for hash of public key

The crypto-conditions specification defines a format for what is
effectively a public key fingerprint. It's what we call the  the
"condition".

It has 4 parts. A type (which determines how the fingerprint is generated)
a bitmask of features that would be required to validate the "fulfillment"
(signature) and a max fulfillment size (which indicates the max size of the
signature to allow a system to check (based just on the condition) if it
will be capable of validating the fulfillment later.

Latest draft is at:
https://datatracker.ietf.org/doc/draft-thomas-crypto-conditions/

I'm presenting the ID in Seoul if anyone is interested and will be pushing
a revised ID in the next few days to hopefully make it much easier to grok
the goals and usage.

This might not be what you're looking for exactly but I guess that depends
on the NEED for the public key fingerprint

On 25 October 2016 at 19:46, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> I'm getting that perhaps we have no specification here.
> Would one be useful?
>
> Paul Lambert <paul@marvell.com> wrote:
>     > In other forums I¹ve been using a hash of the public key
>     > and the associated cipher suite identifier (csi):
>
>     > uaid = h( csi , public_key )
>
>     > The hash used depends on the cipher suite identifier.
>
> Can you give me examples of this case?
> Who defines "csi" here?
>
> I'd ideally like something that works across uses (IPsec, S/MIME, TLS,
> etc.)
> not because I think reusing keys is a great thing, but because sometimes
> users put the wrong cert into the wrong place...
>
>
>     > The display representation is optimized for readability
>     > and recommends a base27 encoding. For example:
>
>     > Q4RM-K4FZ-T432-RZ4Q-ZA88-YQ94
>
>     > The base27 encode/decode string is:
>     > b27string = 'ABCDEFGHJKMNPQRTWXYZ2346789'
>
>
>     > This string is selected to remove visually the
>     > ambiguous characters:
>     > 0O 1Iil 5S UV
>
>     > The separator characters (Œ-Œ) are optional, but recommended.
>
>     > The encoding allows input in lower or upper case, but the
>     > displayed representation should always be upper case for readability.
>
>     > Paul
>
>     > PS - example/reference code for base27 in:
>     > https://github.com/nymble/cryptopy/blob/master/cipher/encoding.py
>
>
>
>
>     > -----Original Message-----
>     > From: saag <saag-bounces@ietf.org> on behalf of "Salz, Rich"
>     > <rsalz@akamai.com>
>     > Date: Monday, October 24, 2016 at 1:56 PM
>     > To: Michael Richardson <mcr+ietf@sandelman.ca>, saag <saag@ietf.org>
>     > Subject: Re: [saag] presentation format for hash of public key
>
>     >> For what it's worth, OpenSSL does octet pairs separated by colon.
>     >> ; openssl x509  -fingerprint -in apps/server.pem
>     >> SHA1
>     >> Fingerprint=E8:4A:8E:20:76:4E:EF:0E:ED:BE:54:9F:91:8C:A4:F6:
> A2:B3:D1:04
>     >> -----BEGIN CERTIFICATE-----
>     >> MIID5zCCAs+gAwIBAgIJALnu1NlVpZ6zMA0GCSqGSIb3DQEBBQUAMHAxCzAJBgNV
>     >> ...
>     >> JBv+z1iQRueoh9Qeee+ZbRifPouCB8FDx+AltvHTANdAq0t/K3o+pplMVA==
>     >> -----END CERTIFICATE-----
>     >>
>     >> _______________________________________________
>     >> saag mailing list
>     >> saag@ietf.org
>     >> https://www.ietf.org/mailman/listinfo/saag
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>