Re: [jose] way forward for two remaining drafts

[Mike Jones <[e-mail]>]

Thanks, Nat.  When I wrote the draft, I was intentionally being as clear as possible at first about the semantics by using two separate parameters, while also recognizing that we would probably want to collapse these to a single parameter for brevity.  My thinking was that we could define a “sio” (signing input options) parameter and three or four values for it.  I just hadn’t come up with great names for the values.  (You’re using integers, which are short but non-meaningful values.)

Here’s an initial stab for people to suggest better alternatives to:

"sph"

"b64"

“sio”

true

true

(parameter to be omitted when defaults used)

false

true

“b64o” (base64url encoded payload only)

true

false

“plain” (plaintext payload)

false

false

“min” (plaintext payload and no protected header)


                                                            -- Mike

From: Nat Sakimura [mailto:[e-mail]]
Sent: Thursday, July 16, 2015 11:41 PM
To: [e-mail]; [e-mail]; [e-mail]
Cc: Mike Jones; [e-mail]; [e-mail]
Subject: RE: [jose] way forward for two remaining drafts

Axel wrote:

Is it an argument for not base64url encoding payloads that they remain human/developer readable?

This argument would make draft-jones-jose-jws-signing-input-options useful for small payloads too.



Indeed. It is one of my use case – small and I want to keep it readable.

For the case the headers are not needed to be protected, the readability extends to the headers as well.

Re: header parameters, for the sake of size, I am inclined to combine “sph” and “b64” to “pb” or something and represent the value as a number.
So: (Sorry for an HTML table)

"sph"

"b64"

“pb”

true

true

3

false

true

1

true

false

2

false

false

0



--
Nat Sakimura <[e-mail]<mailto:[e-mail]>>
Nomura Research Institute, Ltd.

PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.

From: jose [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, July 16, 2015 2:55 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] way forward for two remaining drafts

Will review and probably implement this.

Nits: s/some of have/some have/
   While this
   cryptographically binds the protected Header Parameters to the
   integrity protected payload, some of have described use cases in
   which this binding is unnecessary and/or an impediment to adoption,
   especially when the payload is large and/or detached.
Should read:

   While this

   cryptographically binds the protected Header Parameters to the

   integrity protected payload, some have described use cases in

   which this binding is unnecessary and/or an impediment to adoption,

   especially when the payload is large and/or detached.

Is it an argument for not base64url encoding payloads that they remain human/developer readable?
This argument would make draft-jones-jose-jws-signing-input-options useful for small payloads too.

-Axel

From: jose [mailto:[e-mail]] On Behalf Of Kathleen Moriarty
Sent: Montag, 13. Juli 2015 20:25
To: Edmund Jay
Cc: Mike Jones; Nat Sakimura; [e-mail]<mailto:[e-mail]>; Karen O'Donoghue
Subject: Re: [jose] way forward for two remaining drafts

Hello,

It's good too see that a few people do support these drafts.  Will each of you be sending reviews and comments to the list shortly on these drafts?  If the chairs think it's reasonable to accept the drafts, they will also need to know there will be active support.

Thanks,
Kathleen

Sent from my iPhone

On Jul 13, 2015, at 1:10 PM, Edmund Jay <[e-mail]<mailto:[e-mail]>> wrote:
+1


________________________________
From: Nat Sakimura <[e-mail]<mailto:[e-mail]>>
To: Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>
Cc: Mike Jones <[e-mail]<mailto:[e-mail]>>; Karen O'Donoghue <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, July 12, 2015 10:32 AM
Subject: Re: [jose] way forward for two remaining drafts

Sorry to chime in so late. I have been completely under water for sometime now.

Like Phil, I do see that draft-jones-jose-jws-signing-input-options sort of thing can be very useful, though I may want to have slightly different way of encoding the things. Being able to do detached signature is quite attractive.

Best,

Nat

2015-07-10 2:37 GMT+09:00 Kathleen Moriarty <[e-mail]<mailto:[e-mail]>>:

Hi,

Sent from my iPhone

On Jul 9, 2015, at 1:16 PM, Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:
About https://tools.ietf.org/html/draft-jones-jose-jws-signing-input-options-00<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-jose-jws-signing-input-options-00&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=uGAAosD5aGeonSPFNfYJnr8Eg8lR%2bYJXY8fmq87w%2f7k%3d>, I’ll add that this addresses the requests make by Jim Schaad and Richard Barnes in JOSE Issues #26 “Allow for signature payload to not be base64 encoded” and #23 http://trac.tools.ietf.org/wg/jose/trac/ticket/23<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftrac.tools.ietf.org%2fwg%2fjose%2ftrac%2fticket%2f23&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CzGoDiV%2brrDZzEN6gX95zdOkkZENLSHj3m0jqitSDJU%3d> “Make crypto independent of binary encoding (base64)”.

About https://tools.ietf.org/html/draft-jones-jose-key-managed-json-web-signature-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-jose-key-managed-json-web-signature-01&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=76KRQQOO11ElDqxjBNLqfmpCVQUnN%2ffc13lqOmMN1Z8%3d>, I’ll add that this addresses the request made by Jim Schaad in JOSE Issue #2 http://trac.tools.ietf.org/wg/jose/trac/ticket/2<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftrac.tools.ietf.org%2fwg%2fjose%2ftrac%2fticket%2f2&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8ZukCNBEmC2FAYaqOnXZmy%2ffs7YH0TtKC01aFiR%2fHYI%3d> “No key management for MAC”.

Also, there’s a highly relevant discussion about key management for MACs going on in the COSE working group.  See the thread “[Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)” – especially https://mailarchive.ietf.org/arch/msg/cose/aUehU6O7Ui8CXcGxy3TquZOxWH4<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmailarchive.ietf.org%2farch%2fmsg%2fcose%2faUehU6O7Ui8CXcGxy3TquZOxWH4&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xXRr%2fMEhBlRzUJCohPEIxrOQBl06BJIbWF4p14i19Wc%3d> and https://mailarchive.ietf.org/arch/msg/cose/ouOIdAOe2P-W8BjGLJ7BNvvRr10<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmailarchive.ietf.org%2farch%2fmsg%2fcose%2fouOIdAOe2P-W8BjGLJ7BNvvRr10&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Wgowj5vYeOBshmm3FoMlIwuuG2qsuHzZ6XUXoVI%2fagk%3d>.

One could take the view that our decision on the JOSE key management draft should be informed by the related decision in COSE.  Specifically, that if COSE decides to support key management for MACs, the same reasoning likely should apply to our decision on whether to define a standard mechanism for supporting key management for MACs in JOSE.

Key management is explicitly out-of-scope for COSE as stated in the charter.  The discussion referenced had this point at the close of that discussion.

I'm not seeing much support for these drafts moving forward in JOSE.  I'm also not seeing enough to justify standards track and AD sponsored.  If you think these are important to have move forward in the WG or as standards track, please say so soon.  They can still go forward through the Independent submission process through the ISE.

Thank you,
Kathleen

                                                            -- Mike

From: jose [mailto:[e-mail]] On Behalf Of Karen O'Donoghue
Sent: Wednesday, July 01, 2015 8:38 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [jose] way forward for two remaining drafts

Folks,

With the thumbprint draft progressing through the process, we have two remaining individual drafts to decide what to do with. The options include: 1) adopt as working group drafts; 2) ask for AD sponsorship of individual drafts; or 3) recommend that they not be published. Please express your thoughts on what we should do with these drafts. Jim, Kathleen, and I would like to make a decision in the Prague timeframe, so please respond by 15 July.

https://tools.ietf.org/id/draft-jones-jose-jws-signing-input-options-00.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fid%2fdraft-jones-jose-jws-signing-input-options-00.txt&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PQVZxAOr28bkgjwqjjtnN5r%2f%2fB9JEnsd8JGWkdE%2fc1E%3d>

https://tools.ietf.org/id/draft-jones-jose-key-managed-json-web-signature-01.txt<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fid%2fdraft-jones-jose-key-managed-json-web-signature-01.txt&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=JjKwmnM113pD8JBnlLyEUam5O%2fVYeoFdhi%2ff0xgsH5I%3d>

Thanks,
Karen
_______________________________________________
jose mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QToiRUC5bprgKcShT345YDZoEXMsk7YFhJZnWUNUJCc%3d>

_______________________________________________
jose mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QToiRUC5bprgKcShT345YDZoEXMsk7YFhJZnWUNUJCc%3d>



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FPRICyKxNVxCJjahArzhl0zIXhtTl6mXUDFXCv%2fzXgw%3d>
@_nat_en

_______________________________________________
jose mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jose<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cMichael.Jones%40microsoft.com%7c38da69e6a267492c07c408d28e72b608%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QToiRUC5bprgKcShT345YDZoEXMsk7YFhJZnWUNUJCc%3d>