Subject: [COSE] Adding AES Key Wrap with Padding

From: Jim Schaad <[email-masked]>
Date: Tue, 22 Jan 2019 14:09:53 -0800

Russ,

I will ask the same question that I asked the last time that somebody
requested that we support the AES Key Wrap with Padding Algorithm.  What is
the use case that you have for this algorithm.  This makes a difference in
terms of how things are going to be used and what other things might need to
be specified for this.  I have to admit that I would really prefer to get an
AEAD version of this algorithm if we are going to add something but that I
probably not possible.

Jim

---

From: Russ Housley <[email-masked]>
Date: Tue, 22 Jan 2019 17:36:13 -0500

Jim:

The use case is wrapping PKCS#8 objects, which are not necessarily a multiple of 8 octets.

Russ

> On Jan 22, 2019, at 5:09 PM, Jim Schaad <[email-masked]> wrote:
> 
> Russ,
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Jim Schaad <[email-masked]>
Date: Tue, 22 Jan 2019 15:10:02 -0800

Russ,

That is indeed an interesting use case.  Does this mean that you are really
more interested in using this as a content encryption algorithm rather than
a key encryption algorithm?  I have doubts for this use case that you are
looking to wrap key and are looking to wrap content.  This is different than
a use case where one wishes to use an HMAC algorithm with a key which is not
a multiple of 8 octets.

Jim

> -----Original Message-----
> From: Russ Housley <[email-masked]>
> Sent: Tuesday, January 22, 2019 2:36 PM
> To: Jim Schaad <[email-masked]>
> Cc: cose <[email-masked]>
> Subject: Re: [COSE] Adding AES Key Wrap with Padding
> 
> Jim:
> 
> The use case is wrapping PKCS#8 objects, which are not necessarily a
multiple
> of 8 octets.
> > requested that we support the AES Key Wrap with Padding Algorithm.
> > What is the use case that you have for this algorithm.  This makes a
> > difference in terms of how things are going to be used and what other
> > things might need to be specified for this.  I have to admit that I
> > would really prefer to get an AEAD version of this algorithm if we are
> > going to add something but that I probably not possible.
> >
> > Jim
> >
> >

---

From: Russ Housley <[email-masked]>
Date: Tue, 22 Jan 2019 18:20:40 -0500

Jim:

PKCS#8 is a key that need to be wrapped.

I want to be able to use if for any keying material, including an HMAC key.

Russ

> On Jan 22, 2019, at 6:10 PM, Jim Schaad <[email-masked]> wrote:
> 
> Russ,
>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 22 Jan 2019 15:33:01 -0800

Jim,

Ok lets try this again, I don't think that you got the gist of my question.
(I have been told recently that I probably need to be more verbose in
describing my questions.)

What I understand you want to do is to build a structure that looks
something like this:

EncryptedMessage : {
   Protected Headers,
  Unprotected Headers,
  AES-KeyWrap-Pad( PKCS #8 ),
  Recipient: [ {
       Protected Headers,
      Unprotected Headers,
      RSA-OAEP( AES-KeyWrap-Pad encryption key )
  }]
}

In this case the key wrap is being done as a content encryption key even if
what it is encrypting a content which contains a private key.

The other case that I was talking about would be something like the
following:

EncryptedMessage :{
    Protected Headers,
    Unprotected Headers,
    AES-GCM-128( some content ),
    Recipient: [ {
          Protected Headers,
          Unprotected Headers,
           ECDH ( CEK ),
             Recipient: [{
                 Protected Headers,
                 Unprotected Headers,
                 AES-KeyWrap-Pad( PKCS#8 w/ private ECDH key )
}]}]}

In this case one would both be transporting the private key - encrypted with
AES-KeyWrap and a pre-shared secret (or perhaps ECDH and AES-KeyWrap-Pad)
and that transported key is then being used to do an ECDH operation which is
then used to decrypt some content.

In this case one is in essence transporting two different sets of encrypted
material:  the "some content" information and the private key.

Jim

> Sent: Tuesday, January 22, 2019 3:21 PM
> > That is indeed an interesting use case.  Does this mean that you are
> > really more interested in using this as a content encryption algorithm
> > rather than a key encryption algorithm?  I have doubts for this use
> > case that you are looking to wrap key and are looking to wrap content.
> > This is different than a use case where one wishes to use an HMAC
> > algorithm with a key which is not a multiple of 8 octets.
> >
> > Jim
> >
> >
> >>> I will ask the same question that I asked the last time that
> >>> somebody requested that we support the AES Key Wrap with Padding
> Algorithm.
> >>> difference in terms of how things are going to be used and what
> >>> other things might need to be specified for this.  I have to admit
> >>> that I would really prefer to get an AEAD version of this algorithm
> >>> if we are going to add something but that I probably not possible.
> >>>
> >>> Jim
> >>>
> >>>

---

From: Russ Housley <[email-masked]>
Date: Tue, 22 Jan 2019 18:39:29 -0500

Jim:

I was thinking of the first case, but it would be good to support both.

Russ

> On Jan 22, 2019, at 6:33 PM, Jim Schaad <[email-masked]> wrote:
> 
> Jim,
>