Re: [Cfrg] Question from JOSE working group

More precisely:
RSASSA-PKCS1-v1_5 includes the hash algorithm under the signature
RSASSA-PSS (introduced in PKCS#1 v2.1) does not include the hash algorithm

Doesn't this seem to argue against the need to protect parameters, since the security of RSASSA-PSS is tightly related to the RSA problem itself?  

On Jul 3, 2012, at 1:43 PM, Jim Schaad wrote:

> I would also note that when PKCS#7 was designed, the hash algorithm was
> always protected independent the presence of signed attributes.  Either the
> hash algorithm was in the signed attributes or it was in the RSA signature
> block encoding.   It was only with the introduction of other algorithms that
> this was no longer true.
> 
> Jim
> 
> 
>> -----Original Message-----
>> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
>> Russ Housley
>> Sent: Tuesday, July 03, 2012 8:02 AM
>> To: Richard L.Barnes
>> Cc: cfrg@irtf.org; jose@ietf.org
>> Subject: Re: [Cfrg] Question from JOSE working group
>> 
>> Richard:
>> 
>>> Actually, the inclusion of the hash algorithm under the signature is
> optional:
>>> "
>>>     signedAttrs is a collection of attributes that are signed.  The
>>>     field is optional, but it MUST be present if the content type of
>>>     the EncapsulatedContentInfo value being signed is not id-data.
>>>     [...]  If the field is present, it MUST
>>>     contain, at a minimum, the following two attributes:
>>> 
>>>        ...
>>> 
>>>        A message-digest attribute, having as its value the message
>>>        digest of the content.  Section 11.2 defines the message-digest
>>>        attribute.
>>> "
>>> 
>>> Since "id-data" means "no more ASN.1 structure", for JOSE, the content
>> type is effectively always "id-data".
>> 
>> In practice, there are other attributes that one wants signed, such as
> signing-
>> time, so the algorithm identifier gets included.
>> 
>> Russ
>> 
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
> 