Subject: RE: Love's issue #4; was: Re: PKINIT open issues

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 28 May 2004 16:17:40 -0700

Sam Hartman wrote:
> It seems not very helpful to keep around if no one uses it and if we
believe it is a security hole if used.

I do not know the original design and how this certificate is secured,
but let me ask around and get back here. 

Thanks,

Larry
-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Friday, May 28, 2004 4:01 PM
To: Liqiang(Larry) Zhu
Cc: D. R. Evans; [email-masked]
Subject: Re: Love's issue #4; was: Re: PKINIT open issues

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu
<[email-masked]> writes:

    Liqiang(Larry)> Microsoft does not use this field in the existing
    Liqiang(Larry)> releases, but would it be helpful to keep it
    Liqiang(Larry)> around?

Then how do you know what cert to use to encrypt the key to?

It seems not very helpful to keep around if no one uses it and if we
believe it is a security hole if used.

---

From: Doug Mitchell <[email-masked]>
Date: Fri, 28 May 2004 17:14:16 -0700

It used to be standard practice to have separate certs and keys for 
signing and for encrypting on the theory that one wants to minimize the 
exposure when a given key is compromised. This is almost never done in 
practice nowadays.

Then there is the fact that in the olden days, US export restrictions 
allowed for different legal sizes for keys generated by exportable code 
depending on whether the keys could sign or encrypt. You could export 
(outside the US) code which could generate larger keys for signing then 
for encrypting. The fact that RSA signing and encrypting (with the 
private key) are in fact the exact same operation was apparently lost 
on the US State Department so this inane rule stood as law for years. 
It's why SSL has a protocol option in which the server can specify a 
different encryption cert than the one it uses to sign.

Both of these artifacts probably contributed to the separate encryption 
cert option. I'm not sure I even want to venture forth an opinion as to 
the merit of keeping it around for PKINIT.... However I don't see it as 
any kind of security hole. If the client wants to provide a separate 
encryption cert, I don't see any reason not to honor that request.

--dpm

---

From: Love <[email-masked]>
Date: Sat, 29 May 2004 14:05:20 +0200

Doug Mitchell <[email-masked]> writes:

> If the client wants to
> provide a separate encryption cert, I don't see any reason not to
> honor that request.

The encryptionCert is outside any interity checked area, that is why I
can't se why anyone case use it w/o a MITM problem. It would be worked
around in configurationon what signer certifities maps to what
encryptionCert.

Moving the encryptionCert to inside AuthPack is acceptable, and now that we
knows that noone is using encryptionCert in any implementations, I propose
we do that.

Love

---

From: Sam Hartman <[email-masked]>
Date: Sat, 29 May 2004 16:13:14 -0400

>>>>> "Love" == Love  <[email-masked]> writes:

    Love> Moving the encryptionCert to inside AuthPack is acceptable,
    Love> and now that we knows that noone is using encryptionCert in
    Love> any implementations, I propose we do that.

I propose we drop it and add the option alter if needed.  I do not
object to Love's proposal but prefer mine because it removes
complexity.

Does the document currently say that you use the signing cert for
encryption anywhere?  Are you actually even required to include a copy
of the signing cert?

---

From: Doug Mitchell <[email-masked]>
Date: Sat, 29 May 2004 15:21:31 -0700

On May 29, 2004, at 1:13 PM, Sam Hartman wrote:

> encryption anywhere?

As was shown in this list recently, IETF draft 19 doesn't really say - 
at all - HOW public key encryption is done. Love's proposed addenda 
clarifies and says you encrypt with one or the other (signing, or 
encryption cert).

>  Are you actually even required to include a copy of the signing cert?

Yes. From 3.2.1:

     The ContentInfo in the signedAuthPack is filled out as follows:

     ...snip...

     4.  The certificates field MUST contain at least a signature
         verification certificate chain that the KDC can use to
         verify the signature over the AuthPack.  Additionally, the
         client MAY insert an encryption certificate chain, if
         (for example) the client is not using ephemeral-ephemeral
         Diffie-Hellman.

Note that the field for the encryption cert in PA-PK-AS-REQ - proposed 
to be moved inside signedAuthPack - is not the whole cert, it's just 
issuer&serial number. The cert itself is inside the SignedData's 
CertificateSet...

--dpm

---

From: Love <[email-masked]>
Date: Sun, 30 May 2004 11:45:52 +0200

> issuer&serial number. The cert itself is inside the SignedData's

But that should be enough, the KDC can verify that certificate chain. But
that wouldn't allow using self-signed certificates.

I don't really understand why all fields of PA-PK-AS-REQ isn't inside
AuthPack.

Love

PS, I would like to see a new draft being published since I have no idea
what changes have been completed and what is outstanding.

---

From: Doug Mitchell <[email-masked]>
Date: Sun, 30 May 2004 09:02:49 -0700

On May 30, 2004, at 2:45 AM, Love wrote:

> But that should be enough, the KDC can verify that certificate chain.

I agree.

>  But
Sure it would, at least insofar as the KDC can verify a self-signed 
signing cert. You can put any cert(s) you want into a SignedData's 
CertificateSet. Even a self-signed cert can be identified by 
issuer&serial. (Though there is much less certainty that issuer&serial 
*uniquely* identify a self-signed cert.) Allowing the use of a 
self-signed cert is an implementation-dependent policy decision.

> I don't really understand why all fields of PA-PK-AS-REQ isn't inside
I agree, though I can't immediately see how unsigned kdcCert and 
trustedCertifiers fields can be abused by an attacker.

Love
> what changes have been completed and what is outstanding.

I agree. A newbie question: who has the authority to author such a 
draft?

--dpm

---

From: Jeffrey Altman <[email-masked]>
Date: Sun, 30 May 2004 12:09:48 -0400

Doug Mitchell wrote:

> I agree. A newbie question: who has the authority to author such a draft?
>
> --dpm
>
In the case of an individual submission to the IETF, the editor of the 
document
is the person who submitted it.  In the case, of working group 
submissions the
editor(s) of the documents serve at the discretion of the working group 
chair(s).
In most cases, working groups respect the original authors of the 
document and
they are selected as the editors.

Jeffrey Altman

---

From: Doug Mitchell <[email-masked]>
Date: Sun, 30 May 2004 09:29:11 -0700

> self-signed cert is an implementation-dependent policy decision.
Scratch that. If a MITM detected a request by the client to use a 
self-signed cert - the issuer&serial of which is signed but the cert 
itself is not - he can easily cook up his own (apparently matching) 
encryption cert and insert it into the SignedData.

Seems like, if we support encryptionCert at all, it needs to be the 
whole cert, not just the issuer&serial, and the whole cert needs to be 
inside of the signed AuthPack. Like so:

     AuthPack ::= SEQUENCE {
         pkAuthenticator         [0] PKAuthenticator,
         clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
                                     -- Defined in RFC 3280 [4].
                                     -- Present only if the client
                                     -- is using ephemeral-ephemeral
                                     -- Diffie-Hellman.
         encryptionCert          [2] Certificate OPTIONAL,
                                     -- Defined in RFC 3280
                                     -- Present only if the client is NOT
                                     --    using ephemeral-ephemeral
                                     --    Diffie-Hellman and has 
different
                                     --    signing and encryption certs.
                                     -- specifies recipient of 
EnvelopedData
                                     --    for PA-PK-AS-REP
         ...
     }

Along with this we'd scratch the comment later on in 3.2.1: 
"Additionally, the client MAY insert an encryption certificate chain, 
if (for example) the client is not using ephemeral-ephemeral 
Diffie-Hellman.). I.e. if the encryptionCert is fully specified in the 
AuthPack then there is no reason to also put it in the SignedData.

--dpm