Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

[Yaron Sheffer <[e-mail]>]

Hi Tero,

Thanks for your response, I am fine with your comments but I have a 
question: in Sec. 4.2, we have: "With the use of Digital Signature, 
RSASSA-PKCS1-v1.5 MAY be implemented.  RSASSA-PSS MUST be implemented." 
And then the table has SHOULD for RSA (as well as ECDSA). How come?

Coming to think of it, if we want to ensure interoperability between 
peers that use RSA certs and peers that use ECDSA certs, then at least 
one (probably RSA) needs to be a MUST, even if people are using RFC7427.

Thanks,
	Yaron

On 04/11/2016 02:47 PM, Tero Kivinen wrote:
> Yaron Sheffer writes:
>> 4.1: have we considered making "Digital Signature" (#14) a SHOULD+
>> instead of a SHOULD?
>
> Yes, I think we discussed it, but I think we should really see at
> least one implementation before we pick it as SHOULD+ level...
>
> Has anybody implemented this yet?
>
> This is still quite new, i.e., about year old, and as product cycles
> tend to be quite slow in the VPN gateways, I have not yet seen any
> implementations.
>
>> 4.2: aren't we trying to move the world to the generic "Digital
>> Signature", even if they're still using old certs?
>
> Yes.
>
>> If we are, then (gasp) PKCS1 v1.5 needs to be SHOULD.
>
> Why? There is no relationship between the RSASSA-PSS and
> RSASSA-PKCS1-v1.5 signatures in the certificates and in the AUTH
> payload.
>
> I.e., you can have RSASSA-PKCS1-v1.5 signature in the certificate, and
> use the RSASSA-PSS with SHA-256 to generate the AUTH payload.
>
> Also as we do say that RSASSA-PSS MUST be implemented, that means that
> every implementation which sends out the SIGNATURE_HASH_ALGORITHMS and
> conforms to this document, must support RSASSA-PSS, thus
> implementations can always use it when using RSA keys.
>
> Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427
> implementations which are made before this 4307bis document came out,
> and which do not support RSASSA-PSS required here.
>
>> And the table should mention sha256WithRSAEncryption.
>
> Which by defination is then MAY. And it is MAY because it is not using
> SHA1 (which would make it SHOULD NOT), and it is using old
> RSASSA-PKCS1-v1.5 which is only MAY.
>
> We did remove all MAY lines from the table in last round.
>