You would have a potential flexibility issue of not having both types, other than that it would not be an issue.
From: Mike Jones [mailto:[email protected]] Sent: Saturday, June 06, 2015 4:50 PM To: Jim Schaad; [email protected]; [email protected] Subject: RE: [Cose] Use of supplied authenticated information with AEAD algorithms I'd overlooked this note earlier, so am just replying now. Jim, the case of detached additional authenticated data is an interesting one. Thanks for bringing this up. As an initial reaction, is there a reason this couldn't be handled in the same manner as detached payloads, as is done in JWS Appendix F http://tools.ietf.org/html/rfc7515#appendix-F, by omitting the AAD value in the transmitted form but including it in the integrity computation? -- Mike From: Cose [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Wednesday, April 08, 2015 4:19 PM To: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: [Cose] Use of supplied authenticated information with AEAD algorithms In the process of going through the use cases that have arisen for dealing with the COSE world in ACE. I have come to a realization that we have perhaps messed up the paradigm for additional data when dealing with AEAD algorithms. I don't think this is an issue for the world which JOSE came out of, but it may be an issue going in the future and is definitely an issue for the world of CoAP. In JOSE we make the assumption that all of the additional authenticated data is transmitted as part of the JOSE message. This makes sense because we did not have a large number of cases where it would not be. However, if one looks at the CoAP/ACE world this is not always true. In their case they are going to want to potentially have both authenticated data carried as part of the message, but also have authenticated data which is carried in the envelope. Case of sending a JWT, this would be the equivalent of needing to send the name of the originator in the headers and still wanting to have it validated as part of the token. (As opposed to just sending it in the body of the JWT.) I don't know of any cases currently where this is a problem for JOSE. I do know that it is a potential problem for COSE. Can any body think of a use case for JOSE where this paradigm needs to be fixed? Jim
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
