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

[Kathleen Moriarty <[e-mail]>]

Richard,

I am close to be done with a final check on comments for this draft
and see that one of your comments was not addressed and maybe should
be.

The comment left in the datatracker is as follows:

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.

This is a slightly edited version from earlier discussions, which
leads me to think you may not have been happy with the 'discussion'
http://www.ietf.org/mail-archive/web/jose/current/msg04627.html

Can you take a look at this and if you have text to propose, that
would be appreciated.

On Tue, Nov 4, 2014 at 12:33 AM, Mike Jones <[e-mail]> wrote:
> +1
>
>
>
> From: Kathleen Moriarty [mailto:[e-mail]]
> Sent: Monday, November 03, 2014 8:02 PM
> To: Richard Barnes
> Cc: Mike Jones; [e-mail];
> [e-mail]; The IESG; [e-mail]
>
>
> Subject: Re: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
>
>
>
> Thank you, Richard.
>
> Sent from my iPhone
>
>
> On Nov 3, 2014, at 10:14 PM, Richard Barnes <[e-mail]> wrote:
>
> Thanks a lot!  I cleared.
>
>
>
> On Sat, Oct 25, 2014 at 2:34 AM, Mike Jones <[e-mail]>
> wrote:
>
> Hi Richard,
>
> In -36 I added that if both "use" and "key_ops" are used, then the
> information they convey MUST be consistent, per your suggestion.  I also
> replaced the [TBD]@ietf.org with the actual list name.  Hopefully this will
> enable you to clear your DISCUSSes on this draft.
>
>                                 Thanks again,
>                                 -- Mike
>
> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Monday, October 20, 2014 9:19 AM
> To: Richard Barnes
> Cc: The IESG; [e-mail];
> [e-mail]; [e-mail]
>
> Subject: RE: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
>
> Thanks for your responses, Richard.  Replies are inline below...
>
>> From: Richard Barnes [mailto:[e-mail]]
>> Sent: Saturday, October 18, 2014 11:38 AM
>> To: Mike Jones
>> Cc: The IESG; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Re: [jose] Richard Barnes' Discuss on
>> draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
>>
>> 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]).
>> """
>
> I suspect some reviewers wouldn't agree with the "(see [WebCrypto])" part,
> but I can add the rest of your suggested sentence, if that will do it for
> you.
>
>> > 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?
>
> Kathleen is doing this, per earlier comments on the thread.
>
>> > --------------------------------------------------------------------
>> > --
>> > 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.
>> """
>
> In another thread, Carsten Bormann had explicitly objected to situations in
> which there are different requirements on producers and consumers, unless
> absolutely necessary.  I don't think the situation you're describing (for
> instance, including an extraneous "x" value in an RSA key value) rises to
> the level of severity that it warrants placing different requirements on
> producers and consumers.  Rather, my intuition at this point (which could,
> of course, be wrong), is that doing so would be likely to itself generate
> DISCUSS positions.  I think we're better off leaving this as-is.
>
>> > 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.
>> """
>
> It may be just me, but the whole notion of binding attributes to keys seems
> to be a bit off topic - at least in a section on "Key Provenance and Trust".
> The point of this section is that applications will make trust decisions
> about keys based on the trustworthiness of the way they got the key.
> Whether or not there may also be attributes bundled with the key is
> independent of this, so I'm not prone to talk about it here.  If you think
> it needs to be talked about elsewhere, can you motivate the reason for doing
> so?
>
> Other comments on your proposed text above follow...
>
> In what specific way are you thinking that "Other assertions systems, such
> as JWT, can likewise be used to assert bindings of attributes to keys"?
> While I agree that this is true, I suspect that most implementers wouldn't
> find that particular wording actionable.
>
> In your second proposed paragraph, while you're talking about "binding of
> the JWK to its attributes", I think the core of the message here is that TLS
> URLs can be used to provide clear provenance for sets of keys.  I'm fine
> with saying that in some way.
>
> I agree with your comments about secure transports being used and ensuring
> that keys are only retrieved from locations advertised by the application as
> being their key locations.
>
>>
>>                                 Thanks again,
>>                                 -- Mike
>
>                                 -- Mike
>
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose



-- 

Best regards,
Kathleen