Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)

[Richard Barnes <[e-mail]>]

On Tue, Oct 14, 2014 at 5:53 AM, Mike Jones <[e-mail]>
wrote:

> Thanks for your review.  The -34 draft contains the following
> resolutions.  I hope that you can clear your DISCUSSes on that basis.
>
>                                 -- Mike
>
> > -----Original Message-----
> > From: jose [mailto:[e-mail]] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 01, 2014 7:34 PM
> > To: The IESG
> > Cc: [e-mail];
> [e-mail];
> > [e-mail]
> > Subject: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-key-33: (with
> > DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-jose-json-web-key-33: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Section 4.3.
> > "The "use" and "key_ops" JWK members SHOULD NOT be used together."
> > Did the WG discuss how these could combine?  What was the outcome of that
> > discussion?  This could be an important point for interoperability.  For
> example,
> > WebCrypto enforces them both, so it will break if it gets a key with
> "use" and
> > "key_ops" set to inconsistent values.
> >
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-
> > pss-operations
>
> I believe that the working group discussion is accurately reflected in
> this text from the spec:
>    The "use" and "key_ops" JWK members SHOULD NOT be used together.
>    Applications should specify which of these members they use, if
>    either is to be used by the application.
>
> To keep things simple, applications should choose one or the other, based
> on their needs.  Note that this is a "SHOULD NOT" - not a "MUST NOT", so if
> WebCrypto believes they have a good reason to allow either or both, they're
> not violating the spec.  But specifying which combinations are legal and
> which aren't in the JWK spec seems very high on the complexity to
> usefulness ratio.  I hope that you will choose to withdraw this DISCUSS on
> that basis.
>

How about if we require that they be consistent if used together, but punt
the definition of consistency to WebCrypto?

"""
   The "use" and "key_ops" JWK members SHOULD NOT be used together.
   Applications should specify which of these members they use, if
   either is to be used by the application.  If both "use" and "key_ops"
members
   are present, then they MUST be consistent (see [WebCrypto]).
"""



> > Section 8.
> > "[TBD]@ietf.org"
> > This needs to be populated before approval.  I don't know what's
> customary
> > here, but "[e-mail]" is an obvious candidate.
>
> Per the spec, [e-mail] is already the recommended name.
> Yes, we would create this list before final approval, just as
> [e-mail] was created before RFC 6749 was approved.  I
> hope that you'll choose to withdraw this DISCUSS on that basis.
>

That sounds fine to me.  Who has the action to get that list set up?



> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1.1.
> > The pointer for BASE64URL should be to JWS.  One level of indirection,
> please :)
>
> Agreed
>
> > Section 4.
> > It might be worth being explicit (here or elsewhere):
> > "A JWK MUST NOT contain algorithm-specific members for key type other the
> > one specified in its "kty" attribute."
>
> I agree with the sentiment, but this actually contradicts the statement
> that member names that are not understood MUST be ignored.
>

Good point.  Perhaps we could phrase this as a requirement on creators,
leaving consumers free to be more liberal?

"""
The creator of a JWK MUST NOT include algorithm-specific members for key
type other the one specified in its "kty" attribute.  Consumers of JWKs
SHOULD NOT reject JWKs with such members, however, in the interest of
extensibility.
"""



> > Section 4.1.
> > "cryptographic algorithm family used with the key"
> > "... such as "RSA" or "EC"."
>
> Agreed
>
> > Section 4.7.
> > "base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER"
> > It seems unpleasant for implementations to have to support two flavors of
> > base64, especially since this doesn't use PEM directly.  Did the WG
> discuss just
> > using BASE64URL?
>
> Not much, although each certificate value is actually a PEM-encoded value,
> including allowing newlines, etc.  People agreed with that goal when we did
> discuss it.
>
> > Section 9.1.
> > It might help here to note that technologies like PKIX and JWT can allow
> relying
> > parties to verify the provenance of a key and binding of attributes to
> it.
>
> Can you propose specific language for this?  What I have in mind is
> delivering a JWK or JWK Set on a TLS channel using a URL that is
> cryptographically bound to the use of the key - possibly using the URL as
> the issuer of a JWT signed with the key, but you may have something else in
> mind.
>

I had in mind more the traditional, "use a certificate to bind attributes
to a key" sense.  How about this?

"""
In most applications today, there are trusted authorities that vouch for
the provenance of a key and bind attributes to it.  For example, in
PKIX-based applications, participants use certificates to verify that a
certificate authority has bound certain attributes to a key, such as a name
or key usage.  JWK supports this style of provenance through the "x5u",
"x5c", "x5t", and "x5t#S256" attributes, all of which reference a
certificate that a relying party can use to associate attributes to the
JWK.  Other assertions systems, such as JWT, can likewise be used to assert
bindings of attributes to keys.

In some applications, it may also be convenient to use TLS as an ersatz
assertion mechanism.  For example, an application could require JWKs to be
downloaded with associated attributes over HTTPS as a way of having the
HTTPS server assert a binding of the JWK to its attributes.  This is
similar to the way that the XMPP POSH mechanism uses HTTPS to assert
delegations from one way to another.  In such applications, however, care
needs to be taken to ensure that secure transports are always used, and to
avoid confusion with other uses of the TLS server in question.  The former
situation would allow an attacker to create bogus assertions, and the
latter would let an attacker trick the server into issuing bogus assertions.
"""




>
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
>
>                                 Thanks again,
>                                 -- Mike
>
>