Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Wed, 23 May 2012 01:57:59 -0700

I don't understand many of the specifics, but I'm totally for the spirit
of this proposal.

We may have great crypto algorithms, but they're only as usable as
mainstream developers find them easy to implement.

So let's have simple "alg" strings that package well chosen
combinations. People who choose to have something different can create
their private "alg" identifiers and/or header parameters (it appears to
me that with some careful design both methods for describing custom algs
should be possible).

+1

--
Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]

-------- Original Message --------
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters
From: Mike Jones <[email-masked]>
Date: Tue, May 22, 2012 6:49 am
To: Jim Schaad <[email-masked]>, "'Manger, James H'"
<[email-masked]>, "[email-masked]" <[email-masked]>

  As background on the current spec design, both JSMS and the JWS family
of specs independently made a conscious design choice to specify a
small, limited set of cryptographic algorithms and algorithm
combinations to simplify implementations and increase interoperability. 
Quoting from the  introduction to JSMS (with my emphasis):
  
    Many applications require the ability to send cryptographically
    secured (encrypted, digitally signed, etc.) messages.  While the
IETF
    has defined a number of formats for such messages,  those formats
are
    widely viewed as being excessively complicated for the demands of
Web
    applications, which typically only need the ability to secure simple
    messages.  ...
  
    This document describes a new cryptographic message format,
    JavaScript Message Security (JSMS) intended to meet the need of the
    Web environment.  While JSMS is modeled on existing formats --
    principally CMS [RFC5652] -- it uses JavaScript Object Notation
    (JSON) rather than ASN.1/BER/DER, making it far easier for Web
    applications to handle.  In the interest of simplicity, JSMS also
    omits as many as possible of the CMS modes (multiple signatures,
    password-based encryption).
  
 In parallel, the consensus decisions in the  design discussions behind
the JWE design included:
     “we should specify a small set of composite operations that will
meet the needs of common use cases”
  
 We’re trying to make simple things simple to facilitate widespread
deployment of strong crypto.  The alternative is XML ENC, where all
parameters and parameter combinations *can* be specified but with no
guarantees that any particular combination, other than a
mandatory-to-implement set, will actually be supported or interoperable
among any particular implementations.
  
 I believe that the designers of both sets of JOSE precursor specs
reached the conclusion that simple specs with a small set of useful,
widely implemented, carefully chosen cryptographic primitives and
combinations would be of more practical value to developers and result
in more deployment and interoperability than a highly general spec that
allows for a large combinatorial set of parameter combinations.
  
 If new parameter combinations are needed in practice, they can easily
be specified in the JWA spec or in the registries that it defines.
  
 I hope that understanding this rationale behind the intentionally
limited sets of algorithms specified in both JSMS and JWA will be useful
to the working group.
  
                                                             Best
wishes,
                                                             -- Mike
  
 -----Original Message-----
 From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jim Schaad
 Sent: Monday, May 21, 2012 8:55 PM
 To: 'Manger, James H'; [email-masked]
 Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

 > -----Original Message-----
 > From: Manger, James H  [mailto:[email-masked]]
 > Sent: Monday, May 21, 2012 8:25 PM
 > To: Jim Schaad; [email-masked]
 > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters
 > 
 > > Should an algorithm be able to specific parameters rather than 
 > > making them part of the algorithm name string?  If so should we 
 > > change the way that we are doing parameters to allow for this
better?
 > 
 > > alg: "RSA-OAEP-mf2-sha256"
 > > OR
 > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" }
 > 
 > 
 > Another option is:
 >   "alg": "RSA-OAEP"
 >   "mgf": "MGF1"
 >   "hash": "SHA-256"
  
 That is an option that is doable as well.  I happen to think that it
might lead to problems down the road.  If you have two algorithms in the
header, then one must make sure that there is no possibility that the
two algorithms will want to use the same field.  
  
 Given that anybody can define a new algorithm, it is not possible to do
an exhaustive search for collisions in the use of field names.  It might
be better to have them scoped already.

 > 
 > I suspect additional parameters in the header (like "mgf" and "hash"
 above)
 > was the intention. This is why the algorithms spec (in sections 3.6 
 > and
 4.11 for
 > signature and encryption algorithms) says: "additional reserved
header 
 > parameter names MAY be defined".
 > The result is a flat structure for all sorts of parameters: about the
 payload
 > ("typ"); about JWE processing ("enc", "int"); about a specific 
 > algorithm ("mgf", "hash") etc.
 > A flat structure will cause headaches at some point (cf trying to 
 > separate transport and content details from HTTP's flat header 
 > structure), but it
 is
 > simpler to start with.
 > I suggest we stick with a flat structure for JOSE.
 > 
 > 
 > 
 > > As an example of this, the RSA-OAEP algorithm needs to specify two
 > > parameters:  The mask function and a hash function.
 > 
 > For RSA-OAEP specifically, I suggest:
 > * picking one hash algorithm (SHA-256) and including it in the name 
 > "RSA- OAEP256"
 > * hardwiring the mask-generation function (to be MGF1 with the same 
 > hash
 > algorithm) (so no "mgf" parameter is needed)
 > * hardwiring the label to be empty.
 > 
 > The resulting spec text could be:
 > =====
 > 4.5 "RSA-OAEP256"
 > 
 >   The "RSA-OAEP256" key encryption algorithm is RSA encryption with
 >   Optimal Asymmetric Encryption Padding (OAEP) using SHA-256.
 >   The algorithm is specified in PKCS#1 [RFC 3447], where it is
 >   called RSAES-OAEP-ENCRYPT.
 > 
 >   The hash function is SHA-256 [FIPS 180-4].
 > 
 >   The mask generation function is MGF1 [RFC 3447], using SHA-256 as
 >   the hash function.
 > 
 >   The label is the empty string.
 > =====
 > 
 > --
 > James Manger
  
 _______________________________________________
 jose mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose