From: jose [mailto:[email protected]] On Behalf Of Richard Barnes Sent: Wednesday, April 16, 2014 7:35 AM To: John Bradley Cc: Hannes Tschofenig; [email protected] Subject: Re: [jose] Implementation Requirements
Let me address this in two parts, first with my IESG hat on, and then as an individual. <hat type="IESG"> The IESG does NOT think that a set of mandatory algorithms in JWA is a requirement for interoperability. After having discussed this with Kathleen and Sean: There are several different ways to address interoperability with a framework protocol like JOSE. CMS provides a fine example of how algorithms can be left flexible at the security layer, with applications like S/MIME defining algorithm requirements. Algorithm agility is another important consideration in security protocol design, and locking in algorithms too deeply can hinder updates in the future. </hat> <hat type="individual"> I continue to be concerned that having mandatory algorithms for JOSE will make two types of applications non-compliant: 1. JOSE implementations are often going to not have any choice in what algorithms they can support. They're going to be built on top of crypto libraries, which either support an algorithm or they don't. It's pointless to levy requirements at the JOSE layer. 2. Constrained devices aren't going to want to implement a whole boatload of algorithms, just the ones they need for their use cases. [JLS] I am not sure that I understand the reasoning behind this. For point 2 - an application can specify a set of algorithms that are not even mentioned by the JOSE specifications. This is what I would expect to potentially happen for the constrained device case, the application being running here would say we use the following algorithms - independent of the JOSE specs say. Application specs will always override our specs. For point 1 - that is always true and has always been true for applications that use system crypto. S/MIME could mandate the use of EC, but if it is not supported on the OS and the implementation uses the OS for its crypto - then the application will not be able to do anything with EC algorithms. The same thing is also true with out of date libraries or applications. The set of required algorithms has changed, but not all of the software installations have been upgraded (can you say RC4 in TLS and SSL 3.x in general). jim Limiting the requirement to "standalone JOSE libraries" doesn't address either of these concerns. As a compromise, how about if we define a RECOMMENDED suite of common algorithms? That would help guide implementations toward interop without ruling out the above use cases. </hat> Hope that helps clarify things, --Richard On Mon, Apr 14, 2014 at 9:09 AM, John Bradley <[email protected]> wrote: The IESG wants to see interoperability between implementations, to do that without dragging in discovery etc there need to be minimum feature sets of JOSE libraries that people can count on. A application using JOSE can elect not to support all the algorithms, but JOSE libraries need to support the mandatory to implement algorithms. On Apr 14, 2014, at 9:48 AM, Hannes Tschofenig <[email protected]> wrote: Hi all, I am looking at the implementation requirements of the JWA spec and I am wondering to what deployment environment they refer they. The JW* specs are generic building blocks and I fail to see how one can list mandatory-to-implement algorithsms. Ciao Hannes _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
