I was reading the spec and I think detached signature has certainly a
space, so b64: true/false makes sense to me. However I have to say that I
found a bit strecht the use of sph flag. It sounds to me like a premature
optimization. I would keep it out for now to keep things simple.



On Fri, Jul 17, 2015 at 2:34 PM Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  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:n-sakimura@nri.co.jp]
> *Sent:* Thursday, July 16, 2015 11:41 PM
> *To:* Axel.Nennker@telekom.de; kathleen.moriarty.ietf@gmail.com;
> ejay@mgi1.com
> *Cc:* Mike Jones; odonoghue@isoc.org; jose@ietf.org
> *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 <n-sakimura@nri.co.jp>
>
> 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:jose-bounces@ietf.org <jose-bounces@ietf.org>] *On
> Behalf Of *Axel.Nennker@telekom.de
>
>
> *Sent:* Thursday, July 16, 2015 2:55 PM
> *To:* kathleen.moriarty.ietf@gmail.com; ejay@mgi1.com
> *Cc:* Michael.Jones@microsoft.com; sakimura@gmail.com; odonoghue@isoc.org;
> jose@ietf.org
> *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:jose-bounces@ietf.org <jose-bounces@ietf.org>] *On
> Behalf Of *Kathleen Moriarty
> *Sent:* Montag, 13. Juli 2015 20:25
> *To:* Edmund Jay
> *Cc:* Mike Jones; Nat Sakimura; jose@ietf.org; 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 <ejay@mgi1.com> wrote:
>
>   +1
>
>
>
>
>
>   ------------------------------
>
> *From:* Nat Sakimura <sakimura@gmail.com>
> *To:* Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
> *Cc:* Mike Jones <Michael.Jones@microsoft.com>; Karen O'Donoghue <
> odonoghue@isoc.org>; "jose@ietf.org" <jose@ietf.org>
> *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 <
> kathleen.moriarty.ietf@gmail.com>:
>
>
>
>  Hi,
>
> Sent from my iPhone
>
>
> On Jul 9, 2015, at 1:16 PM, Mike Jones <Michael.Jones@microsoft.com>
> 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:jose-bounces@ietf.org <jose-bounces@ietf.org>] *On
> Behalf Of *Karen O'Donoghue
> *Sent:* Wednesday, July 01, 2015 8:38 AM
> *To:* jose@ietf.org
> *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
> jose@ietf.org
>
> 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
> jose@ietf.org
>
> 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
> jose@ietf.org
>
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>