Subject: CONSENSUS CALL - No encryptionCert in PKINIT

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 12 Nov 2004 11:53:14 -0500

This is ticket #666.

We previously removed the encryptionCert field, because no one could figure 
out what is was for.  Love determined that the point was to support 
signing-only certificates by allowing a separate cert for encryption, and 
reopened the issue.

We discussed this at this week's meeting in Washington.  The conclusion 
reached by the room was that the field was not needed, and that DH was a 
sufficient mechanism for supporting signing-only certificates.

We now need to validate this decision on the list.
For that purpose, I will accept comments on this issue until next Friday, 
19-Nov-2004, at which point I will hopefully be able to declare a consensus.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2004 22:10:07 +0100 (MET)

What exactly where you asking for?

I don't know what it means protocol-wise, but support for peers
with two seperate RSA-certs, one for authentication (but sign-only)
and one for encryption (not valid/usable for authentication)
is certainly a useful feature, and it ought to be possible when one
is doing X.509-based PKI stuff.

The motivation between seperate signing and encryption keys was,
that if the purpose of the keys (key-pairs) was strictly seperate,
then the only purpose of law-enforcement requesting access to the
private sign key would be to forge signatures, which no judge in
a democratic state would agree to (I don't know whether this
still applies to the US).

So the need is primarily for the seperation of key-pairs for end-users,
not so much about key-pairs of servers.  I.e. when using SSL, the
session key is never encrypted with the SSL client cert, but only
with the SSL server cert.

Ultimately the use of PFS-schemes (Perfect Forward Secrecy) would
turn the cert into an authentication-only key-pair, at least for
the protocols that use PFS.

Reason that two seperate RSA-certs may be used instead of
a PFS-scheme based on DH may be (a) better performance, and (b)
availability of RSA-smartcards or an installed base of it.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Nov 2004 16:41:48 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> What exactly where you asking for?  I don't know what it
    Martin> means protocol-wise, but support for peers with two
    Martin> seperate RSA-certs, one for authentication (but sign-only)
    Martin> and one for encryption (not valid/usable for
    Martin> authentication) is certainly a useful feature, and it
    Martin> ought to be possible when one is doing X.509-based PKI
    Martin> stuff.

I think the working group agrees we need to support pkinit with
signing only certs.  We'd prefer to do that through the DH options in
the protocol rather than the complexity of a separate encryption cert.

All the implementers at the DC meeting were OK with this approach.

--Sam

---

From: Love <[email-masked]>
Date: Wed, 17 Nov 2004 05:58:26 +0100

> All the implementers at the DC meeting were OK with this approach.

So the motivation of having an encryption cert is that it might be bad so
use rsa key for both signing and encryption.

That said, it seems easier to make the DH mode a MUST and just ignore the
issue.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Nov 2004 18:25:32 -0500

On Friday, November 12, 2004 11:53:14 -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

> This is ticket #666.
>
> We previously removed the encryptionCert field, because no one could
> figure out what is was for.  Love determined that the point was to
> support signing-only certificates by allowing a separate cert for
> encryption, and reopened the issue.
>

This issue was discussed extensively at the meeting in Washington, and many 
of the most active participants were present during that discussion.  Both 
the key points of that discussion and the subsequent poll were reported in 
the minutes of that meeting.  In addition, the mailing list received two 
comments on this issue - one supporting the decision, and one providing 
additional information on the use of separate signing and encryption keys. 
In such a situation, I believe that the resulting decision can be validated 
without having the discussion over again here, provided that, as in this 
case, there have been no objections.

Therefore, I am declaring that it is the consensus of the WG that the 
existing DH exchange is a sufficient mechanism for supporting signing-only 
certificates, and therefore the encryptionCert field is not needed.  No 
further changes are needed to PKINIT to address this issue, and I am 
closing the corresponding ticket.

-- Jeff