ietf-smime
[Top] [All Lists]

RE: missing algorithm parameters of signatureAlgorithm inside SignerInfo

2008-01-03 14:07:08

I have a number of questions that need to be answered before I can give you
a correct answer.


1.  What does the appropriate specification state is suppose to be present?
RFC3278 states that the correct SignatureAlgorithm parameters are NULL for
ecdsa-with-SHA1.

2.  Are you looking for the Public Key parameters or the Signature Algorithm
parameters.  Please note that these are different and need to be kept
separately. 

Public key parameter MUST be obtained from the certificate (for certificate
based systems).
Signature algorithm parameters MUST be obtained from the
SignerInfo.signatureAlgorithm


jim

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Maxim Masiutin
Sent: Thursday, January 03, 2008 6:28 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: missing algorithm parameters of signatureAlgorithm inside
SignerInfo


I have discussed this issue with Russ Housley and have decided to bring
it to the public concern. Russ have proposed to deal depending on a
particular algorithm. I, in contrast, think that this issue is abstract
and is not related  to any particular algorithm.

Could you please suggest how to deal with the missing algorithm
parameters of signatureAlgorithm inside SignerInfo type of SignedData?

I have found a message signed by an elliptic curve algorithm where
signature algorithm parameters of signatureAlgorithm inside SignerInfo
where empty, and the elliptic curve algorithm didn't work without the
parameters. If I take the parameters from SubjectPublicKeyAlgorithm of
signer's certificate (sid SignerIdentifier), then the signature
verification was successful.

1.      Is it allowed to take algorithm parameters from signer's
certificate if they are omitted in signatureAlgorithm of SignerInfo, or
I should treat such a signature as invalid?
2.      If the parameters are both present and different, should I
treat the signature as invalid or one parameter should overwrite
another?

Should we cover this case in a next revision of RFC3369?

Thank you in advance, and Happy New Year.


<Prev in Thread] Current Thread [Next in Thread>