Thanks Andreas and Tobias for your reply. Is there a reason why a new errata was not reported with the 2nd and 15th byte changed (rightly done as in the current strongswan identifier/ASN.1 blob) from the rejected errata?
Just want to know which ASN.1 blob we should use to interop and maybe standardise/generalise it since the RFC ASN.1 blob (72 byte long) and the rejected errata are wrong. Regards, Sahana Prasad On Mon, Feb 5, 2018 at 11:19 AM, Tobias Brunner <[email protected]> wrote: > Hi Sahana, > > > Question 1 : Difference in OID bytes : > > > > The 67 bytes ASN.1 OID that should be sent as per the errata from 7427 > > (https://www.rfc-editor.org/errata_search.php?rfc=7427) and the 67 > > bytes that I receive from strongswan are different. > > Please note that both of these erratas were rejected. And as Andreas > mentioned the second errata's ASN.1 encoding is incorrect. While the > ASCII length was changed the ASN.1 encoding was not. > > > Question 2 : Calculation of RSA signature > > > > To calculate the 128 byte signature, the 67 bytes OID plus the 32 bytes > > hash (sha256) is considered right? > > No, the signature is built as specified in RFC 7296, section 2.15. The > length and OID are just added in front of the signature value within the > Authentication Data field of the Authentication payload. > > > Is there a way to see the hash that is generated? I have all logs > > enabled, but do not see the hash value. I can only see the 128 > > byte rss-signature that gets added to the 204 byte long auth payload > > There are no log messages that print the value to be signed. > > Regards, > Tobias >
