Subject: Re: LAST CALL - ECC Support for PKINIT

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 12 Jan 2006 17:09:53 -0500

On Sunday, December 25, 2005 11:24:19 AM -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

> The Kerberos working group is beginning a Last Call on the following
> document:
>
> Title:  ECC Support for PKINIT
> File:   <draft-zhu-pkinit-ecc-00.txt>
>
>    This document describes the use of Elliptic Curve certificates,
>    Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
>    (ECDH) key agreement within the framework of PKINIT - the Kerberos
>    Version 5 extension that provides for the use of public key
>    cryptography.
>
>
> Due to the various winter holidays, I am extending the last call period
> to a total of three weeks.  Please send comments to the Kerberos working
> group mailing list, <[email-masked]>, by 2006-01-16.

This last call expires on Monday, and I have so far seen no comments at 
all.  Has anyone even reviewed this document?

I will have a hard time saying this reflects the consensus of the working 
group if no one speaks up...

-- Jeff

---

From: Chaskiel Grundman <[email-masked]>
Date: Fri, 13 Jan 2006 02:15:33 -0500 (EST)

> 3.  Using Elliptic Curve Certificates and Elliptic Curve Signature
>    Schemes

Is this section really needed? does PKINIT actually limit what signature 
algorithms can be used for the SignedData's?

>   If ECDH is negotiated as the key delivery method, both the KDC and
>   the client calculate the shared secret value and derive the reply key
>   as follows:
>
>   1) Let DHSharedSecret be the x-coordinate of the shared secret value
>      (an elliptic curve point).  DHSharedSecret is the output of
>      operation ECSVDP-DH as described in Section 7.2.1 of [IEEE1363].
>
>   2) DHSharedSecret is first padded with leading zeros such that the
>      size of DHSharedSecret in octets is the same as that of the
>      modulus, then represented as a string of octets in big-endian
>      order.
>
>   3) The DHSharedSecret value derived above is used as input to the
>      octetstring2key() function to derive the AS reply key k, as
>      described in Section 3.2.3.1 of [PKINIT].

This text seems really clunky. I can see that it's modeled after text in 
PKINIT, which is also clunky. Since an implementor of ECDH obviously needs 
to use most of Section 3.2.3.1 of PKINIT, can't we rely on it more, and 
say something simpler, like this?

--- cut ---
If ECDH is negotiated as the key delivery method, then the PA-PK-AS-REP 
and AS reply key are generated as in Section 3.2.3.1 of [PKINIT] with the 
following difference:

The DHSharedSecret is the x-coordinate of the shared secret value (an 
elliptic curve point).  DHSharedSecret is the output of operation 
ECSVDP-DH as described in Section 7.2.1 of [IEEE1363].
--- cut ---