I would suggest that we forget the SPI proposal and fix the text for the key id
proposal in the three proposals.
kid and spi are actually doing the same.
The requirements for key naming are:
* The value is used to select the key
* It has to uniquely select the key.
* If you cannot find the key corresponding then this must lead to an error.
Here is from example text about key naming from RFC 4962:
Uniquely named keys
AAA key management proposals require a robust key naming
scheme, particularly where key caching is supported. The key
name provides a way to refer to a key in a protocol so that it
is clear to all parties which key is being referenced. Objects
that cannot be named cannot be managed. All keys MUST be
uniquely named, and the key name MUST NOT directly or
indirectly disclose the keying material. If the key name is
not based on the keying material, then one can be sure that it
cannot be used to assist in a search for the key value.
Here is the text from draft-ietf-jose-json-web-encryption-08:
4.1.10. "kid" (Key ID) Header Parameter
The "kid" (key ID) header parameter is a hint indicating which key
was used to encrypt the JWE; this can be used to determine the
private key needed to decrypt the JWE. This parameter allows
originators to explicitly signal a change of key to recipients.
Should the recipient be unable to locate a key corresponding to the
"kid" value, they SHOULD treat that condition as an error. The
interpretation of the "kid" value is unspecified. Its value MUST be
a string. Use of this header parameter is OPTIONAL.
When used with a JWK, the "kid" value MAY be used to match a JWK
"kid" parameter value.
My proposal would be:
----
4.1.10. "kid" (Key ID) Header Parameter
The "kid" (key ID) header parameter indicates which key and
associated parameters were used to encrypt the JWE.
This parameter also allows
originators to explicitly signal a change of key to recipients.
Should the recipient be unable to locate a key corresponding to the
"kid" value, they MUST treat that condition as an error.
The value in the "kid" MUST be treated as a a case sensitive string.
Use of this header parameter is OPTIONAL.
----
Here is the text from draft-ietf-jose-json-web-signature-08:
4.1.7. "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. Should the
recipient be unable to locate a key corresponding to the "kid" value,
they SHOULD treat that condition as an error. The interpretation of
the "kid" value is unspecified. Its value MUST be a string. Use of
this header parameter is OPTIONAL.
When used with a JWK, the "kid" value MAY be used to match a JWK
"kid" parameter value.
My proposal would be:
----
4.1.7. "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. Should the
recipient be unable to locate a key corresponding to the "kid" value,
they SHOULD treat that condition as an error. The interpretation of
the "kid" value is unspecified. Its value MUST be a string. Use of
this header parameter is OPTIONAL.
The "kid" (key ID) header parameter indicates which key and
associated parameters were used for the digital signature and
the keyed message digest computation of the JWS.
This parameter also allows
originators to explicitly signal a change of key to recipients.
Should the recipient be unable to locate a key corresponding to the
"kid" value, they MUST treat that condition as an error.
The value in the "kid" MUST be treated as a a case sensitive string.
Use of this header parameter is OPTIONAL.
----
Here is the text from draft-ietf-jose-json-web-key-08:
4.4. "kid" (Key ID) Parameter
The "kid" (key ID) member can be used to match a specific key. This
can be used, for instance, to choose among a set of keys within a JWK
Set during key rollover. The interpretation of the "kid" value is
unspecified. Key ID values within a JWK Set need not be unique. The
"kid" value is a case sensitive string. Use of this member is
OPTIONAL.
When used with JWS or JWE, the "kid" value MAY be used to match a JWS
or JWE "kid" header parameter value.
In some contexts, different keys using the same Key ID value might be
present, with the keys being disambiguated using other information,
such as the "kty" or "use" values. For example, imagine "kid" values
like "Current", "Upcoming", and "Deprecated", used for key rollover
guidance. One could apply a label to all keys where the
classification fits. If there are multiple "Current" keys, then in
this example, they might be differentiated either by having different
"kty" or "use" values, or some combination of both. As one example,
there might only be one current RSA signing key and one current
Elliptic Curve signing key, but both would be "Current".
My proposal would be:
----
4.4. "kid" (Key ID) Parameter
The "kid" (key ID) header parameter indicates the name of the key. The key
id must be unique for the specific context so that the recipient is able to
determine what key to use for a cryptographic operation without additional
information.
This parameter also allows originators to explicitly signal a change of
key to recipients. Should the recipient be unable to locate a key
corresponding to the
"kid" value, they MUST treat that condition as an error.
When the JSON Web Key payload is used together with a JWS or a JWE
and the "kid" value matches the value in the JWS
or JWE "kid" header parameter value then a key transport mechanism is
used, i.e., the key itself is attached to the JWS or the JWE payload.
-----
Notice that I changed the description for the JSON Web Key quite a bit since
this non-uniqueness description was a bit of nonsense.
If you have the ability to uniquely name the key using a kid then why wouldn't
you want to do it. This simplifies implementations.
Ciao
Hannes
On Feb 9, 2013, at 1:01 AM, Brian Campbell wrote:
> Maybe this was apparent from my comments/questions on the SPI proposal over
> the last couple days[1] but I have concerns that run the gamut from
> operational complexity and fragility to security problems. I believe strongly
> that, without considerably more analysis and specification detail, the
> current SPI work is much too risky to consider go in the current base JOSE WG
> drafts.
>
> As an alternative I'd like to request/propose that the SPI stuff be submitted
> as new I-D to help facilitate that additional discussion and analysis that I
> think it needs.
>
> Thanks,
> Brian
>
> [1] http://www.ietf.org/mail-archive/web/jose/current/msg01500.html
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
