Subject: [lamps] pkix-keyinfo content type

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Aug 2019 15:10:01 -0400

I just applied for a provisional IANA media type 'pkix-keyinfo' for use in
computing UDF values and it occurs to me that I should make LAMPS aware of
the proposed use.

The spec is available here:

https://tools.ietf.org/html/draft-hallambaker-mesh-udf-05
http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html#n-pkix-certificates-and-keys

I strongly recommend using the second version as it uses the new HTML RFC
format to rended superscripts and subscripts etc.

In brief, the idea is to allow a single fingerprint format to be used to
encode any content type without semantic substitution attacks. So to take
the digest of a public key, we first generate the PKIX SubjectPublicKeyInfo
 :

   SubjectPublicKeyInfo  ::=  SEQUENCE  {

        algorithm            AlgorithmIdentifier,

        subjectPublicKey     BIT STRING  }

Then we take this octet stream <SubjectPublicKeyInfo> and calculate:

H ( "application/pkix-keyinfo:" + H(<SubjectPublicKeyInfo>) )

Where + is concatenation.

The reason the new content type is required is that there has not been an
application that would make use of a SubjectPublicKeyInfo fragment in
isolation before.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Aug 2019 20:24:04 -0400

Phillip Hallam-Baker <[email-masked]> wrote:
    > In brief, the idea is to allow a single fingerprint format to be used
    > to encode any content type without semantic substitution attacks. So to
    > take the digest of a public key, we first generate the PKIX
    > SubjectPublicKeyInfo :

    > Where + is concatenation.

This is not consistent with rfc5280 suggestion on how to create SubjectKeyIdentifier.
I've just been through how to specify a non-SHA-1 bound version of that, and
RFC7469 section 2.4 has suggestions.

As SubjectKeyIdentifier can be calculated by any suitable way and used if it
is present, it's only for the case that it is not present that is a problem.
Typically only CA:TRUE certificates are supposed to have it present.  I'd
like it to be present for all certificates.

So your construction would be:
   H ( "application/pkix-keyinfo:" + SubjectKeyIdentifier )

and I think that is fine, as long as it does not cause confusion.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [