My sincere apologies. Upon review, it appears that I missed a whole block of
resolutions agreed to in this thread. Those that I believe I missed were:
· changing “data associated with a key” to “data cryptographically
secured by a key”? (And of course, deleting the extraneous “than”.)
· add that this implies a that there is secure way to deliver the needed
decryption key for the JWE
· In addition to the common parameters, each JWK will have members that
are key type-specific.
· Rather than saying “SHOULD be used”, we could change it to just say
“is used”.
· The "alg" member is used to specify the algorithm with which the key
is to be used.
· The "use" parameter is employed to indicate whether a public key is
for encrypting data or verifying the signature on data.
· This specification will be used both in open environments … and closed
environments …
· change “can be” to “is”
· Clarification about improving interoperability
· Similarly, if the “alg” member is present, it SHOULD correspond to the
algorithm specified in the certificate.
· we could add language saying that certificate thumbprints are also
known as certificate fingerprints
· We could be more explicit and talk about performing authenticated
encryption
Also, there was an issue about the RFC 1421 reference that we did not reach a
resolution on. In looking at 1421, it’s no longer clear to me that this is the
best reference for the “x5u” certificate format definition. I’ll have to
investigate that further.
Finally, on the basis of Stephen’s comment on two weeks being potentially two
short for the registration review period and people taking multi-week
vacations, I propose that we change it to three weeks.
Kathleen, do you want me to publish updated drafts today addressing these
missed resolutions? My thinking is that it would probably be better to go into
the telechat with these issues having been addressed.
-- Mike
From: Kathleen Moriarty [mailto:[email protected]]
Sent: Thursday, September 25, 2014 7:25 AM
To: Mike Jones
Cc: Stephen Kent; [email protected]; [email protected]; Moriarty,
Kathleen; [email protected]
Subject: Re: [jose] SECDIR review of draft-ietf-jose-json-web-key-31
Hi Mike,
It appears that the explanation for thumprints/fingerprints was not included in
the current version and was agreed to. This came up several times in reviews
and I think it would be helpful for the reader. Let me know if I missed
something or if this was an oversight and it will be addressed in the next
revision.
Also, there is some suggested text from Steve on "alg" members. Where does
that stand? I think I am missing the resolution.
These issues are in the email thread right next to each other.
Thanks!
On Tue, Sep 23, 2014 at 7:40 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
Thanks again for your review, Stephen. The resolutions discussed below have
been incorporated in draft -32.
See the thread “JWK member names, was: [jose] SECDIR review of
draft-ietf-jose-json-web-key-31” for the status of that particular issue.
-- Mike
From: Stephen Kent [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, September 11, 2014 8:13 AM
To: Mike Jones; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; Moriarty,
Kathleen
Cc: [email protected]<mailto:[email protected]>
Subject: Re: SECDIR review of draft-ietf-jose-json-web-key-31
Mike,
Thanks for the reply to my comments.
I've retained your replies and responded to them, below.
I agree that “employing countermeasures to” is more accurate than “preventing”.
I also agree that the “avoiding mistakes” language is not actionable – I
propose to just remove it.
Great.
Actually, it was spoken by then-Security AD Sean Turner. ;-)
gee, I thought Sean was wise, but I didn't realize he was a Jedi ;-).
How about changing “data associated with a key” to “data cryptographically
secured by a key”? (And of course, deleting the extraneous “than”.)
OK.
The wording above is needlessly awkward. Nonetheless, this says that key sets
containing symmetric or private keys should be encrypted by embedding them in
another JSON crypto format (JWE). It would be nice to add that this implies a
that there is secure way to deliver the needed decryption key for the JWE, else
this recommendation just adds a layer of indirection, and does not solve the
problem.
Fair enough. I propose that we add something along those lines.
OK, I look forward to seeing the revised wording here.
Section 9.3 discusses a countermeasure against a specific attack on RSA key
use. This seems unduly narrow, since this spec is intended for use with RSA,
DH, DSS, and ECDH keys. Why devote a long paragraph to this one issue, while
saying nothing about equally serious concerns that arise for other algorithms?
This particular attack is described both because the countermeasure requires
specific key representation actions and because a working group member asked it
to be included. For what it’s worth, I expect that additional security
considerations will be added when resolving Russ Housley’s gen-art review of
the JWS specification.
If comparable alg-specific countermeasures are added based on Russ's comments
then
this may be OK, but in isolation this RSA-specific attack seem out of place.
These non-goals were agreed to by the working group from the very beginning,
while the working group was still being chartered. The group wanted to build
something simple and easily deployable to represent keys in JSON – not reinvent
all the work that the PKIX working group did on certificates and certificate
chains, etc. Do any working group members want to suggest specific wording to
try to capture this sentiment?
OK.
The example that comprises Section 3 should include an explanation of the
parameters, else it’s not a great example.
The parameters and values of them are explained in the paragraph preceding the
example text. It says:
The following example JWK
declares that the key is an Elliptic Curve
[DSS<https://tools.ietf.org/html/draft-ietf-jose-json-web-key-31#ref-DSS>] key,
it is used with
the P-256 Elliptic Curve, and its x and y coordinates are the
base64url encoded values shown. A key identifier is also provided
for the key.
Each statement above corresponds to a parameter in the example, and in the same
order.
OK. I missed that.
I suppose that one option is to be more verbose above and add parenthetical
remarks after each statement above saying which parameter does this. So for
instance, the parenthetical phrase “(“kty” parameter)” could be added before
the first comma. Do others in the working group think that would make the
example easier to read, harder to read, or do any of you have an alternative
suggestion?
I defer to the WG on this presentation issue.
In addition to the common parameters, each JWK will have members that
are algorithm-specific.
They’re not algorithm-specific – they’re key type-specific. Another way of
eliminating the repeated use of the word “parameters” is to replace the second
sentence with “These members represent the key value”. Would that work for you
(and the working group)?
Yes, I meant key-type specific. But if one were to use that term instead of
"algorithm specific"
I still think my wording is better.
This topic has been heavily discussed by the working group, and while the specs
used to just say that objects with duplicate member names MUST be rejected,
working group members, including Tim Bray (the editor of the JSON spec),
prevailed on us to weaken this so that parsers that implement the ECMAscript
behavior of returning only the last member name may be legally used. (The
argument was made that there was more security downside in effectively
requiring people to write and debug their own strict parsers than in using
laxer, but well-supported and debugged parsers.)
I find that argument unpersuasive, but I defer to the cognizant Ad on this.
However, we also intentionally require that producers use only one instance of
each member name, so that legally produced objects will never exercise the
ambiguities that are present in real JSON parsers. That seemed to be the most
practical solution to the working group.
Based on year of experience in PKIX that is not a great solution. If the
consumer of a data
structure fails to strictly enforce the requirement imposed on the producer of
the data structure,
the result is that non-conforming producers do not receive "appropriate"
feedback.
The term "Collision-Resistant Name" is already present in the Terminology
section. However, previous reviewers had requested that definitions not be
repeated in multiple specs, so it’s incorporated by reference, rather than
repeating the definition here. The notion is that of an implementation wants
to use a collision-resistant name such as “http://names.example.com/the-name”,
it can do so without having to create a public specification and register the
name with IANA.
I found the definition by reading one of the other specs, but I didn't see a
clear explanation of
why this is a reasonable alternative to using an IANA registry. The text above
does still does
not provide a rationale.
I agree that the “SHOULD” language is awkward. Rather than saying “SHOULD be
used”, we could change it to just say “is used”.
OK.
Would the language “The “alg” member can be used to specify the cryptographic
operation that the key is intended to be used for” work better for you? Or
would people like to just see the parenthetical remark deleted?
How about:
The "alg" member is used to specify the algorithm with which the key is to be
used.
Section 4.5 defines the key_ops parameter. It’s not clear how this parameters
and “use” relate. There is also an odd sentence at the end of the first
paragraph:
The "key_ops" parameter is intended for use cases in which public,
private, or symmetric keys may be present.
This seems to encompass all of the types of keys that JWK carries, so the
sentence seems to add no useful qualification for when this parameter is
intended to be used.
This is in contrast to the related statement in the “use” definition:
The "use" parameter is intended for use cases in which
it is useful to distinguish between public signing keys and public
encryption keys.
Too subtle for me, and the language above seems a bit wimpy. Why not say:
The "use" parameter is employed to indicate whether a public key is for
encrypting
data or verifying the signature on data.
If you want to see this parameter name changed, you’ll need to file a bug
against the WebCrypto spec and get it changed there. Then I’m sure that JOSE
will gladly follow.
My request is directed to the IESG, suggesting that they take this action.
This specification will be used both in open environments, in which multiple
organizations will need to have a common understanding of any extensions used,
and closed environments, which the producing and consuming organization will
always be the same and private values could be safely used. IANA registration
is definitely the right thing to do for open environments. It’s probably
unnecessary for deployments in closed environments.
Then say this.
Same answer as for Section 4.
ibid.
“Can” is being used as a non-2119 synonym for “MAY” here. That being said, we
could just change “can be” to “is”, since it’s explicitly said that its use is
optional at the end of the paragraph.
please revise accordingly.
It’s the inclusion of other metadata about the key that might improve
interoperability that’s being referred to – not the inclusion of the cert
reference. For instance, including “use” or “alg” parameters might be useful
to applications that can’t process the certificate.
that's not what the text said, hence my confusion.
As for the cert vs. cert chain question, in the general case, a chain may be
required to establish trust. However, a chain of length one (a single
certificate) will also be sufficient in some use cases. We’re not inventing
anything new here. The data format is specified in RFC 1421.
could you point specifically to where 1421 uses two names to identify
equivalent data structures
for transport of certs/cert chains? I trued a quick search of the text and
didn't locate the
text to which you appear to refer.
I had thought there were uses of RSA keys where the same key is used both for
signing and encryption (even though this is a deprecated practice).
Yes, that practice is frowned upon, and we prefer that certs use an OID that
makes it clear
how a key is to be used. How about the following text:
Similarly, if the "alg" member is present, it MUST be consistent with
the algorithm specified in the certificate.
But we could change this to “Similarly, if the “alg” member is present, it
SHOULD correspond to the algorithm specified in the certificate.” Or is that
overly strong for some certificates and uses of them?
I prefer this text.
Also, the name seems misleading since the chain MAY contain additional certs,
and hence may not be a chain at all!
I’m not sure if I’m following you here. Are you suggesting the possibility of
having multiple certificates not chaining to one another in the representation?
This isn’t allowed by the specification, as written. Are you suggesting that
it needs to be allowed?
Thumbprint is the term used in the Windows libraries, such as
http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.thumbprint(v=vs.110).aspx<http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.thumbprint%28v=vs.110%29.aspx>.
Whereas OpenSSL uses fingerprint http://www.openssl.org/docs/apps/x509.html.
I know that there would be an uproar if we tried to make a breaking change to
the “x5t” name at this point, because it’s in widespread production use.
However, we could add language saying that certificate thumbprints are also
known as certificate fingerprints, so people familiar with either term will
know what this is.
Yes, do add that explanatory text.
The term “base64url” is incorporated by reference in the terminology section
(Section 2).
Actually, Appendix C in JWS is not normative. It’s just example code. The
normative definition of the encoding is in Section 5 of RFC 4648.
Then 4648 should be cited.
It used to be a “SHOULD” but the working group felt that the “MUST … unless”
wording was a more accurate statement of the requirement.
I defer to the cognizant AD here, but the notion of SHOULD is really MUST ...
unless ...
Section 8 (IANA Considerations) establishes a two-week review period for
creating new (IANA) registry items. This seems too short; some people take
multi-week vacations. I note that the same text appears in the JWS and JWE
documents.
This text was taken from RFC 6749.
I didn't review that RFC. My comment still stands.
Aren’t appendices normally informative?
normally, but not always.
We could be more explicit and talk about performing authenticated encryption.
please do.
Steve
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
--
Best regards,
Kathleen
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
