Replies inline below...
From: Stephen Kent [mailto:[email protected]]
Sent: Monday, September 15, 2014 7:56 AM
To: Mike Jones; Kathleen Moriarty; [email protected]; [email protected];
[email protected]; [email protected]
Subject: Re: JWK member names, was: [jose] SECDIR review of
draft-ietf-jose-json-web-key-31
Mike,
Sure. Here's an analysis of the requirements about duplicate member names.
There could be two very different kinds of objections to the present text:
A. People think we have the semantics for duplicate identifiers wrong.
B. People think we should explain the current semantics for duplicate
identifiers more clearly.
I sure hope that we're dealing with B and not A. Stephen, which is the nature
of your critique of this text?
C- don't accept duplicate IDs, is what I was hoping for.
I noted why allowing a recipient to accept a dup name, and use just the last
instance, will
likely lead to such behavior being perpetuated, based on PKIX experience.
So you're advocating this alternative from the analysis, correct?
1. Require producers not use duplicate members and require consumers to reject
inputs with duplicate member names.
Pros: This is the most locked-down, consistent, and alternative.
Cons: Real JSON parsers don't all reject duplicate inputs. If we force people
to write custom parsers, this will result in exploitable bugs (and some just
won't do it and won't be conformant).
The primary reason that the working group changed from this alternative in
draft -12 in July 2013 to the present one is that it allows JSON parsers as
actually deployed and supported to be used. The argument made then was that
forcing people to write a custom parser to reject duplicate member names is
likely to create security bugs, since insufficiently locked down parsers are a
fertile area for security vulnerabilities. It was thought that it was better
to have people using well-maintained, standard parsers and count on producers
to not emit duplicate member names in the first place. Is there some aspect of
this reasoning that doesn't seem convincing to you, Stephen?
As for perpetuating the behavior, it's not clear to me that the behavior will
ever start, since producers can't use duplicate member names and consumers are
allowed to reject them. Thus, producers can't count on consumers accepting the
illegal inputs, and so have a strong disincentive against ever producing them.
Is there something I'm missing here?
Also, in a reply to Tim, I think you argued that people have already
implemented JOSE and so
we ought not make any changes at this late stage. If that's what you said, I
disagree emphatically.
The IETF always warns implementers that specs may change until an RFC is
published, and thus
one implements a pre-RFC spec at risk.
You apparently misunderstood the point of my reply to Tim. I wasn't saying
that changes aren't possible. I was saying that we want JOSE to be usable by
people now - not just several years in the future when parsers for a more
locked-down JSON dialect may become available.
Steve
-- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
