-
Notifications
You must be signed in to change notification settings - Fork 31
Timestamp verification fail #7
Comments
Thanks for opening this. I don't quite understand the issue you are having. It would be helpful if you could provide an example of a signature/timestamp that isn't working but should be. This library should support all of the algorithm OIDs you list. I think you may have the wrong values for Here are the OIDs I see for those algorithms: oidSignatureECDSAWithSHA256 = asn1.ObjectIdentifier{1, 2, 840, 10045, 4, 3, 2}
oidSignatureECDSAWithSHA384 = asn1.ObjectIdentifier{1, 2, 840, 10045, 4, 3, 3}
oidSignatureECDSAWithSHA512 = asn1.ObjectIdentifier{1, 2, 840, 10045, 4, 3, 4} |
Sorry for the confusion, I pasted wrong OIDs for ECDSA indeed, but the timestamp verification fails for The logic in
I think you should create another map for: and use it without |
Just get some TS responses for publicly available TSA and test your timestamp package with 3rd party responses. You will see the failures. |
I think that makes sense. The spec says
So, I need to support signature+digest algorithm (eg. SHA256WithRSA) in the SignatureAlgorithm in addition to just the signature algorithm (eg. RSA). If both signature and digest algorithm are specified in the SignatureAlgorithm should the SignerInfo's DigestAlgorithm not be checked at all? What if the DigestAlgorithm is SHA256, but the SignatureAlgorithm is RSAWithSHA1? The spec isn't very clear on this. |
All the public timestamp authorities I've worked with just specify RSA (1.2.840.113549.1.1.1) for the SignatureAlgorithm. For example here is a timestamp from GlobalSign. An example that specifies signature+digest algo would be helpful for writing a test of this behavior. |
You are correct, I also found bunch of Based on my understanding of the standard:
the code should have a look up for complete |
Is it an invalid message if the SignatureAlgorithm is RSAWithSHA1, but the DigestAlgorithm is SHA256? |
There are two places where digest is used:
Looks like if digest algorithm is the same in Signature and in Digest, then some vendors ise PublickeyAlgorithm in SignatureAlgorithmIdentifier and combine it with DigestAlgorithm, as we saw above. |
I'm testing the following logic based on your code:
Seems to be working with all 3rd party TSR that I've got. |
Many signature protocols use a format that is _technically_ backwards compatible with CMS. However, these incompaiblities are minor and can be avoided by removing the check for octets.Tag == asn1.TagOctetString. By just returning the octets.Bytes without checking the tag, old-style PKCS github#7 signatures can now be created and verified without issue. Signed-off-by: Joe Richey <joerichey@google.com>
Many signature protocols use a format that is _technically_ backwards compatible with CMS. However, these incompaiblities are minor and can be avoided by removing the check for octets.Tag == asn1.TagOctetString. By just returning the octets.Bytes without checking the tag, old-style PKCS github#7 signatures can now be created and verified without issue. Signed-off-by: Joe Richey <joerichey@google.com>
in the the function
func (sd *SignedData) verify
there is a loop
The line 123 fails, for RSAWithSHA1 signature: OID 1.2.840.113549.1.1.11
The following map is wrong when your code deals with external Timestamp servers.
You should support the following mappings from SignerInfos:
The text was updated successfully, but these errors were encountered: