paramaters x5c and x5t#S256 and GNAP key formats

[adeinega]

RFC 7517 (JSON Web Key) defines a JWK as

A JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value.

The current draft does it as

Value of the public key as a JSON Web Key [RFC7517].

that could be a minor editorial change. Although, at the same time, RFC 7517 defines parameters such as x5c and x5t#S256 which, for the most part, intersect with cert and cert#S256 key formats introduced in section "Key Formats". The question I have is what are the reasons to define these formats if the same goals are achievable with JWKs only?

Thus, we would use something like

{
  "key": {
    "proof": "jwsd",
    "jwk": {
      "kty": "RSA",
      "e": "AQAB",
      "kid": "xyz-1",
      "alg": "RS256",
      "n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY...",
      "x5t#S256": "qwerty",
      "x5c": [
        "end-entity cert (base64)",
        "intermediate cert (base64)",
        "root cert(base64)"
      ]
    }
}

instead of

{
  "key": {
    "proof": "jwsd",
    "jwk": {
      "kty": "RSA",
      "e": "AQAB",
      "kid": "xyz-1",
      "alg": "RS256",
      "n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."
    },
    "cert": "MIIEHDCCAwSgAwIBAgIBATANBgkqhkiG9w0BAQsFA..."
  }
}

That would allows to omit cert and cert#S256 and express the same (single) key in multiple formats. Furthermore, this could allow to have a bit more simplified approach for #105.

[fimbault]

Currently in section 7.1, the non-normative example shows a single key presented in multiple formats (PEM and JWK), but " If a key is sent in multiple formats, all the key format values MUST be equivalent" could be interpreted in different ways. Probably to be clarified.

So I guess there's different things to consider:

• do we restrict the list of key formats to JWK and suggest to use x5c ? I agree with @adeinega that it would simplify things, and it brings some advantages in terms of key identification (kid, etc.). The thing we need to be careful about is that the JWK RFC puts x5c it as optional, so we might have to put some wording as to when that is expected for our own use cases.
• how do we deal with the multiple formats? Do we already support it in the core or only through a registry ?

I also agree there's more importance in making key rotation easy than is supporting multiple formats, at least in the core.

[jricher]

I decided originally to not just use JWK in the XYZ drafts for a few reasons:

1. Not every signature method is JOSE-based, and so the kty and alg parameters don't map to all use cases. Taking a deep dependency on JOSE here doesn't make sense to me, though it should definitely be allowed as an option.
2. Some systems are going to want to use only certificates, and so wrapping the certificate in a JWK is awkward, at best.
3. Some keys are going to be fetchable, like DID URLs for key parameters. That's not specified in the core but the goal of the key object is to make sure the recipient can get the keying material, so it fits.
4. There are other key value formats out there beyond JWK and X509, and we shouldn't preclude them by wrapping them all in JWKs. COSE Keys immediately come to mind, and there are others.

Now don't get me wrong, I love JWK and having a structured format to carry bare public keys is an amazing innovation -- but we can't assume that's what everyone in the world is going to use for this very fundamental part of the negotiation process.

With all of that in mind I'm still in favor of having the certificate separate so that we can do:

"client": {
  "key": {
      "proof": "httpsig",
      "cert": "MIIEHDCCAwSgAwIBAgIBATANBgkqhkiG9w0BAQsFA..."
  }
}

[IDmachines]

+1

[fimbault]

Those reasons are valid, although pretty much everything could be dealt with through a proper extension mechanism (which I think is important).
Regarding http message signature, I guess that's the same debate as httpsig JWA?.
The main advantages I'd see in limiting the default would be to avoid the additional complexity of knowing whether one alg is implemented or not (which becomes an issue if we allow several possibilities), and focusing more on rotation etc.

Fetchable keys could work differently though, and so having that possibility in the core would make sense.

[jricher]

@fimbault I haven't checked in the HTTP Sig changes that will allow JWA algorithms yet, but I'm working on it. :) This would be independent of the key format, though.

[fimbault]

Can't depend on JWK only, we need to keep the system open to a variety of formats (e.g. certs, etc.).

[adeinega]

@fimbault, @jricher, from my (very pragmatic) perspective, I'm more than fine with the support of a variety of different formats. Although, JWKs are still being too flexible. Hence, I suggest specifying if it's allowed to use and/or mix parametersx5c, x5u, x5t as well as jku or not. For example, The OpenID Connect Discovery spec tells that

The JWK x5c parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate.

which makes perfect sense to me.

Also, I still suggest changing the language used to describe what JWK is to

A JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value.

this is the definition provided by RFC 7517.

[jricher]

The key object is meant to represent one key, but it gives multiple ways to represent that key -- and I agree that we need to be really clear about the relationship between different parameters, including parameters inside the JWK object itself. I think it'll be helpful to pull in some of this discussion in the key representation section. We've got some language on multiple key formats in there already, and it needs to be expanded as raised in #18

[fimbault]

Closing as discussed last week on the mailing list