Re: [jose] Proposal about the SPI proposal

[Hannes Tschofenig <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose