Subject: [COSE] Issue: External Authenticated Data

From: "Jim Schaad" <[email-masked]>
Date: Mon, 3 Aug 2015 08:18:02 -0700

I want to close the issue of allowing for externally provided information to
be included in the integrity computation.  This was added to the document in
order to support the ability of doing integrity protection over CoAP option
fields which appears to be a requirement from the ACE documents.

The current working document has expanded text dealing with what an
application needs to do in order to support this.  It also added the concept
to signed data, something that I originally did not think was needed.

Are there objections to including this concept in the COSE work?

Are there people who believe that this is not needed for the ACE work and
therefore should be removed?

Feel free to comment on the current text as well.

Jim

---

From: Mike Jones <[email-masked]>
Date: Mon, 3 Aug 2015 18:36:33 +0000

The way that I would suggest that we enable external authenticated data to be included in the integrity computations is to have the application place that data in the protected header.  I think that we should not provide a top-level field for this.  It's a corner case that will often not be used, and we shouldn't optimize for it.  Rather, we should optimize for the case where there is no externally provided integrity protected data, and allow it to be included in the set of protected header values, when needed.

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, August 03, 2015 8:18 AM
To: [email-masked]
Subject: [COSE] Issue: External Authenticated Data

I want to close the issue of allowing for externally provided information to be included in the integrity computation.  This was added to the document in order to support the ability of doing integrity protection over CoAP option fields which appears to be a requirement from the ACE documents.

The current working document has expanded text dealing with what an application needs to do in order to support this.  It also added the concept to signed data, something that I originally did not think was needed.

Are there people who believe that this is not needed for the ACE work and therefore should be removed?

Jim

_______________________________________________
COSE mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c7ab20cae993640ef3bf208d29c16af7c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5EJcqh0d676TU8H37EKcmUcCOGxvhOMgiNf9fYmxXzc%3d

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 3 Aug 2015 12:15:11 -0700

Have you read the ACE draft?

> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, August 03, 2015 11:37 AM
> To: Jim Schaad; [email-masked]
> Subject: RE: [COSE] Issue: External Authenticated Data
> 
> The way that I would suggest that we enable external authenticated data to
be
> included in the integrity computations is to have the application place
that data
> in the protected header.  I think that we should not provide a top-level
field for
> this.  It's a corner case that will often not be used, and we shouldn't
optimize for
> it.  Rather, we should optimize for the case where there is no externally
provided
> integrity protected data, and allow it to be included in the set of
protected
> header values, when needed.
> 
> 				-- Mike
> 
> I want to close the issue of allowing for externally provided information
to be
> included in the integrity computation.  This was added to the document in
order
> to support the ability of doing integrity protection over CoAP option
fields which
> appears to be a requirement from the ACE documents.
> 
> application needs to do in order to support this.  It also added the
concept to
> signed data, something that I originally did not think was needed.
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.
> org%2fmailman%2flistinfo%2fcose&data=01%7c01%7cMichael.Jones%40micro
> soft.com%7c7ab20cae993640ef3bf208d29c16af7c%7c72f988bf86f141af91ab2d
> 7cd011db47%7c1&sdata=5EJcqh0d676TU8H37EKcmUcCOGxvhOMgiNf9fYmxXz
> c%3d