Subject: PKINIT -33 comments/proposal

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 7 Feb 2006 00:26:39 -0800

What happens if the KDC does not support public key encryption and the
client does not wish to use the Diffie-Hellman key agreement method (aka
clientPublicValue is not present in the request), the KDC does not seem
to have a way to let the client to recover from this.

I propose to add a new error code:

KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81

Then before the last paragraph in section 3.2.3 page 20, add the
following:

   If the client does not wish to use the Diffie-Hellman key delivery
   method (the clientPublicValue is not present in the request) and the
   KDC does not support the public key encryption key delivery method,
   the KDC MUST return an error message with the code
   KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED.  There is no
accompanying
   e-data for this error message.

Thanks,

-- Larry

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 07 Feb 2006 04:04:06 -0500

Sounds reasonable.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Feb 2006 10:55:54 -0500

Sounds reasonable to me as an individual.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Feb 2006 11:57:15 -0600

> KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED 81

In a pinch (e.g., if this had been discovered after the RFC issued) and
in this case you could reuse KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED
since the client did not use DH key agreement there's no way to
interpret DH-related errors as anything other than a generic error
related to public key transport.

Anyways, I approve.