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:[email protected]]
Sent: Thursday, July 16, 2015 11:41 PM
To: [email protected]; [email protected]; [email protected]
Cc: Mike Jones; [email protected]; [email protected]
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 <[email protected]<mailto:[email protected]>>
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:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Thursday, July 16, 2015 2:55 PM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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:[email protected]] On Behalf Of Kathleen Moriarty
Sent: Montag, 13. Juli 2015 20:25
To: Edmund Jay
Cc: Mike Jones; Nat Sakimura; [email protected]<mailto:[email protected]>; 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 <[email protected]<mailto:[email protected]>>
wrote:
+1
________________________________
From: Nat Sakimura <[email protected]<mailto:[email protected]>>
To: Kathleen Moriarty
<[email protected]<mailto:[email protected]>>
Cc: Mike Jones
<[email protected]<mailto:[email protected]>>; Karen
O'Donoghue <[email protected]<mailto:[email protected]>>;
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>>:
Hi,
Sent from my iPhone
On Jul 9, 2015, at 1:16 PM, Mike Jones
<[email protected]<mailto:[email protected]>> 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:[email protected]] On Behalf Of Karen O'Donoghue
Sent: Wednesday, July 01, 2015 8:38 AM
To: [email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/jose
