It seems to me that without the "build up a table" language, there's no risk in the SPI proposal at all (see revised text below). Fails safe: If you get an SPI you don't know, you reject the object. The only risk is in the design of the key management protocols, which is a separate topic. Think of it like this split between RFC 4303 (ESP) and RFC 4306 (IKEv2, the key management protocol).
And I'm not sure how having it in an I-D makes any difference at all. --Richard -----BEGIN----- Section 4.1.X. "spi" Header Parameter The "spi" (Security Parameters Index) header parameter contains a base64url-encoded opaque byte string that labels a set of security parameters. This index is designed to enable the use of smaller headers in cases where entities use an out-of-band mechanism to negotiate cryptographic parameters. Entities supporting the use of the "spi" parameter maintain a table of cached security parameters. The maintenance of this table, e.g., how entries are added or removed, is done by the out-of-band key management protocol. Each entry in the table is indexed by an SPI value, and contains the following cryptographic parameters -- JWE header fields -- Encrypted Key -- Initialization Vector A JWE whose header contains an SPI value MUST NOT contain Encrypted Key or Initialization Vector components. It will thus have two base64url-encoded components, the header and the encrypted data. An entity receiving such a JWE reconstructs the full JWE by adding the cached header fields to the header, and adding the Encrypted Key and Initialization Vector components to the JWE. The reconstructed JWE is then processed as normal. If a JWE object contains an unrecognized SPI value, then the recipient MUST consider it invalid. -----END----- On Fri, Feb 8, 2013 at 6:01 PM, Brian Campbell <[email protected]>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
