Subject: [pkix] Guidance on using the same key for key establishment and signing data

From: "Timothy J. Miller" <[email-masked]>
Date: Thu, 24 Sep 2009 08:27:50 -0500

I *think* this came up on this list before, but I can't find a 
reference.  Has any standards body (e.g. NIST) published guidance on 
servers using the same keypair for key establishment (e.g., SSL) and 
data signing (e.g. XML-Dsig)?

aTdHvAaNnKcSe.

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Thu, 24 Sep 2009 10:03:50 -0500

Paul Hoffman wrote:

> Do you consider "don't do it" to be guidance? NIST requires that a public key be used for only one purpose in a handful of their documents. I don't believe that it fully justifies this requirement anywhere, but I could be wrong. The best reason that I have heard is that most organizations have very different escrow policies for encryption keys than for signing keys, and having one key do both would muddle the policy. To me, that's a good enough argument, and it trumps "but I only want to manage one private key".

SSL/TLS using DHE key agreement would only be used the key pair for 
digital signature.  Key encipherment or key agreement would only be 
needed for the DH and RSA key exchange ciphersuites.  In cases where the 
ciphersuite is limited to DHE key exchange, would you agree one key for 
both uses is acceptable?

-- Tim

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Sep 2009 07:44:48 -0700

At 8:27 AM -0500 9/24/09, Timothy J. Miller wrote:
>I *think* this came up on this list before, but I can't find a reference.  Has any standards body (e.g. NIST) published guidance on servers using the same keypair for key establishment (e.g., SSL) and data signing (e.g. XML-Dsig)?

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 24 Sep 2009 11:34:01 -0400

Timothy J. Miller wrote:
> Paul Hoffman wrote:
>
>> Do you consider "don't do it" to be guidance? NIST requires that a 
>> public key be used for only one purpose in a handful of their 
>> documents. I don't believe that it fully justifies this requirement 
>> anywhere, but I could be wrong. The best reason that I
> have heard is that most organizations have very different escrow 
> policies for encryption keys than for signing keys, and having one key 
> do both would muddle the policy. To me, that's a good enough argument, 
> and it trumps "but I only want to manage one private key".
>
> needed for the DH and RSA key exchange ciphersuites.  In cases where 
> the ciphersuite is limited to DHE key exchange, would you agree one 
> key for both uses is acceptable?
>
According to my understanding, yes it is acceptable. I think the 
security certificate validation logic (implemented in TLS software 
engines) allows it anyway. This is a very basic question about TLS 
handshake: if a certificate allows a typical TLS handshake, is it also 
possible to use the same key/certificate for signing application data?

But asking a simple question to experts is often tricky.
> -- Tim
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Sep 2009 08:25:12 -0700

At 10:03 AM -0500 9/24/09, Timothy J. Miller wrote:
>SSL/TLS using DHE key agreement would only be used the key pair for digital signature.  Key encipherment or key agreement would only be needed for the DH and RSA key exchange ciphersuites.  In cases where the ciphersuite is limited to DHE key exchange, would you agree one key for both uses is acceptable?

Why are you asking me? :-) I can see arguments on both sides. A strong argument against your proposal is that you would somehow need to guarantee that the public key would only be used with DHE, and that might be beyond the scope of what you can be sure of.

Your original question asked for official guidance. NIST's guidance is that every organization should have a key-handling policy. This probably means handling all keys, not just one. If you already have a policy on how to handle multiple keys, why skimp and try to roll two key uses together? It's not like strong keys are hard to manufacture.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Sep 2009 08:40:08 -0700

Off-list, someone pointed me to a document with which I have been working but forgot: NIST SP 800-57 part 1. Section 5.2 gives the logic of key separation.

---

From: "Timothy J. Miller" <[email-masked]>
Date: Thu, 24 Sep 2009 11:00:38 -0500

Paul Hoffman wrote:

> Why are you asking me? :-) 

Because you answered first.  :)

> Your original question asked for official guidance. NIST's guidance is that every organization should have a key-handling policy. This probably means handling all keys, not just one. If you already…

And we have one, but it's not server-oriented to say the least.

While keys are cheap, software--particularly server-side 
software--that's savvy about multiple keys can be ... problematic.

Is mostly an intellectual exercise on my part, anyway.  In the end, 
practical requirements will win no matter what policy says.  Mission 
first is the mantra.

-- Tim

---

From: Sean Turner <[email-masked]>
Date: Thu, 24 Sep 2009 12:04:32 -0400

Tim,

NIST SP800-57 Part 1 provides some guidance in Sec 5.2:

"In general, a single key should be used for only one purpose (e.g., 
encryption, authentication, key wrapping, random number generation, or 
digital signatures). There are several reasons for this ..."

It also provides an out for using a key establishment/transport keys 
once to request a certificate.

spt

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 24 Sep 2009 12:32:26 -0400

Timothy J. Miller wrote:
>> Your original question asked for official guidance. NIST's guidance 
>> is that every organization should have a key-handling policy. This 
>> probably means handling all keys, not just one. If you already have a 
>> policy on how to handle multiple keys, why ski
> mp and try to roll two key uses together? It's not like strong keys 
> are hard to manufacture.
>
Follow up on my 0.02 cents advice.

Maybe the mission first mantra and the intellectual exercise match in 
the present case.

In PK crypto, key separation is foremostly (mainly, only?) motivated by 
preventing "chosen ciphertext attacks", and thus a 
signature-primitive-only key pair is OK.

In your mission, you sign something within a TLS session establishment 
and sign some application data. It's signature only, then the 
granularity of separation seems OK.

I guess the certificate details merely implement this key separation 
("intellectual") principle. Did PKIX achieved anything useful if it 
didn't get this right?

Who does need NIST for this?