On 3/22/2011 12:31 PM, Massimiliano Pala wrote:
Hi Douglas,
the issue here is to be sure that things are done correctly - e.g., for testing
that the crypto used by the CA issuing a certificate is ok. In any case, the NID
from the signer can be missing (in fact, AFAIK, the curves should be provided
with
explicit params - implicit params are deprecated) - so you can not (1) rely on
the presence of the NID, and (2) trust that the issuer is not lying.
RFC 3279, http://www.ietf.org/rfc/rfc3279.txt would imply that that is correct.
But it is updated by RFC 5480, http://www.ietf.org/rfc/rfc5480.txt
In section 2.1.1 it says: "implicitCurve and specifiedCurve MUST NOT
be used in PKIX" which leaves only namedCurve.
It also says:
"The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place
within a certificate where the elliptic curve domain parameters may
be located. If the elliptic curve domain parameters are not present,
then clients MUST reject the certificate."
So I would say to based on RFC 5480, (1) it must have a NID.
(2) I would think you could verify a self signed certificate in the same way,
using the standard verify.
If the issuer is lying about the NID - then I don't trust it... checking is
always good! :D Also, I might have the CA as a trusted anchor but I might want
to restrict the usage of certificates that have been signed with a particular
group.. (that's my goal).
So if you require RFC 5480, given the namedCurve from the signers
AlgorithmIdentifier within the SubjectPublicKeyInfo of the signer
should define the group.
Or am I still missing something?
Thanks for your help and comments!
Cheers,
Max
On 03/22/2011 12:02 PM, Douglas E. Engert wrote:
On 3/22/2011 10:10 AM, Massimiliano Pala wrote:
Hello Stephen, all,
thanks for all the advices, I ended up doing the following:
1. Grab the Key from the Certificate
2. Cycle through the built-in curves
3. Generate a new point from the Key's group
4. if order(curve[i]) == order(key) and point is on curve[i]
==> curve found! ; return nid
5. i++ ; goto 4
This works. By comparing the nid with the "required" nid, I shall be
guaranteed that the key used to signed is on the specific nid.
Do you see any flaws ?
I am not sure if the above is correct or not, but the process of verifying
the signature should verify the curve is correct as well. During the verify
you have the pubkey of the signer, the (questionable?) curve NID from
the signer,
the certificate to be verified and its signature.
Your verify routine takes the NID and maps it to the built-in curve
parameters,
contained in the openssl library. So you know the signature is valid, using
the built-in parameters of the named curve. (You must be trusting the
openssl
library to have the correct curve parameters, is any case.)
So I don't see why you can not trust the NID in the signer's certificate
is valid.
If you don't trust the the signer has provided the correct NID, why would
you trust the signer for anything else?
BTW, for check of point 4 -> I had to add it because otherwise I had
multiple hits on different curves. Initially I expected that that check
would be performed in the EC_POINT_is_on_curve().. maybe is a check
that should be added there ?
Cheers,
Max
On 03/22/2011 10:47 AM, Dr. Stephen Henson wrote:
On Tue, Mar 22, 2011, Massimiliano Pala wrote:
Hello Peter, all,
thanks for the hint.. but I was actually looking more at a way to
check if
a certificate has been signed with one of the curves you listed.
Maybe it is
not possible, but it would be nice to be able to say "this
certificate has
been signed with P-256" - since this can be a requirement for
rejecting or
accepting a certificate.
The other solution is to extract the key from the signer's
certificate, check
the signature with it and, if it checks out, check that the key is of a
particular curve... is there any better way to do it ?
Are you talking programattically or by parsing text output of an OpenSSL
utility? It should be easy enough programatically.
BTW as regards curve names and their NID equivalents: I looked into
this for
the ECDSA tests for the latest validation. There's a translation
function in
fips/ecdsa/fips_ecdsavs.c which I'm fairly confident is correct as it
passes
the test vectors I've thrown at it.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
--
Douglas E. Engert <[email protected]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
