> Whose responsibility is it to enforce this? Should WebCrypto refuse to export such?

s/export/import/

(In reply to Alexey Proskuryakov from comment #0)
> I think that it would be helpful if WebCrypto called out some non-obvious
> cases where JWK import or export should not be allowed.
> 
> Some examples:
> 
> - JWK does not allow duplicate operations in key_ops. No sane WebCrypto
> would produce such on export, but it's not at all obvious what to do when
> importing. Whose responsibility is it to enforce this? Should WebCrypto
> refuse to export such?

Invalid JWK, per the JWK spec, so yeah.

> 
> - JWK does not allow leading zeroes in BigIntegers. Should WebCrypto refuse
> to import keys with such?

Are you sure? JWK doesn't specify BigIntegers at all. JW*A* however, does (In Section 6 - http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-6 )

I'm just wanting to make sure we're referencing the right specs when we talk about requirements.

If we're going to utilize JWK, my assumption is that yes, all "MUST" requirements should be validated - otherwise, it's not JWK.

> 
> - JWK does not allow RSA keys shorter than 2048 bits. Should WebCrypto
> refuse to import such? Should it refuse to export short WebCrypto keys, or
> is that up to JS code to enforce?

Again, JWK doesn't set this requirement.

JWA lists it, but in the context of Section 3, which are algorithms for use with JWS. WebCrypto is not a JWS implementation, so I don't think this requirement applies.

That is, per http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-20#section-3.1 , it only applies towards JWS.

The conclusions I reach are:
1) WebCrypto is definitely delving into dangerous territory regarding the dependency on JOSE (although this has always been known).
2) WebCrypto needs to be very clear regarding the treatment of JWA's Sections 3, 4, and 5. We're permitting the algorithms from the relevant algorithm table as aliases, but we are NOT inheriting the requirements from JWE/JWS.

You are correct, I was referring to JWK loosely, meaning the whole family of interrelated specs.

I did not analyze the relationship between JOSE specs in much detail, however WebCrypto uses key formats from JWA, so it would be surprising if we are selective about which parts of JWA to respect.

I think the problem is that all three of JWE, JWS and JWK refer to the JWA specification for components that they need.

Because JWK refers to JWA doesn't mean that JWK inherits all the requirements in there that apply to JWE and JWS. For example, JWA is quite clear that only authenticated encryption algorithms are supported for JWE, but this does not mean JWK cannot carry keys for AES CTR etc.

So, yes, we are selective about what requirements in JWA apply to us. Or rather, JWA is selective in applying its requirements to JWE or JWS and not to JWK itself.

Yes, one way or another, WebCrypto needs to be very explicit about this. I see no way to guess that WebCrypto respects every sentence from this section, except for the last one:

---------------------
6.3.1.1.  "n" (Modulus) Parameter

   The "n" (modulus) member contains the modulus value for the RSA
   public key.  It is represented as the base64url encoding of the
   value's unsigned big endian representation as an octet sequence.  The
   octet sequence MUST utilize the minimum number of octets to represent
   the value.
---------------------

(In reply to Alexey Proskuryakov from comment #5)
> Yes, one way or another, WebCrypto needs to be very explicit about this. I
> see no way to guess that WebCrypto respects every sentence from this
> section, except for the last one:
> 
> ---------------------
> 6.3.1.1.  "n" (Modulus) Parameter
> 
>    The "n" (modulus) member contains the modulus value for the RSA
>    public key.  It is represented as the base64url encoding of the
>    value's unsigned big endian representation as an octet sequence.  The
>    octet sequence MUST utilize the minimum number of octets to represent
>    the value.
> ---------------------

I'm not sure I follow? When importing a JWK, I *would* expect a WebCrypto implementation to respect this, as this is a requirement on JWK as a transport medium (and not a specific requirement on "keys used with JWE/JWS" or "algorithms used with JWE/JWS")

While the suggestion is that BigInteger should follow Postel's Law (following the most recent phone call), I don't think that liberally extends to everything. After all, from the perspective of JWK import/unwrap, what's being unwrapped is a JWK, not a "BigInteger" (which is a UInt8Array, not a JSON "string"). When exporting/wrapping, WebCrypto should only present valid JWKs (with respect to the format - not with respect to their particular use within JWE/JWS)

I misread your earlier comment as suggesting that we don't check for minimal length on import. Now I see that you didn't say that.

So, it seems clear that the importKey and unwrapKey procedures should include a step which says what to do if the imported information is not valid according to the key format (return an error).

In the JWK section, I believe we should include some words about what is considered invalid according to the 'jwk' key format and this should refer to the JWK specification - i.e. all the normative requirements of that specification should apply.

JWK explicitly references Section 6 of JWA for the definitions of the various JWK members expressing different types of keys. Although JWK does not use normative language for that reference, I think we can conclude that the normative requirements of *Section 6* of JWA apply to all JWKs. I think we should note that in our specification.

(In reply to Mark Watson from comment #8)
> So, it seems clear that the importKey and unwrapKey procedures should
> include a step which says what to do if the imported information is not
> valid according to the key format (return an error).
> 
> In the JWK section, I believe we should include some words about what is
> considered invalid according to the 'jwk' key format and this should refer
> to the JWK specification - i.e. all the normative requirements of that
> specification should apply.
> 
> JWK explicitly references Section 6 of JWA for the definitions of the
> various JWK members expressing different types of keys. Although JWK does
> not use normative language for that reference, I think we can conclude that
> the normative requirements of *Section 6* of JWA apply to all JWKs. I think
> we should note that in our specification.

While I agree with the spirit, I do think we should be careful here.

For example, "x5c", "x5u", "x5t" have a normative requirement that, if present, the key in the certificate MUST match the public key represented by other members of the JWK.

If a UA importing a JWK, even though the "x5t"/"x5c"/"x5u" members are not used at all, is an implementation required to check it? Same with any other (future) attribute registrations added to the registry. Or are you suggesting UA implementations are required to support x5[t/c/u] as well?

Section 3 of JWK is somewhat ambiguous to this, specifically the last paragraph. "Additional members can be present in the JWK; if not understood by implementations encountering them, they MUST be ignored". Does that mean that all of the attributes in Section 3 are REQUIRED to be supported?

(In reply to Ryan Sleevi from comment #9)
> (In reply to Mark Watson from comment #8)
> > So, it seems clear that the importKey and unwrapKey procedures should
> > include a step which says what to do if the imported information is not
> > valid according to the key format (return an error).
> > 
> > In the JWK section, I believe we should include some words about what is
> > considered invalid according to the 'jwk' key format and this should refer
> > to the JWK specification - i.e. all the normative requirements of that
> > specification should apply.
> > 
> > JWK explicitly references Section 6 of JWA for the definitions of the
> > various JWK members expressing different types of keys. Although JWK does
> > not use normative language for that reference, I think we can conclude that
> > the normative requirements of *Section 6* of JWA apply to all JWKs. I think
> > we should note that in our specification.
> 
> While I agree with the spirit, I do think we should be careful here.
> 
> For example, "x5c", "x5u", "x5t" have a normative requirement that, if
> present, the key in the certificate MUST match the public key represented by
> other members of the JWK.
> 
> If a UA importing a JWK, even though the "x5t"/"x5c"/"x5u" members are not
> used at all, is an implementation required to check it? Same with any other
> (future) attribute registrations added to the registry. Or are you
> suggesting UA implementations are required to support x5[t/c/u] as well?
> 
> Section 3 of JWK is somewhat ambiguous to this, specifically the last
> paragraph. "Additional members can be present in the JWK; if not understood
> by implementations encountering them, they MUST be ignored". Does that mean
> that all of the attributes in Section 3 are REQUIRED to be supported?

Yes, the "x5c", "x5u", "x5t" members are something we need to deal with. IS a WebCrypto implementation required to support these (and therefore check the normative JWK requirement) or not ?

The sentence in Section 3 is clear about future members or members defined elsewhere: they do not need to be supported for compliance with JWK and if not supported MUST be ignored. That sentence does not say anything about the members defined in the JWK specification (we don't - when reading specification text - assume that because something is said about X and nothing is said about Y then Y gets the opposite requirement to X).

In fact I cannot find anything in JWK that says any members MUST be supported at all. Aside from 'kty', this makes sense, because there could be implementations that support only one key type, so no key type can be mandatory to be supported.

JWK could clarify this, but in the absence of such clarification, we can assume that receivers are not required to support any of the members defined.

For WebCrypto, I think it would be wise to make it explicit that the "x5c", "x5u", "x5t" members MAY be ignored.

https://dvcs.w3.org/hg/webcrypto-api/rev/fc8c15cb6e83

The only JWK-defined property for which this is an issue is "key_ops" since for the others we explicitly require that they have specific values in the JWK import procedures.

I have added text to require that key_ops is valid according to JSON Web Key.

I have also changed "is not a valid JWK according to Section X.Y of JWA" to "does not meet the requirements of Section X.Y of JWA" so there is no ambiguous use of the term "valid JWK".

With these changes I think we are explicitly doing all the JWK validity checking necessary. We do not refer to a blanket "JWK validity" check and so additional members, whether defined in JWK or not are ignored.