What alternative registry of algorithm names were you thinking of? Are you
suggesting that we use the OID numbers used by CMS?
As far as I know, there is no MIME registry of cryptographic algorithm names,
so I don't think there's any conflict/duplication there.
-- Mike
From: Phillip Hallam-Baker [mailto:[email protected]]
Sent: Friday, June 14, 2013 4:56 PM
To: Mike Jones
Cc: Phil Hunt; Richard Barnes; [email protected]; <[email protected]>;
George Fletcher
Subject: Re: [jose] Deployed Code (was: Re: #23: Make crypto independent of
binary encoding (base64))
So is the idea that a standards organization should seek consistency
I understand the WG rationale. I reject it as a sufficient IETF rationale. If
it stands it is going to require two parallel registries for the same algs.
I have a spec that crosses HTTP and JSON. Am I supposed to use mime registry in
one and this duplicate scheme in the other?
Blocking that type of move is what IETF last call is for. There is a negligible
benefit in the spec and a huge cost to the community.
Sent from my differenc engine
On Jun 14, 2013, at 5:53 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
Short names were chosen because of the core compactness requirement for the
Compact Serialization. That was an engineering decision that was consciously
made and for which the rationale is clear.
You can disagree with that decision but it has known clear benefits and is far
from arbitrary.
-- Mike
From: Phillip Hallam-Baker [mailto:[email protected]]
Sent: Friday, June 14, 2013 2:49 PM
To: Phil Hunt
Cc: Richard Barnes; Mike Jones;
[email protected]<mailto:[email protected]>;
<[email protected]<mailto:[email protected]>>; George Fletcher
Subject: Re: [jose] Deployed Code (was: Re: #23: Make crypto independent of
binary encoding (base64))
I think in this case that it is late to bring up binary encoding in Jose
But that does not mean we can't add it later. Specs have revisions. All that is
needed to support binary is a flag to say what was signed. Defaults to the
current scheme.
Now if it was a case where binary had been raised at the start of the process
and the person got told to shut up because of 'focus' well that would be
different. When people pull that trick I have no qualms about repeating my
concerns in IETF last call. I think that all too often there is too much haste
when starting a WG and people get railroaded into a broken scheme some faction
likes. But that did not happen here so I think it is going to be for the binary
camp to work out the solution.
My bigger Jose concern is the bizarre decision to rename all the crypto alg
names. I have a spec that uses mime and JSON. If I take Jose seriously I need a
second crypto alg registry.
That is junk, that is something that was raised at the start of the process. So
yes, I will make it an issue in IETF last call
Sent from my difference engine
On Jun 13, 2013, at 12:06 PM, Phil Hunt
<[email protected]<mailto:[email protected]>> wrote:
Seems like many these days are in a rush. They call for consensus before
discussing the issue.
Isn't it up to the chair?
This isn't unique to this WG.
Too many times the explanation for keeping an apparent 'feature/flaw' is
'because we don't want change'. Yet often the group can't explain it. Or worse,
the group just says "we know the emperor has no clothes, we just don't feel the
need to comment." This is where alarm bells go off for me.
Phil
On 2013-06-13, at 7:35, Richard Barnes <[email protected]<mailto:[email protected]>> wrote:
This would have been a nice discussion to have had 18 months ago, when we were
getting started.
I don't think it's compatible with the IETF ethos to say "Changes to this
document MUST NOT break existing code." Otherwise, we're not doing engineering
here, we're cleaning up documentation and rubber-stamping.
What would be acceptable is to say "Changes must break cleanly with existing
code". That is, it should be possible for a JWT implementation to, say,
process both "legacy" JWS syntax and whatever comes out of this group. That
way, we could come to consensus on the best solution, incorporating lessons
learned from earlier work without being hindered by them.
Would participants here consider it a acceptable for the output of this working
group to be incompatible with existing JWT implementations, as long as it had
the property that JW* objects in the new format could be clearly distinguished
from "legacy" JW* objects, so that implementations could adapt their processing?
--Richard
On Thu, Jun 13, 2013 at 10:24 AM, George Fletcher
<[email protected]<mailto:[email protected]>> wrote:
+1
Breaking deployed code as raised by Brian, Naveen and others is a critical
consideration.
Thanks,
George
On 6/13/13 10:19 AM, Mike Jones wrote:
Jim and Karen, could you please do as Richard suggests and close this issue as
"won't fix".
Thank you,
-- Mike
From: Richard Barnes [mailto:[email protected]]
Sent: Wednesday, June 12, 2013 1:57 PM
To: [email protected]<mailto:[email protected]>; Mike Jones
Subject: Fwd: [jose] #23: Make crypto independent of binary encoding (base64)
In other words: Chairs, feel free to close/wontfix :)
---------- Forwarded message ----------
From: Richard Barnes <[email protected]<mailto:[email protected]>>
Date: Wed, Jun 12, 2013 at 4:55 PM
Subject: Re: [jose] #23: Make crypto independent of binary encoding (base64)
To: "Matt Miller (mamille2)" <[email protected]<mailto:[email protected]>>
Cc: jose issue tracker
<[email protected]<mailto:trac%[email protected]>>,
"<[email protected]<mailto:[email protected]>>"
<[email protected]<mailto:[email protected]>>,
"<[email protected]<mailto:[email protected]>>"
<[email protected]<mailto:[email protected]>>,
"<[email protected]<mailto:[email protected]>>" <[email protected]<mailto:[email protected]>>
To be clear, I structured my message in two parts for a reason, to separate the
analysis from the opinion. I acknowledge that I am but one voice here, and I'm
increasingly hearing how alone I am :)
On Wed, Jun 12, 2013 at 4:23 PM, Richard Barnes
<[email protected]<mailto:[email protected]>> wrote:
<impartial-analysis>
So just to be clear on the trade-off the WG has to make:
On the one hand: Breaking every existing JWT implementation in the world
On the other hand: Eternally binding ourselves to base64 encoding, even if
binary-safe encodings become available (CBOR, MsgPack, etc.)
</impartial-analysis >
<personal-opinion>
I have some sympathy with JWT implementors. It sucks to have to refactor code.
But I think we're literally talking about something like a 5-line patch. And
early JWT implementors knew or should have known (to use a DC phrase) that they
were dealing with a draft spec. As the W3C editor's draft template says, in
big bold red print, "Implementors who are not taking part in the discussions
are likely to find the specification changing out from under them in
incompatible ways."
As PHB pointed out in the other thread, it would be nice to use JWS and JWE in
place of CMS one day, without the base64 hit. We should incur the
implementation pain now, and get the design right for the long run. Base64 is
a hack around JSON; we should build the system so that when we no longer need
that hack, it can go away.
</personal-opinion>
--Richard
On Wed, Jun 12, 2013 at 10:27 AM, Matt Miller (mamille2)
<[email protected]<mailto:[email protected]>> wrote:
I did at first find it curious why the cryptographic operations were over the
base64url-enccoded values, but I was also very focused on JWE, where I think
the field separation problem is less of an issue (at least now). For JWS, this
would certainly cause problems without some manner of unambiguous field
parameterization.
I will note that unescaped NULL is not valid in JSON, so it could be used as a
separator between the encoded header and the payload. I do find it interesting
if JOSE could more easily and efficiently support other encodings. However, I
think that while this is an interesting thought experiment, it seems we're too
far down the path to seriously consider it unless the current state were shown
to be horribly broken.
- m&m
Matt Miller < [email protected]<mailto:[email protected]> >
Cisco Systems, Inc.
On Jun 11, 2013, at 6:01 PM, jose issue tracker
<[email protected]<mailto:trac%[email protected]>> wrote:
> #23: Make crypto independent of binary encoding (base64)
>
>
> Comment (by [email protected]<mailto:[email protected]>):
>
> For both serializations, you already need the base64url encoded versions
> of the JWS Header and the JWS Payload to preserve them in transmission, so
> computing them isn't an extra burden. In the JWS Compact Serialization,
> you already need the concatenation of the Encoded JWS Header, a period
> character, and the Encoded JWS Payload, so computing that concatenation
> isn't an extra burden. Given you already have that quantity, computing
> the signature over it is the easiest thing for developers to do, and it's
> been shown to work well in practice. There's no compelling reason to make
> this change.
>
> Even for the JSON Serialization, the only "extra" step that's required to
> compute the signature is the concatenation with the period character - to
> prevent shifting of data from one field to the other, as described by Jim
> Schaad in the e-mail thread. So this step isn't actually "extra" at all -
> it's necessary. It's also highly advantageous to use exactly the same
> computation for both serializations, which is currently the case.
>
> Since there is no compelling reason to make this change, and since making
> it could enable the "shifting" problem identified by Jim, it should not be
> made.
>
> --
> -------------------------+-------------------------------------------------
> Reporter: [email protected]<mailto:[email protected]> | Owner:
> draft-ietf-jose-json-web-
> Type: defect |
> [email protected]<mailto:[email protected]>
> Priority: major | Status: new
> Component: json-web- | Milestone:
> encryption | Version:
> Severity: - | Resolution:
> Keywords: |
> -------------------------+-------------------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/23#comment:2>
> jose <http://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
<XeC><http://connect.me/gffletch>
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
