Re: [SCITT] Constraints on unprotected data in receipt...

[Ray Lutz <[e-mail]>]

Hi Hannes et al:

The question being asked was regarding whether the entire public
key should be included in the receipt or just the key id. There are
several fields identified in either COSE or JOSE/JWK/JWS etc.
IETF docs that can provide either the public key(s) and/or x.509
certificate reference URI or entire encoded x.509 certificate.

I think the answer to this depends on the use case, esp for
cases where there is rapid interaction, then perhaps the COSE
data can be minimized and so then the "kid" may be okay.

But for the use case I am interested in, and I believe the use case
for SW and general data, then it is better to have the full public
keys as used (and it could be from the submitter or the scitt
machine) should be provided.

My conclusion is: I would see a lot of value in providing the full 
public key
in the receipt. Whether it is protected or not, I can't see that it actually
matters, and could easily be placed in either location. It is essentially
already protected because if it is altered, then the whole block won't
be consistent. I think it does not matter too much, because both can be 
easily read, and
it seems to do no harm to sign the public key as well.

The rule I proposed is that if you have
the receipt, you will be able to check it for internal consistency
without any other information, and to do that you need the actual
public key. But I will also allow that the rule may not apply to
all uses cases. In the use case I am interested, and I daresay this
is true for the SW use case, space is not a constraint and it is better
to be compete rather than rely on established state.

So to comply with this rule, then it cannot be the hash of the
public key and it can't be an id of the public key, because the
recipient may not be able to get any further information, i.e. in
an air-gapped environment. If the public key is sent, then the
recipient, or anyone in the future, can check the consistency
of the receipt, and prove that the receipt was signed by the
associated private key.

Once a connection is re-established, then the validity of the
public key can be checked. So I am for including the link to the
X.509 certificate that is associated with the key, if that is available.

But then again, I may have misunderstood what Henk was asking
me because my mind was wandering at the time and he had to
repeat it to me so I could have a chance of getting it.

I had to do some study of some of the docs. I include that here
in case it is helpful to anyone else. (please also tell me if I am
barking up the wrong tree!)

I see the JWK --JSON Web Key (RFC7517) provides a set of
public keys used to verify any JSON Web Token (JWT).

For the purposes of a receipt, I would guess just a single key
used to create the signature of the receipt is necessary, so it would be
like this JSON:


      {"keys":
            [
              {"kty":"RSA",
               "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
          4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
          tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
          QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
          SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
          w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
               "e":"AQAB",
               "alg":"RS256",
               "kid":"2011-04-29"}
            ]
          }


(I took this directly from
RFC7517 so it may have to be adjusted slightly). There is a "kid" i.e. 
key id
field in this key.

RFC7517 says:

    4.5.  "kid" (Key ID) Parameter

        The "kid" (key ID) parameter is used to match a specific key. This
        is used, for instance, to choose among a set of keys within a
    JWK Set
        during key rollover.  The structure of the "kid" value is
        unspecified.  When "kid" values are used within a JWK Set, different
        keys within the JWK Set SHOULD use distinct "kid" values.  (One
        example in which different keys might use the same "kid" value is if
        they have different "kty" (key type) values but are considered to be
        equivalent alternatives by the application using them.)  The "kid"
        value is a case-sensitive string.  Use of this member is OPTIONAL.
        When used with JWS or JWE, the "kid" value is used to match a JWS or
        JWE "kid" Header Parameter value.

So this ID is not guaranteed to be unique or very useful.  I can imagine 
that
Henk maybe was considering that it could be used to refer to this public key
by the SCITT receipt but I don't see that as being very reliable. But 
then I
definitely could have misunderstood what his question was.

I notice that in the COSE literature, the kid is commonly an email address.

It is worth reviewing how this would be used in conjunction with a JWS
JSON Web Signature (RFC 7515). I apologize for probably repeating what is
well known among the IETF community but it is helpful for my understanding.
I am repeating the example from RFC 7515:

    {"typ":"JWT", "alg":"HS256"}   <-- protected header
    (payload -- any content, but commonly expressed as JSON)
    signature

    The protected header is encoded by BASE64URL(UTF8())

    The payload is encoded by BASE64URL()

    And then, these two strings are joined by '.' and converted
    to ASCII(), and then the signature is created. So the
    entire signature block looks like this:

    eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

The protected header can include the jwk parameter and also the kid:
But it seems that the kid is only useful for specifying which one of the
provided public key should be used.

    4.1.3.  "jwk" (JSON Web Key) Header Parameter

        The "jwk" (JSON Web Key) Header Parameter is the public key that
        corresponds to the key used to digitally sign the JWS.  This key is
        represented as a JSON Web Key [JWK].  Use of this Header
    Parameter is
        OPTIONAL.

    4.1.4.  "kid" (Key ID) Header Parameter

        The "kid" (key ID) Header Parameter is a hint indicating which key
        was used to secure the JWS.  This parameter allows originators to
        explicitly signal a change of key to recipients.  The structure of
        the "kid" value is unspecified.  Its value MUST be a case-sensitive
        string.  Use of this Header Parameter is OPTIONAL.

        When used with a JWK, the "kid" value is used to match a JWK "kid"
        parameter value.

And we also see that they define several other items in the protected 
header,
including "x5u" the X.509 parameter that is actually a URI to the 
certificate.
The certificate is available at that URI. This is not very useful unless 
you can
access the URI, of course.

But more importantly for us (perhaps) is the "x5c" parameter which 
provides the actual
X.509 public key certificate which corresponds to the public key used to 
sign
the JWS.

But in my review of this, it seems like this has a lot of crud in it 
that maybe we
don't need for immediate review, and the "jwk" header would be enough, 
and it would
be perhaps acceptable to just have a reference to the x.509 cert.

Regarding the protected and unprotected headers.
Apparently, you can't use the _compact serialization_ if you use
unprotected headers.

I see this:

      JWS Protected Header
           JSON object that contains the Header Parameters that are
    integrity
           protected by the JWS Signature digital signature or MAC
    operation.
           For the JWS Compact Serialization, this comprises the entire JOSE
           Header.  For the JWS JSON Serialization, this is one component of
           the JOSE Header.

        JWS Unprotected Header
           JSON object that contains the Header Parameters that are not
           integrity protected.  This can only be present when using the JWS
           JSON Serialization.

And further:

        JWS Compact Serialization
           A representation of the JWS as a compact, URL-safe string.

        JWS JSON Serialization
           A representation of the JWS as a JSON object.  Unlike the JWS
           Compact Serialization, the JWS JSON Serialization enables
    multiple
           digital signatures and/or MACs to be applied to the same content.
           This representation is neither optimized for compactness nor URL-
           safe.

So with all this said, it appears that this same structure has been
re-applied using CBOR (RFC-8949) and that results in COSE (RFC-8152).

In particular, we find the kid described here:

        kid:  This parameter identifies one piece of data that can be used as
           input to find the needed cryptographic key.  The value of this
           parameter can be matched against the 'kid' member in a COSE_Key
           structure.  Other methods of key distribution can define an
           equivalent field to be matched.  Applications MUST NOT assume that
           'kid' values are unique.  There may be more than one key with the
           same 'kid' value, so all of the keys associated with this 'kid'
           may need to be checked.  The internal structure of 'kid' values is
           not defined and cannot be relied on by applications.  Key
           identifier values are hints about which key to use.  This is not a
           security-critical field.  For this reason, it can be placed in the
           unprotected headers bucket.

I look through the COSE doc and there are many ways this can be
used that differ substantially from what I see as the need for securing
fairly static chunks of data, like sw code files or binaries, that are
hashed and ultimately the merkle root is the item in the payload.

So in the end, I would see a lot of value in providing the full public key
in the receipt. Whether it is protected or not, I can't see that it actually
matters, and could easily be placed in either location. It is essentially
already protected because if it is altered, then the whole block won't
be consistent.

--Ray




























On 5/12/2023 3:38 AM, Hannes Tschofenig wrote:
> Hi Ray,
>
>
> before I share my view I have a few questions
>
> > The question is: Should the public key appear in the unprotected
> portion of the receipt, or can it be an id of the public key.
>
>
> Which public key are we talking about? The receipt is signed by the
> transparency service. Are you talking about the public key of the
> transparency service? It could also be the public key of the issuer? Or
> both?
>
>
> What do you mean by "id of the public key"? Are you trying to stay that
> there could also be a reference to the public key (in comparison to
> sending the public key directly)?
>
>
> Why would the public key be included in the receipt? Convenience for the
> recipient? Does it need to be the public key? Could be the hash of the
> public key? Could be a certificate or even a certificate chain?
>
>
> Ciao
>
> Hannes
>
>

-- 
-------
Ray Lutz
Citizens' Oversight Projects (COPs)
http://www.citizensoversight.org
619-820-5321