Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

From: Carsten Bormann <[email-masked]>
Date: Wed, 01 Jul 2015 09:12:55 +0200

Jim Schaad wrote:
> If one believes that it is only for use in constrained environments,
> then it is unlikely that there is a need for multiple recipients.

Actually, we do have scenarios with fan-out (both via proxy and per
multicast), and those are actually a strong motivator for object security.

The minimal-bytes alternative is to mix in the map entries for a single
recipient with those for the headers etc.  Both JSON and CBOR do not
have a defined sequence of map entries, so this means the recipient has
to piece the info together as it comes in.  We'd also need a separate
set of labels.  Not my favorite.

If we keep together that map, what we could still do is turn

       ? recipients => [+{COSE_encrypt_fields}]

back (we had something like that earlier) into

       ? recipients => [+{COSE_encrypt_fields}] / {COSE_encrypt_fields}

Saves that 0x81 byte in the single-receiver case.

Grüße, Carsten

---

From: Brian Campbell <[email-masked]>
Date: Wed, 1 Jul 2015 14:40:24 -0600

In my own experience with JOSE, the need for single recipient case is
overwhelming majority and the simplicity the compact serialization afforded
for that case are a major win. My own implementation supports only the
compact serializations (and thus only a single recipient or signature) and
it is used widely in my employer's products and services as well as being
open source. No one has ever even asked about the JSON serializations
(which support multiple signatures/recipients).

I understand the allure of consistently treating something that could have
more than one thing as always potentially having more than one.

But there is real value in making the most common cases simple, which
shouldn't be discounted.

On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann <[email-masked]> wrote:

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 1 Jul 2015 18:06:46 -0400

self.setChair(false); // n.b.: commenting as an individual contributor

I’ve got to agree with Brian on this point. To add my anecdote to the pile: I’ve been using the JOSE compact serializations in many production environments for years now, including contributing to several different open source implementations all of which support only the compact serializations. In that time I’ve never once had someone ask for support to the JSON serializations, or ask for multi-party signature or recipient support. I’d encourage folks in the COSE list to do a survey of the numerous JOSE libraries out there and see what features people are actually implementing and using. This ought to be a good indicator for what to focus on here, if you ask me.

To me, the JSON serializations in JOSE were always more of an academic exercise than something I saw being used in the real world. And for a simple case, they’re amazingly fantastic. When COSE was first being discussed, I had thought it was a foregone conclusion that it would focus on the compact serializations, considering that the entire goal here is to make JOSE *more compact* (and/or simple in various dimensions, given Carsten’s recent post). The compact serializations are very simple data structures and this is part of the reason that JOSE has actually taken off the way it has.

— Justin

self.setChair(true); // back to lurking

> On Jul 1, 2015, at 4:40 PM, Brian Campbell <[email-masked]> wrote:
> 
> In my own experience with JOSE, the need for single recipient case is overwhelming majority and the simplicity the compact serialization afforded for that case are a major win. My own implementation supports only the compact serializations (and thus only a single recipient or signature) and it is used widely in my employer's products and services as well as being open source. No one has ever even asked about the JSON serializations (which support multiple signatures/recipients). 
> 
> I understand the allure of consistently treating something that could have more than one thing as always potentially having more than one. 
> 
> But there is real value in making the most common cases simple, which shouldn't be discounted. 
> 
> 
> 
> On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
> Jim Schaad wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
>

---

From: Henrich Pöhls <[email-masked]>
Date: Wed, 1 Jul 2015 17:13:55 +0200

Dear Jim,

On 01 Jul 2015, at 06:31, Jim Schaad <[email-masked]> wrote:

> Part of the question is going to be where do you expect COSE to be used in the future.
>  
> If one believes that it is only for use in constrained environments, then it is unlikely that there is a need for multiple recipients.

Another application domain of COSE is integrity protection (ECCsignatures, MACs), right? 
I can think of use cases that benefit if you are capable of having a compact and easily parseable representation of signed signed data.
An example could be if you facilitate signatures to check if data originated at some sensor and also that it passed (and got vetted for) by another constrained device (e.g. data concentrator).

Just my thoughts. As I currently work towards finding a good representation for cryptographically signed JSON messages to be emitted by constrained devices, within the RERUM project, I was following the discussions here. 

Best, Henrich

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 02 Jul 2015 09:36:39 +0200

I'm not sure the JOSE experience translates to COSE.

In JOSE, there are two different forms, one array-based (a dot-joined
sequence of base64 encodings of the array elements) and one map-based.
COSE doesn't need that choice.

All I can read from the JOSE experience cited here is a strong indicator
that we want to go for arrays, not maps, at least for the outer structure.

Now whether that is shaped*)

[pr, un, ciph, [r1, r2]]

or

[pr, un, ciph, r1]

or

[pr, un, ciph, *r1]

(where *r1 means tha the contents of r1 is expanded right in place)

becomes less of a complexity argument:
[pr, un, ciph, [r1]]
really isn't that much more complex than
[pr, un, ciph, r1]
except for that one 0x81 byte wasted; in a pinch, we can also go for

[pr, un, ciph, r1, r2]
(which is another way of saying:
[pr, un, ciph, *[r1, r2]]
)

Making the array variable size disables JOSE's hack of using the array
size for distinguishing JWE from JWS.  But we don't need that; CBOR has
tags.

Grüße, Carsten

*) I'm leaving msg_type out here, see other thread.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 2 Jul 2015 11:13:58 -0600

Some things translate more directly than others :)

Indeed the dot joined base64url encoded segments are very array like. And
with CBOR that encoding and dot joining is unneeded.

The JOSE experience I'm suggesting this WG consider is the relative
simplicity afforded by compact serializations and the widespread use they
have seen.

Conceptualizing the compact serializations as arrays, you have this for
signatures/macs:

    [protected_header, payload, signature]

and this for encryption:

    [protected_header, encrypted_key, initialization_vector, ciphertext,
authentication_tag]

There's just a single recipient or just one signature. There's only one
place for headers and they are always protected. It's a (relatively) simple
and consistent processing model. The message can be processed or not.
There's real value in the simplicity.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Jul 2015 20:50:02 -0700

> -----Original Message-----
> From: Mike Jones [mailto:[email-masked]]
> Sent: Tuesday, June 30, 2015 5:46 PM
> To: Jim Schaad; [email-masked]
> Subject: RE: [Cose] Issue: Encoding for a single recipient or structure
> 
> Reply inline below...
> 
> > -----Original Message-----
> > From: Jim Schaad [mailto:[email-masked]]
> > Sent: Tuesday, June 30, 2015 5:15 PM
> > To: Mike Jones; [email-masked]
> > Subject: RE: [Cose] Issue: Encoding for a single recipient or
> > structure
> >
> >
> >
> > > -----Original Message-----
> > > From: Mike Jones [mailto:[email-masked]]
> > > Sent: Tuesday, June 30, 2015 3:45 PM
> > > To: Jim Schaad; [email-masked]
> > > Subject: RE: [Cose] Issue: Encoding for a single recipient or
> > > structure
> > >
> > > Hi Jim,
> > >
> > > Per your suggestion in response to my issue 1, I'm reviewing this
> thread.
> > > (I'm also including the original message below so WG members who
> > > joined the list when the WG was formed will see it.)
> > >
> > > First, let me ask a question to see if I correctly understand the
> > > problem
> > with
> > > your option (1) below.  JWE used "alg" for the key management
> > > algorithm and "enc" for the content encryption algorithm.  Likewise,
> > > JWE used "encrypted_key" for the encrypted key value and "ciphertext"
> > > for the encrypted plaintext.  Since there were no name collisions,
> > > all could live
> > in
> > > the top-level JSON object.  Whereas, your current COSE draft uses
> > > the equivalent of "alg" for both algorithms and the equivalent of
> "ciphertext"
> > > for both encrypted values, hence the label collisions you are citing
> > below,
> > > correct?
> > >
> > > If my understanding is right, then unless a JWE-like approach were
> > > adopted in which different labels are used for the different
> > > purposes, then yes, I agree that (1) wouldn't work.  Was this change
> > > to a single set of labels
> > the
> > > intended topic of the thread "[Cose] Issue:  Reuse the Enrypt
> > > structure
> > for
> > > recipients"?  I'm asking because a lot of the thread ended up being
> > > about
> > a
> > > different topic - whether the encrypted_key value would contain just
> > > an encrypted bare key or the equivalent of an encrypted JWK structure.
> > >
> > > You asked if I had anything new to add to the discussion.  I'll add
> > this...
> > >
> > > Just like for JOSE, I expect that many applications will implement
> > > only
> > the
> > > COSE features that they need.  For instance, JWT [RFC 7519]
> > > implementations only need to implement the JOSE Compact
> > > Serializations
> > > - not the JSON Serializations.  I expect there to be many COSE
> > > applications that will similarly only implement support for a single
> > > recipient.  This
> > would
> > > save on code size and be simpler.
> > >
> > > I believe that applications that only use a single recipient will be
> > > the
> > most
> > > common, hence the goal stated in my review to optimize for this case.
> > > Assuming we take your option (1) off the table and limit discussion
> > > to
> > only
> > > your options (2) and (3) below, then the choice seems to be between
> > > these effective grammars for the single recipient case:
> > > 	(2) recipients: {recipient_data}
> > > 	(3) recipients: [{recpient_data}]
> > >
> > > If you're only ever building code for the single recipient case,
> > > then
> > > (2)
> > is
> > > simpler.  But I agree that if you're using code that supports
> > > multiple recipients, then (3) is simpler, if somewhat less elegant.
> >
> > I am going to make the same challenge to you that I made to Derik at
> > one point.
> >
> > Can you provide code to show that option 2 is significantly larger
> > than option 3?
> 
> I'm not saying that there's a significant code size difference.  Maybe you
can
> tell us how much code would be removed from your implementation if you
> #ifdef'ed out the loops associated with producing and consuming the
> recipients arrays and just replaced it with code using a singleton array
value
> (option 3) or simply a recipient_data map value (option 2).  I admit up
front
> that there will be almost no code size difference between 2 or 3 if the
> implementation has been compiled to only support a single recipient.

The difference code size is harder to specify, since I switched from using
arrays to maps at the same time.  However the code fragment that deals with
all of the above cases (in the decode case) is

            // Recipients
            if (obj[index + 4].IsNull && (size == 5)) ; // No Recipient
structures - this is just fine
            else if (obj[index + 4].Type == CBORType.Array) {
                // An array of recipients to be processed
                for (int i = 0; i < obj[index + 4].Count; i++) {
                    Recipient recip = new Recipient();
                    recip.DecodeFromCBORObject(obj[index + 4][i], 0,
obj[index + 4][i].Count);
                    recipientList.Add(recip);
                }
            }
            else {
                //  We are going to assume that this is a single recipient
                Recipient recip = new Recipient();
                recip.DecodeFromCBORObject(obj, index + 4, size - 4);
                recipientList.Add(recip);
            }

Note that this code only deals with two cases - the rolled out case and the
array case.

> 
> My main point in raising this issue now is we're likely to hear the same
> thing about COSE that Richard Barnes heard from developers who were
> really using the JSON Serializations before we added the flattened data
> representation - that having to emit and parse a singleton array is ugly,
> awkward, etc.

This was raised because the people Richard was working with had a different
paradigm that most of us had when looking at how to process the message.
Personally I found this to be a huge complication in my code base to deal
with.  I would note that how they dealt with multiple recipients was to copy
things from the recipient to the base and treated it as a single recipient
case.  I think that this both made things more complicated and harder to
deal with that necessary.

Since all I cared about was a multiple case, I did an implantation that used
multiple promises to deal with all of the possible recipients at one time.
In doing so I found that I really wanted a first success promise which does
not exist.
 
> 
> This isn't a show-stopper to me, but now that there's a working group, I
> wanted to raise the issue for the working group to explicitly consider up
> front, rather than wait until people are using early implementations and
we
> hear back from developers "why couldn't this have been simpler in the
> simple case"?
> 
> 				Cheers,
> 				-- Mike
> 
> > Jim
> >
> > >
> > > What do others think about this tradeoff?
> > >
> > > 				-- Mike
> > >
> > > -----Original Message-----
> > > From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
> > > Sent: Thursday, April 30, 2015 3:59 PM
> > > To: [email-masked]
> > > Subject: [Cose] Issue: Encoding for a single recipient or structure
> > >
> > > Question: Flattened encoding -
> > > a)  Roll into parent map
> > > b)  Just be a map
> > > c)  Single element in array
> > >
> > > Discussion:
> > >
> > > A late addition to the JOSE specification was the ability to fold a
> > > single recipient map into the base encryption or signature map.
> > > This is doable because the keys for all of the maps in question are
> unique.
> > > This would
> > not
> > > be true if the issue on reusing the encryption body for the
> > > recipient structure is accepted.  This issue is being discussed in a
> > > separate mail
> > thread
> > > (but is current).  If arrays were to be used at the top level, one
> > > just
> > appends
> > > the elements to the end of the base structure  (see examples in the
> > current
> > > document).
> > >
> > > There are three different options that can be selected at this point:
> > >
> > > 1)  The recipient/signature map is folded into the
> > > encryption/signing message top level.  If we accept the change for
> > > using the same structure
> > for
> > > both the encryption body and the recipients, this is not a viable
> > > option
> > due
> > > to collisions of keys in the map.
> > >
> > > 2)  The recipient/signature element in the base map is permitted to
> > > be either an array of recipient/signature elements or a single
> > > recipient/signature map.  This option was rejected by the JOSE group
> > > as being too complicated for programmers to deal with.  The cost of
> > > this option is 2 bytes over option one.  (One byte for the
> > > recipients key, one byte for the map marker.)
> > >
> > > CDDL grammar would be:  recipients: [+[recipient_data]] /
> > > {recipient_data}
> > >
> > > 3)  We do not support any special form of dealing with a single
> recipient.
> > > The cost of this option is 3 bytes over option one.  (One byte for
> > > the recipients key, one byte for the array marker, one byte for the
> > > map
> > marker.)
> > >
> > > CDDL grammar would be:  recipients: [+[recpient_data]]
> > >

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 7 Jul 2015 15:57:29 -0700

One needs to be careful with arguing from antecedent.  Beware of black swans.

I can think of a number of reasons why JOSE is not used.  The fact that everything is base64 encoded and that detached content are not enthusiastically supported are high among these.

I know that MILE glanced at using JOSE since they were thinking of moving to JSON, but the form did not match how they were currently setup, and the base64 of all content was a problem.

I expect that the world of compact devices are going to want to do something along the lines of RFC 4108 which does firmware update packages in CMS.  This is likely to want multiple signatures and lots of binary content.  Moving to JOSE is a problem on the second account and so would be unlikely to show up on anybody’s radar.

My opinion is that if people really care about having a “specialized” single recipient version, then by far the best course is to go back to using arrays at the top level and do the unrolling approach.  This is the smallest message size and yet is still a simple way to decode things.  If we keep maps at the top level, I see no benefits of trying to have a single recipient version at the savings of a single  byte in the message and additional complications.  One can keep that extra message byte and say – only process the first recipient structure even if there are more than one.

From: Brian Campbell [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2015 1:40 PM
To: Carsten Bormann
Cc: Jim Schaad; [email-masked]
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

 

On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann <[email-masked] <mailto:[email-masked]> > wrote:

Grüße, Carsten

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 7 Jul 2015 15:58:56 -0700

From: Brian Campbell [mailto:[email-masked]] 
Sent: Thursday, July 02, 2015 10:14 AM
To: Carsten Bormann
Cc: Justin Richer; Jim Schaad; [email-masked]
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

Indeed the dot joined base64url encoded segments are very array like. And with CBOR that encoding and dot joining is unneeded.

The JOSE experience I'm suggesting this WG consider is the relative simplicity afforded by compact serializations and the widespread use they have seen.

[JLS]  I don’t know how much of this is because it is easy, or because that was the format that was being used by “everybody” before it even came into the working group.  Remember how many decisions boiled down to – we can’t change this, it would break all of the existing code.

Conceptualizing the compact serializations as arrays, you have this for signatures/macs:

and this for encryption:

    [protected_header, encrypted_key, initialization_vector, ciphertext, authentication_tag]

There's just a single recipient or just one signature. There's only one place for headers and they are always protected. It's a (relatively) simple and consistent processing model. The message can be processed or not. There's real value in the simplicity. 

On Thu, Jul 2, 2015 at 1:36 AM, Carsten Bormann <[email-masked] <mailto:[email-masked]> > wrote:

[pr, un, ciph, [r1, r2]]

or

[pr, un, ciph, r1]

or

[pr, un, ciph, *r1]

[pr, un, ciph, r1, r2]

Grüße, Carsten

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Jul 2015 11:00:54 -0400

Henrich Pöhls <[email-masked]> writes:

> I can think of use cases that benefit if you are capable of having a
> compact and easily parseable representation of signed signed data.
> An example could be if you facilitate signatures to check if data
> originated at some sensor and also that it passed (and got vetted for)
> by another constrained device (e.g. data concentrator).
>
> Just my thoughts. As I currently work towards finding a good
> representation for cryptographically signed JSON messages to be
> emitted by constrained devices, within the RERUM project, I was
> following the discussions here.

For this I would expect nested structures.  E.g.:

  COSE_Signature(<from concentrator>,
                 payload: COSE_Signature(<from sensor>,
                                         payload: <content>))

Could we have a more compact representation of this?   Possibly..  But I
suspect the extra overhead of the nesting is not significantly more than
the extra overhead of signaling a virtual-nesting.

> Best, Henrich

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Jul 2015 11:14:38 -0700

> From: Henrich Pöhls [mailto:[email-masked]]
> Sent: Wednesday, July 01, 2015 8:14 AM
> To: Jim Schaad
> Cc: Dick Hardt; [email-masked]
then it
> is unlikely that there is a need for multiple recipients.
> 
compact
> and easily parseable representation of signed signed data.
originated
> at some sensor and also that it passed (and got vetted for) by another
> constrained device (e.g. data concentrator).
> 
> representation for cryptographically signed JSON messages to be emitted
> by constrained devices, within the RERUM project, I was following the
> discussions here.

Sorry -I had intended to respond to this message when I did the last pass
through and forgot.

I can think of three different ways to handle this depending on what
restrictions on wishes to impose on implementations.  It will also depend on
what you are using for algorithms.  For example, it might be that the sensor
is sending data to the vetter using a MAC algorithm rather than a signature
algorithm.  In this case the vetter would just rebuild the message and put a
signature on it.  Part of the data that it signs would then be the
identifier of the sensor that the message came from.

If one is using a signature algorithm on both the sensor and the vetter one
could do any of the following:

1) Just nest the signature structures like Derik suggested.   This gives you
    Sign(Sign(content, sensor), vetter)

2)  Follow the same construct as the countersignature attribute in CMS.
This means that a new unprotected attribute is created which would be a
signature by the vetter on the signature of the sensor.    This gives:
   Signed(content, sensor, unprotected-countersign(sensor-signature,
vetter))

3)  It would be possible to do something similar to a countersignature, but
have it be a bit bigger in terms of what is signed.  Have two signatures on
the content.  The first is the normal signature of the sensor.  The second
would be signature over the sensor payload plus a part of the sensors
signature.  This can be indicated by new protected attribute that indicates
that this the case.  You would then end up with two signatures on the
content and could validate either one, checking or not checking the vetter's
correctness as needed.

      Signed( sign(content, sensor), sign(content+sensor-signature, vetter))

Jim

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2015 07:12:18 -0600

On Tue, Jul 7, 2015 at 4:58 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Thursday, July 02, 2015 10:14 AM
> *To:* Carsten Bormann
> *Cc:* Justin Richer; Jim Schaad; [email-masked]
> *Subject:* Re: [Cose] Issue: Encoding for a single recipient or structure
>
>
> [JLS]  I don’t know how much of this is because it is easy, or because
> that was the format that was being used by “everybody” before it even came
> into the working group.  Remember how many decisions boiled down to – we
> can’t change this, it would break all of the existing code.
>
>
>

That the format was being used suggests that it provided utility to those
that were using it.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2015 10:58:18 -0600

To dismiss that as argument from antecedent would be to miss the main
thrust of what was said.

There may well be other reasons (those that you've cited) for lack of use
of the JOSE JSON serializations, but some of us anyway have seen
significant real world use of compact serializations of JOSE and have not
encountered the need for the additional features offered by the JSON
serializations.

I'm starting to fell as though I'm in the minority here, however, so I'll
eventually stop harping about it. I was just looking for the WG to consider
the value and success of the simpler side of JOSE.

On Tue, Jul 7, 2015 at 4:57 PM, Jim Schaad <[email-masked]> wrote:

> I can think of a number of reasons why JOSE is not used.  The fact that
> everything is base64 encoded and that detached content are not
> enthusiastically supported are high among these.
>
>
>
> I know that MILE glanced at using JOSE since they were thinking of moving
> to JSON, but the form did not match how they were currently setup, and the
> base64 of all content was a problem.
>
>
>
> I expect that the world of compact devices are going to want to do
> something along the lines of RFC 4108 which does firmware update packages
> in CMS.  This is likely to want multiple signatures and lots of binary
> content.  Moving to JOSE is a problem on the second account and so would be
> unlikely to show up on anybody’s radar.
>
>
>
> My opinion is that if people really care about having a “specialized”
> single recipient version, then by far the best course is to go back to
> using arrays at the top level and do the unrolling approach.  This is the
> smallest message size and yet is still a simple way to decode things.  If
> we keep maps at the top level, I see no benefits of trying to have a single
> recipient version at the savings of a single  byte in the message and
> additional complications.  One can keep that extra message byte and say –
> only process the first recipient structure even if there are more than one.
>
>
>
> *Sent:* Wednesday, July 01, 2015 1:40 PM
> *To:* Carsten Bormann
> *Cc:* Jim Schaad; [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Fri, 10 Jul 2015 17:01:14 +0000

I don’t think you’re in the minority, Brian.  I think you’re doing a good job making the case for simplicity, and others are happy with you taking the lead in that regard.

From: Cose [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, July 10, 2015 9:58 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

To dismiss that as argument from antecedent would be to miss the main thrust of what was said.
There may well be other reasons (those that you've cited) for lack of use of the JOSE JSON serializations, but some of us anyway have seen significant real world use of compact serializations of JOSE and have not encountered the need for the additional features offered by the JSON serializations.
I'm starting to fell as though I'm in the minority here, however, so I'll eventually stop harping about it. I was just looking for the WG to consider the value and success of the simpler side of JOSE.

On Tue, Jul 7, 2015 at 4:57 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
One needs to be careful with arguing from antecedent.  Beware of black swans.

From: Brian Campbell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 01, 2015 1:40 PM
To: Carsten Bormann
Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

Grüße, Carsten

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