I strongly agree with a point that Jim is making below: JWA must continue to
create the algorithms registries so that other specifications can add algorithm
identifiers. http://www.w3.org/TR/WebCryptoAPI is only the first of many specs
that we anticipate will use these registries. For instance, it wouldn’t be at
all surprising to have other specs register additional Elliptic Curve “crv”
identifiers in the near future.
Kathleen, I took your suggestion as being that the
Required/Recommended/Optional/Deprecated/Prohibited status of algorithms
defined by the initial JWA RFC would be updated by new RFCs that obsoleted the
initial JWA RFC – not that the algorithm identifiers themselves would not be
registered in the appropriate registries. That’s the change I was planning on
working on, based upon your feedback. Please confirm that that’s your intent,
or if not, let’s talk further.
Best wishes,
-- Mike
From: Jim Schaad [mailto:[email protected]]
Sent: Thursday, April 17, 2014 2:16 PM
To: 'Kathleen Moriarty'; [email protected]
Cc: Mike Jones; [email protected]
Subject: RE: [jose] AD review of draft-ietf-jose-json-web-algorithms
From: jose [mailto:[email protected]] On Behalf Of Kathleen Moriarty
Sent: Thursday, April 17, 2014 7:51 AM
To: [email protected]<mailto:[email protected]>
Cc: Michael Jones;
[email protected]<mailto:[email protected]>
Subject: [jose] AD review of draft-ietf-jose-json-web-algorithms
Hello Mike & JOSE members,
I am working my way through the requested reviews to progress the JOSE drafts
and can see a lot of work has been done, thank you. As I read through the
Algorithms (JWA) draft there are some changes that will need to be made to
avoid problems during the IESG review. This is a pretty big change for the
draft, but will help make the review and approval faster. Typically, the lists
of algorithms are handled through a draft update as opposed to creating an IANA
registry. A good example is a recent update of a draft in the IPSECME working
group so you can see the structure and the precedence for this model.
[JLS] Kathleen, I don’t know that I agree with this statement. There are a
number of different places where IANA registries are used for the purpose of
having lists of algorithms. I would point to the following as examples:
TLS uses registries for all of their algorithm assignments.
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18
– The TLS HashAlgorithm Registry
Kerberos has their OIDS registered with IANA
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26
PKIX and CMS have been moving towards keeping their OID trees in IANA registries
RFC 7101 and https://datatracker.ietf.org/doc/draft-housley-pkix-oids/
This is only a small set of the algorithm registries that are kept by IANA.
The only new thing is that the requirements level of algorithm is now being
kept in the registry, however that requires a document of some type to change
the top level requirements.
I would note that we already have the following non-IETF document that is going
to make changes to the IANA registry http://www.w3.org/TR/WebCryptoAPI
jim
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts
Now for other edits and questions:
Section 3.6 - Can you explain why would this be included? If you are not going
to sign, I am not sure why one would use JOSE at all.
Section 5.2 - The write up of this section seems a bit more complicated than
necessary. It seems it would have just been simpler to state that the sizes
vary as required by the algorithms and key lengths used rather than providing
the differences from one to the next. Can you simplify this?
After looking through some of the mailing list discussions, it seems there was
already agreement to slim this and other sections down by pointing to the
draft-mcgrew-aead-aes-cbc-hmac-sha2
http://www.ietf.org/mail-archive/web/jose/current/msg02276.html
Can I get an update as to where that stands, referencing what you can from that
draft as opposed to duplicating text? Thanks!
Security Considerations: While it is true the content is covered in other
places, this section could benefit from improvement before it goes to the
SecDir review. The second sentence in the first paragraph says the following:
Among these issues are
protecting the user's private and symmetric keys, preventing various
attacks, and helping the user avoid mistakes such as inadvertently
encrypting a message for the wrong recipient.
It would be helpful if you could expand the text and make it more descriptive
and applicable to this document. For example, shouldn’t the first section say
user’s private asymmetric and symmetric keys? I assume that is what was
intended with private, but it reads funny to me without that. The only
‘attack’ or caution mentioned in the document is for the application to prevent
a user from selecting the wrong key. Please include some attacks that
developers and implementers should be aware and cautioned on, or state that
specific attacks and considers are detailed in the subsections to follow.
I think that's it for now. Although I do need to look through some more of the
previous conversations on the mailing list and in the issue tracker.
I see there are some open discussions, like the one Richard raised yesterday
that need to be resolved in the document as well before we move forward with
this one. Thanks for all of your effort on this draft!!
--
Best regards,
Kathleen
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
