Subject: [Cose] Thoughts about the use of AAD in COSE

From: "Jim Schaad" <[email-masked]>
Date: Fri, 12 Jun 2015 09:40:42 -0700

I have been thinking about the use of AAD in some different applications and
how the field was created during the JOSE WG process.

There are two different ways that AAD is expected to be supplied by
applications.  It is either going to be data that is carried as part of the
message structure, or it is going to be data that the application has
external from our message structure.  This would include both implied data
(i.e. information from a conversation that is carried forward but is implied
in the message) and information  that is part of the containing message but
not part of the COSE message.  

In the creation of JOSE, it was determined that applications might have
additional data they wanted to have verified and carried as part of the
message.  The obvious way to do this is to create an item that is placed in
the protected header field.  The problem with this for JOSE is that the data
might be binary rather than textual.  This means that the data would need to
be base64 encoded in order to put it into the protected header.  The
protected header is then base64 encoded when the message is created to be
sent.  This means that the AAD data supplied by the application is double
base64 encoded.  To prevent this, an independent field 'aad' was created to
carry the potential binary data instead.

Since COSE has the ability to carry binary data directly without doing the
double base64 encoding (actually without any base64 encoding), there is no
reason to keep the separate AAD data field for data that is carried in the
message.  Instead it can just be placed in the protected header section of
the message.  There is still a need to deal with the question of AAD that is
not carried in the message.  But that is a different issue.

One question that is open for discussion is "Should we define a generic
program supplied AAD protected header field, or should we say that this is
an application's responsibility?"

The reason not defining a generic field is that it makes more sense to keep
the pieces of the AAD data separated rather than having an extra encoding
level. 

Jim

---

From: Mike Jones <[email-masked]>
Date: Fri, 12 Jun 2015 17:13:40 +0000

I agree that there's no need to carry forward the JOSE top-level "aad" member, for the reasons you cite.

I also agree that there's no requirement to define a specific AAD header field, since any fields placed in the protected header will be integrity-protected, and there may be multiple such fields used by the application.  On the other hand, we could reserve a header parameter value for the application to use in the common case that it needs only one application AAD value - with the definition clearly saying that the contents are application-defined.

				-- Mike

-----Original Message-----
From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, June 12, 2015 9:41 AM
To: [email-masked]
Subject: [Cose] Thoughts about the use of AAD in COSE

I have been thinking about the use of AAD in some different applications and how the field was created during the JOSE WG process.

There are two different ways that AAD is expected to be supplied by applications.  It is either going to be data that is carried as part of the message structure, or it is going to be data that the application has external from our message structure.  This would include both implied data (i.e. information from a conversation that is carried forward but is implied in the message) and information  that is part of the containing message but not part of the COSE message.  

In the creation of JOSE, it was determined that applications might have additional data they wanted to have verified and carried as part of the message.  The obvious way to do this is to create an item that is placed in the protected header field.  The problem with this for JOSE is that the data might be binary rather than textual.  This means that the data would need to be base64 encoded in order to put it into the protected header.  The protected header is then base64 encoded when the message is created to be sent.  This means that the AAD data supplied by the application is double
base64 encoded.  To prevent this, an independent field 'aad' was created to carry the potential binary data instead.

Since COSE has the ability to carry binary data directly without doing the double base64 encoding (actually without any base64 encoding), there is no reason to keep the separate AAD data field for data that is carried in the message.  Instead it can just be placed in the protected header section of the message.  There is still a need to deal with the question of AAD that is not carried in the message.  But that is a different issue.

One question that is open for discussion is "Should we define a generic program supplied AAD protected header field, or should we say that this is an application's responsibility?"

The reason not defining a generic field is that it makes more sense to keep the pieces of the AAD data separated rather than having an extra encoding level. 

Jim

_______________________________________________
Cose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose