Subject: [jose] Disscussion Issue - Algorithm Parameters

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 May 2012 15:55:59 -0700

<no hat>

An issue I would like to see some discussion on 

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?

As an example of this, the RSA-OAEP algorithm needs to specify two
parameters:  The mask function and a hash function.  We can say that these
are to be encoded in the name of the algorithm (i.e. RSA-OAEP-mf1-sha256) or
we can change the alg parameter to allow for the following:

Either a string specifying the name of the algorithm (with defaults values
in some cases)  (i.e. alg: "RSA-OAEP-mf2-sha256")

OR

A JSON structure with the name of the algorithm and the parameters

alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" }

jim

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 22 May 2012 13:25:26 +1000

> alg: "RSA-OAEP-mf2-sha256"
> OR

Another option is:
  "alg": "RSA-OAEP"
  "mgf": "MGF1"
  "hash": "SHA-256"

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.

> 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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 May 2012 20:54:51 -0700

> -----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?
> 

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.
> * hardwiring the mask-generation function (to be MGF1 with the same hash
> algorithm) (so no "mgf" parameter is needed)

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 May 2012 05:49:48 +0000

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<http://tools.ietf.org/html/draft-rescorla-jsms-00#section-1> (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<http://self-issued.info/?p=378> 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

> From: Manger, James H [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

> To: Jim Schaad; [email-masked]<mailto:[email-masked]>

> > 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?

>   "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.

above)

> was the intention. This is why the algorithms spec (in sections 3.6

> and

4.11 for

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

> * 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

> James Manger

_______________________________________________

jose mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 22 May 2012 16:21:40 +1000

> better to have them scoped already.

That's what we have a registry for: "JSON Web Signature and Encryption Header Parameters Registry".

If you encrypt a session key with RSA-OAEP and use HMAC for integrity, you can theoretically use 3 different hash algorithms (in OAEP, in mask generation, in HMAC). Hence, defining one "hash" header parameter would not be sufficient. In practice I doubt this will be a problem (in this case requiring the 3 hash algorithms be consistent is likely to be a good restriction).

The problem I see down the road is when some software wants to, for instance, pass just the parameters relating directly to the plaintext onto another module. Today, it would keep "typ" and remove "alg", "int", "jku", "kid", "jwk", "x5u", and "x5t". Tomorrow, the task gets increasingly awkward since new public and private parameters start appearing and software cannot automatically tell if they are related to the plaintext or to something else.

I am still willing to support a flat structure, however, for its simplicity.

--
James Manger

---

From: <[email-masked]>
Date: Tue, 22 May 2012 09:32:39 +0200

I agree with the fact that all described algorithms must be fully described to eliminate ambiguity. 
But we have to find a balance between long and complicated and short and simple.

With regard to RSA-OAEP I suggest to keep the name "RSA-OAEP" and describe the default parameters in the text or table-cell.
If an implementer chooses other parameters than the default then they could use your suggested format. alg: { name:"RSA-OAEP", hash: "PSI-384", mgf: "mgfX" }
Which then leads to the requirement that servers MUST reject the whole thing if one of the parameters is not supported.

Things are getting complicated. It is best to stay with the defaults (fully describe them in the text but keep the name) and leave other  parameters than default ones to extensions. 

I have implemented an early version of the JW? Specs in Java
https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/json/WebToken.java
which uses Bouncycastle
http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/asn1/pkcs/RSAESOAEPparams.html
which use sha1 and mgf1SHA1 as default.
These same defaults are specified in Table5 of http://self-issued.info/docs/draft-jones-json-web-encryption.html
"RSA using Optimal Asymmetric Encryption Padding (OAEP) 	RSA-OAEP 	http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p 	RSA/ECB/OAEPWithSHA-1AndMGF1Padding"

So everything in this spec (related to RSA_OAEP) looks fully specified to me. 
I see no reason to make things more complicated.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Tuesday, May 22, 2012 12:56 AM
To: [email-masked]
Subject: [jose] Disscussion Issue - Algorithm Parameters

<no hat>

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?

As an example of this, the RSA-OAEP algorithm needs to specify two
parameters:  The mask function and a hash function.  We can say that these are to be encoded in the name of the algorithm (i.e. RSA-OAEP-mf1-sha256) or we can change the alg parameter to allow for the following:

Either a string specifying the name of the algorithm (with defaults values in some cases)  (i.e. alg: "RSA-OAEP-mf2-sha256")

OR

jim

[email-masked]

---

From: George Fletcher <[email-masked]>
Date: Tue, 22 May 2012 11:36:46 -0400

+1

On 5/22/12 1:49 AM, Mike Jones wrote:
>
> 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 
> <http://tools.ietf.org/html/draft-rescorla-jsms-00#section-1> (with 
> *my emphasis*):
>
>    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*.  ...
>
>    applications to handle. *In the interest of simplicity, JSMS also*
>
> *   omits as many as possible of the CMS modes* (multiple signatures,
>
> In parallel, the consensus decisions in the design discussions behind 
> the JWE <http://self-issued.info/?p=378> design included:
>
> 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
>
> <mailto:[mailto:[email-masked]]>
>
> > To: Jim Schaad; [email-masked] <mailto:[email-masked]>
>
> 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.
>
> >
>
> [email-masked] <mailto:[email-masked]>
>

-- 
Chief Architect
Identity Services Engineering
AOL Inc.

---

From: <[email-masked]>
Date: Tue, 22 May 2012 18:50:37 +0200

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, May 22, 2012 7:50 AM
To: Jim Schaad; 'Manger, James H'; [email-masked]
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

   messages.  ...

                                                            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

above)

4.11 for

payload

is

jose mailing list

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 22 May 2012 09:53:52 -0700

I fully understand that you wanted to keep it simple.  That is why I
proposed having the option - either a string or a structure.   Allowing for
the structure allows people who want to have the complexity have it.  This
would not be the normal case.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Monday, May 21, 2012 10:50 PM
To: Jim Schaad; 'Manger, James H'; [email-masked]
Subject: RE: [jose] Disscussion Issue - Algorithm Parameters

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
<http://tools.ietf.org/html/draft-rescorla-jsms-00#section-1>  (with my
emphasis):

   messages.  ...

In parallel, the consensus decisions in the design discussions behind the
JWE <http://self-issued.info/?p=378>  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

> From: Manger, James H  <mailto:[mailto:[email-masked]]>
[mailto:[email-masked]]

> To: Jim Schaad;  <mailto:[email-masked]> [email-masked]

 

above)

4.11 for

payload

is

jose mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/jose>
https://www.ietf.org/mailman/listinfo/jose

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 22 May 2012 09:55:58 -0700

+1 on editing down available options in exchange for simplicity

On May 22, 2012, at 9:50 AM, <[email-masked]<mailto:[email-masked]>> wrote:

+1

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, May 22, 2012 7:50 AM
To: Jim Schaad; 'Manger, James H'; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

In parallel, the consensus decisions in the design discussions behind the JWE<http://self-issued.info/?p=378> 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.

                                                            Best wishes,
                                                            -- Mike

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, May 21, 2012 8:55 PM
To: 'Manger, James H'; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

above)
4.11 for
payload
is

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 May 2012 10:48:28 -0700

+1 on keeping it simple per the current design of of the algorithm being a single string

I have one implementation running and deployed and another being designed and prefer having only a few good crypto choices, but being extensible in case others are needed by having a different string. 

-- Dick

On May 22, 2012, at 9:55 AM, Chuck Mortimore wrote:

> On May 22, 2012, at 9:50 AM, <[email-masked]> wrote:
> 
>> +1
>>  
>> 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):
>>  
>> In parallel, the consensus decisions in the design discussions behind the JWE design included:

---

From: John Bradley <[email-masked]>
Date: Tue, 22 May 2012 13:48:25 -0400

The default set needs to be kept simple. 

They do need all the optional parameters nails down.  That should no change the default alg names. 

Defining extension composite algorithms is fine with whatever names. 

Keep the core ones simple so they work. 

John B. 

Sent from my iPhone

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 May 2012 02:52:09 +0900

+1

Less choice is better for the core.

=nat via iPhone

On 2012/05/23, at 2:48, Dick Hardt <[email-masked]> wrote:

+1 on keeping it simple per the current design of of the algorithm being a
single string

I have one implementation running and deployed and another being designed
and prefer having only a few good crypto choices, but being extensible in
case others are needed by having a different string.

-- Dick

+1

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Mike
Jones
*Sent:* Tuesday, May 22, 2012 7:50 AM
*To:* Jim Schaad; 'Manger, James H'; [email-masked]
*Subject:* Re: [jose] Disscussion Issue - Algorithm Parameters

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 <http://tools.ietf.org/html/draft-rescorla-jsms-00#section-1> (with
*my emphasis*):

In parallel, the consensus decisions in the design discussions behind the
JWE <http://self-issued.info/?p=378> 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

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.

                                                            Best wishes,
                                                            -- Mike

-----Original Message-----

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.

above)
4.11 for
payload
is

---

From: Edmund Jay <[email-masked]>
Date: Tue, 22 May 2012 12:10:27 -0700 (PDT)

+1 to keep things simple

________________________________
From: Mike Jones <[email-masked]>
To: Jim Schaad <[email-masked]>; "Manger, James H" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Mon, May 21, 2012 10:50:06 PM
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

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):

 
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.

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-----

> > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" }
 
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.

above)
4.11 for
payload
is

---

From: Edmund Jay <[email-masked]>
Date: Tue, 22 May 2012 13:18:17 -0700 (PDT)

I agree with Axel that specs should be simple and that the various algorithms' 
parameters default/supported values should be fully described.
I was working on adding AES-GCM support to my PHP library and the algorithm has 
options for IV size, tag size, and addtional authentication data. The JWE spec 
described what the parameter values should be or what values are supported. This 
cuts down on having to specify the values somewhere.
If the complicated way of using a JSON structure is added and the parameter 
values are the same as the defaults, then it pretty much means that all 
applications would need to support the complicated case just to read the default 
values.

________________________________
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Tue, May 22, 2012 12:32:59 AM
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

I agree with the fact that all described algorithms must be fully described to 
eliminate ambiguity. 

With regard to RSA-OAEP I suggest to keep the name "RSA-OAEP" and describe the 
default parameters in the text or table-cell.
If an implementer chooses other parameters than the default then they could use 
your suggested format. alg: { name:"RSA-OAEP", hash: "PSI-384", mgf: "mgfX" }
Which then leads to the requirement that servers MUST reject the whole thing if 
one of the parameters is not supported.

Things are getting complicated. It is best to stay with the defaults (fully 
describe them in the text but keep the name) and leave other  parameters than 
default ones to extensions. 

which uses Bouncycastle

which use sha1 and mgf1SHA1 as default.
These same defaults are specified in Table5 of 
http://self-issued.info/docs/draft-jones-json-web-encryption.html
"RSA using Optimal Asymmetric Encryption Padding (OAEP)     RSA-OAEP     
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p     
RSA/ECB/OAEPWithSHA-1AndMGF1Padding"

-----Original Message-----

<no hat>

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?

As an example of this, the RSA-OAEP algorithm needs to specify two
parameters:  The mask function and a hash function.  We can say that these are 
to be encoded in the name of the algorithm (i.e. RSA-OAEP-mf1-sha256) or we can 
change the alg parameter to allow for the following:

Either a string specifying the name of the algorithm (with defaults values in 
some cases)  (i.e. alg: "RSA-OAEP-mf2-sha256")

OR

jim

---

From: Brian Campbell <[email-masked]>
Date: Tue, 29 May 2012 06:26:34 -0600

+1

On Tue, May 22, 2012 at 10:55 AM, Chuck Mortimore
<[email-masked]> wrote:
> the introduction to JSMS (with my emphasis):
>
> JWE design included: