> From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton
> Sent: Saturday, 06 October, 2012 19:11
> On Sat, Oct 6, 2012 at 5:41 PM, Charles Mills
> <charl...@mcn.org> wrote:
> > Thanks. I'm a relative newbie to this whole topic. Can you
> point me to a resource that describes "pin" in the sense you
> use it below? The word is too common for the Google to be much help.
> >
> If you are using RSA, then the public key is {e,n}. When a client
> connects to a server, the client ensures the {e,n} in the server's
> certificate is expected. You can usually find it at certificate[0]. In
> essence, you have white listed the {e,n} pair for the host in
> question.
>
> If using ECC, you have two items to verify: the [public] point and
> domain parameters. For prime fields, the public key is the point, Q
> (or (qx, qy)), and the domain parameters are {p, a, b, G, n, h} (G is
> a base point and sometimes denoted as (gx,gy) pair). Again, its a
> whitelist of expected values for the host.
>
In principle yes, but in practice most ECC uses the few parametersets
(curves) established by standards and assigned OIDs which (are used to)
identify them. In this case you need only check the OID.
Similarly for classic DSA, you have publickey y and parameters
consisting of large prime p, medium subgroup order q and its
generator g. p,q,g can be shared and could be standardized but
to my knowledge aren't. p,g for classic DH also can be standardized
and were in some cases like ssh and IPsec but AFAIK not for SSL,
and any DH for SSL is rare and static-DH not supported by openssl.
> If you are using ephemeral key exchanges, then certificate[0] will be
> a temporary, throw away key. Ephemeral is good because it provides
> forward secrecy. In this case, the server's certificate/public key is
> used for authentication, and the public key of interest can be found
> at certificate[1]. certificate[1] must sign certificate[0] (some hand
> waiving since certificates can't sign one another).
>
Not in SSL. If you use *static* DH or ECDH, you have that key in cert[0],
which is authenticated by cert[1], and cert[1] further chained as needed.
But as above openssl doesn't support static-DH; it does do static-ECDH,
but I've never seen that used. If you use *ephemeral* those keys are
in separate messages (ServerKeyExchange and/or ClientKeyExchange) not
in any cert. If you use anonymous, again the keys are in S,CKeyExchnage
and there are no certs in the handshake at all.
Yes, ephemeral either DH-E or ECDH-E does have the advantage of forward
secrecy -- but warning, current Java's standard implementation (JSSE)
on server for DH-E uses 768-bit, which isn't adequately secure when used
much less forward. (For ECDH-E most if not all named curves are okay,
and can be limited by the client, and maybe preferred, I'm not sure.)
Other protocols can be different, but it would be impractical to get
valid certs for ephemeral keys unless you are your own online CA, and
then it really give better assurance than using a (static signing) cert
to authenticate the bare key as SSL does.
A certificate, or a publickey, doesn't actually sign anything; the
corresponding privatekey does. But a certificate can carry, and be
marked in KU and/or EKU as carrying, the public half of a privatekey
used to sign certs, CRLs, data, email, etc. Which is what people
mean when they say this, and not really confusing or ambiguous.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
