Subject: Re: [Cose] Use of supplied authenticated information with AEAD algorithms

From: Mike Jones <[email-masked]>
Date: Sat, 6 Jun 2015 23:50:05 +0000

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-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, April 08, 2015 4:19 PM
To: [email-masked]; [email-masked]
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

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 6 Jun 2015 18:09:08 -0700

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-masked]] 
Sent: Saturday, June 06, 2015 4:50 PM
To: Jim Schaad; [email-masked]; [email-masked]
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-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, April 08, 2015 4:19 PM
To: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
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