Subject: [Ipsec] Doubt regarding Encoding method for RSA signatures

From: Suram Chandra Sekhar <[email-masked]>
Date: Thu, 02 Jun 2005 09:56:34 +0530

Hi,
I have a question on Encoding method for RSA signature as specified in the 
ikev2-clarification-document.

In Section 2.2,
    Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
    signature encoding method (see next section for details), which
    includes the algorithm identifier for the hash algorithm.

Here it is said that IKEv2 uses the PKCS#1 v1.5.

The next section
Section 2.3 specifies as follows...

    The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different
    encoding methods (ways of "padding the hash") for signatures.
    However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20].  That
    version has only one encoding method for signatures
    (EMSA-PKCS1-v1_5), and thus there is no ambiguity.

In this section it is said that IKEv2 points to the older PKCS#1 v2.0.

Is this a typo or both the versions are same??

The next question is PKCS#1v2.0 (rfc 2437) is obsoleted by PKCS#1v2.1 (rfc 
3447).

The problem is that, for the encoding method EMSA-PKCS1-v1_5 looks 
different in both the versions.

Section 9.2.1 of PKCS#1 v2.0 (rfc 2437) specifies the padding to form the 
encoded message as follows...

   5. Concatenate PS, the DER encoding T, and other padding to form the
      encoded message EM as: EM = 01 || PS || 00 || T

Section 9.2 of PKCS#1v2.1 (rfc 3447) specifies the padding to form the 
encoded message as follows..

    5. Concatenate PS, the DER encoding T, and other padding to form the
       encoded message EM as

          EM = 0x00 || 0x01 || PS || 0x00 || T.

In version 2.1 of PKCS#1, the encoding starts with 00 01 where as in 
version 2.0 of PKCS#1,
the encoding starts with 01.

I want to know the following things..

1. Why is it decided to go with an obsoleted rfc.
2. I see there is ambiguity with padding between v2.0 and v2.1 of 
PKCS#1.  Can this be clarified further.

I feel it can refer to the new version PKCS#1 v2.1 (rfc 3447) with the 
encoding method as only EMSA_PKCS1_V1_5.
Also as specified in the clarification document, hash function can be 
recommended to be SHA1.

Please clarify on this.

Regards
Suram

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Thu, 2 Jun 2005 16:30:38 +0300

Suram Chandra Sekhar wrote:
>
> Hi,
> I have a question on Encoding method for RSA signature as specified
> in the ikev2-clarification-document.
> 
> In Section 2.2,

IKEv2 uses the "PKCS#1 v1.5" encoding method and signature
generation/verification operations; the definition for these
can be found in several different documents, including the
original PKCS#1 v1.5 (also RFC 2313), v2.0 (also RFC 2437) 
and v2.1 (also RFC 3447).

The "v1.5" signature generation/verification operations defined
in all those documents are compatible (but written slightly
differently).

> The next question is PKCS#1v2.0 (rfc 2437) is obsoleted by 
> PKCS#1v2.1 (rfc 3447).
> 
> The problem is that, for the encoding method EMSA-PKCS1-v1_5 
> looks different in both the versions.
> 
> Section 9.2.1 of PKCS#1 v2.0 (rfc 2437) specifies the padding to
> form the encoded message as follows...
>
>  5. Concatenate PS, the DER encoding, and other padding to
>     form the encoded message EM as: 
>     EM = 01 || PS || 00 || T
> 
> Section 9.2 of PKCS#1v2.1 (rfc 3447) specifies the padding to form
> the encoded message as follows..
>
>  5. Concatenate PS, the DER encoding T, and other padding to 
>     form the encoded message EM as  
> In version 2.1 of PKCS#1, the encoding starts with 00 01 where as 
> in version 2.0 of PKCS#1, the encoding starts with 01.

Adding zeroes in front of the message does not matter for RSA
operations, because they treat the message as a non-negative
integer. So if one implementation implements RSA signature
generation/verification according to v2.1 and another 
implementor uses v2.0, they're still compatible.

> 1. Why is it decided to go with an obsoleted rfc.

No reason (or more likely, the reference was put there before
RFC 3447 was published, and nobody updated it). The RFC editor
might fix the reference to point to the latest version.

> 2. I see there is ambiguity with padding between v2.0 and v2.1 
> of PKCS#1.  Can this be clarified further.

We'll try to rephrase the text slightly when doing clarifications 
version -04.

> I feel it can refer to the new version PKCS#1 v2.1 (rfc 3447) with
> the encoding method as only EMSA_PKCS1_V1_5.  Also as specified in
> the clarification document, hash function can be recommended to be
> SHA1.
> 
> Please clarify on this.
>
> Regards
> Suram

Best regards,
Pasi