+1 =nat via iPhone
Apr 20, 2013 3:34、John Bradley <[email protected]> のメッセージ: Yes using "alg":"spi" is cleaner and allowed by the current spec. I am not keen on omitting alg as a flag. On 2013-04-19, at 3:10 PM, Mike Jones <[email protected]> wrote: BTW, in terms of a “dedicated flag”, I’d previously suggested to Richard in private communication that one way for the SPI spec to do his cleanly would be to use “alg”: “spi”, rather than omitting the “alg” field entirely. The “spi” value would then be registered by the SPI spec in the algorithms registry - pointing back to the SPI spec. I personally think that this is cleaner than just omitting “alg”, since it maintains the invariant that all JWS and JWE representations have an “alg” value that is used to determine the processing rules. Cheers, -- Mike *From:* Russ Housley [mailto:[email protected]] *Sent:* Friday, April 19, 2013 10:51 AM *To:* Richard Barnes; Mike Jones *Cc:* Karen O'Donoghue; [email protected] *Subject:* Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? +1 On Apr 19, 2013, at 1:42 PM, Richard Barnes wrote: In principle, you could use the omission of the "alg" field as a signal that pre-negotiation is going on. However, that seems like not the most useful way to do it, and it conflicts with current practice -- namely the examples currently in the JWE and JWS specs. Those examples use pre-negotiation, but they also have an "alg" field. It's not very useful because it doesn't provide the recipient any clue about how to populate the missing fields. There's a semantic mis-match here as well, since a JWE with pre-negotiation is still a JWE, just an incomplete one. A dedicated flag field like SPI provides a clearer indication, and it also provides a hook that out-of-band protocols can use to connect in the pre-negotiated parameters. --Richard On Fri, Apr 19, 2013 at 12:06 PM, Mike Jones <[email protected]> wrote: Russ, I'm curious why you say that the "spi" field needs to be in the base spec. From a spec factoring point of view, even if SPI remains a completely separate spec and nothing is said in the base spec, there would be no confusion or conflicts, including for implementations. Here's why: - A header without an "alg" field is not recognized as a JWS or JWE, so there's no conflict there - A JWS or JWE can legally contain a "spi" header field and a registry is already provided to define the meanings of additional header fields, so there's no conflict there either Therefore, it seems like the separate spec could use the registry to define the meaning of "spi" in a JWS and JWE and could furthermore define the semantics of objects using headers without an "alg" field but including a "spi" field. No conflicts. And clear separation of concerns. Those wanting the SPI functionality could use it. Those not needing it would need to do nothing - which I think is as it should be. Best wishes, -- Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Russ Housley Sent: Friday, April 19, 2013 8:37 AM To: [email protected]; [email protected] Subject: Re: [jose] Feedback request on jose tracker issue #8: Should we add a "spi" header field? Combination of 1 and 2. The field needs to be in the base specifications, but the only rule that needs to be included in the base specification is an exact match of the identifier. Russ = = = = = = = = = = 1. Have draft-barnes-jose-spi remain a separate specification that could optionally also be supported by JWS and JWE implementations. 2. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as a mandatory feature. 3. Incorporate draft-barnes-jose-spi into the JWS and JWE specifications as an optional feature. 4. Another resolution (please specify in detail). _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
