Subject: Re: [IPsec] Last Call: <draft-kivinen-ipsecme-signature-auth-06.txt> (Signature Authentication in IKEv2) to Proposed Standard

From: Johannes Merkle <[email-masked]>
Date: Mon, 25 Aug 2014 14:10:38 +0200

Tero,

you haven't responded to my objection yet. Please let me know if you think that I am mistaken; otherwise the example
should be corrected.

Johannes

Johannes Merkle wrote on 25.07.2014 11:39:
> Tero,
> 
> thanks for updating the document. However, I'm not sure the first issue is solved.
> 
> Tero Kivinen wrote on 20.07.2014 21:02:
>> Changed to:
>>
>> 	With RSASSA-PSS, the algorithm object identifier must always
>> 	be id-RSASSA-PSS, and the hash function and padding parameters
>> 	are conveyed in the parameters (which are not optional in this
>> 	case). See <xref target="RFC4055"/> for more information.
>>
>> In the RSASSA-PSS the parameters are required, but they can be empty,
>> so they are not optional in this case.
>>
> 
> Really? Section 3.1 of RFC 4055 states
>    When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters
>    MUST employ the RSASSA-PSS-params syntax.  The parameters may be
>    either absent or present when used as subject public key information.
> 
> My understanding of this is that the parameters can indeed be absent not just empty.
> 
> IMHO the semantic is different: If the parameters are empty (empty sequence in RSASSA-PSS-param), the default values
> apply, and according to Section 3.3, case 3, of RFC 4055, the parameters in a signature MUST be validated against the
> (default) parameters specified in SPKI. However, if the parameters are absent, then, according to Section 3.3, case 2,
> of RFC 4055, no parameter validation is needed in a signature validation, i.e. a signature may use any parameters.
> 
> Maybe, I misinterpret the spec here?
> 
> 
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Aug 2014 15:42:25 +0300

Johannes Merkle writes:
> you haven't responded to my objection yet. Please let me know if you
> think that I am mistaken; otherwise the example 
> should be corrected.

I have not have time to come back to this draft yet, I was still
supposed to be on vacation for last week and this week, but I had to
get back to get the RFC5996bis stuff going, so thats why I have been
trying to concentrate on that.

Yes, I think you are right that the change I made in there might not
be correct. I need to try to parse the RFCs more to try to find out
how the RSASSA-PSS parameters are supposed to be included. There is
also cases that inside the parameters there is hash and mgf
algorithms, which have parameters and they have again different rules
whether they needs to be include, absent etc...

The RSASSA-PSS is so complicated that getting things right seems to
require multiple readings of the RFCs to parse everything right :-)

Luckily all this text is non-normative, the implementors are supposed
to be reading the other RFCs for real specifications, but that does
not mean we can write anything that is wrong here either... 
-- 
[email-masked]