Subject: RE: DH groups for PKINIT

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 31 Jan 2005 09:27:32 -0800

I support the inclusion of ECParameters. The changes are: 

1) Insert id-ecPublicKey into section 3.1.3

2) Then TD-DH-PARAMETERS is defined as follows:

       TD-DH-PARAMETERS ::= SEQUENCE OF TD-DH-PARAMETERS-ENTRY
                   -- Contains a list of Diffie-Hellman group
                   -- parameters in decreasing preference order.

       TD-DH-PARAMETERS-ENTRY ::= CHOICE {
           modp                   [0] DomainParameters,
                   -- Type DomainParameters is defined in [RFC3279].
           ec                     [1] EcpkParameters,
                   -- Type EcpkParameters is defined in [RFC3279].
           ...
       }

The benefit of using a well known DH group ID is probably to reduce the
message size, but I do not think this reason alone is compelling enough
to make such an change at such a late stage.

Thanks,

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Monday, January 31, 2005 8:41 AM
To: Jeffrey Hutzelman
Cc: [email-masked]
Subject: Re: DH groups for PKINIT

On Fri, Jan 28, 2005 at 08:13:41PM -0500, Jeffrey Hutzelman wrote:
> This is ticket #530.
> 
> In San Diego we agreed to say "MUST group 2, SHOULD group 14".
> Larry argues that we need to also say "SHOULD group 16".
> He also proposes adding "MAY group 4" (this is an EC2N group).
> 
> Are there any objections to these proposals?

I don't think we need "MAY use group X" -- just don't forbid the use of
any groups not listed.

> Does anyone want to speak up in support of them?
> 
> 
> The error code KDC_ERR_KEY_SIZE is used for negotiating DH groups; it 
> is returned when the parameters proposed by the client do not meed the

> KDC's requirements.  The e-data for this error is a TYPED-DATA with 
> type TD-DH-PARAMETERS, containing a proposal from the KDC.
> 
> Larry proposes to change the data for TD-DH-PARAMETERS from a single 
> DomainParameters object to a SEQUENCE OF DomainParameters, allowing 
> the KDC to propose multiple groups in order of preference.
> 
> Are there any objections to this proposal?
> Does anyone want to speak up in support of it?

Fine with me, er, except, if we're to allow for the use of ECDH then
instead of DomainParameters we need a CHOICE of DomainParameters and
ECParameters.  For simplicity, if we're to have a CHOICE at all, why not
also have an group number integer -- shorthand for the group's actual
parameters?

So:

   IMPORTS DomainParameters, ECParameters
      FROM PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
	 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	 id-mod-pkix1-algorithms(17) }

   ...

   TD-DH-PARAMETERS ::= CHOICE {
      dh-params		DomainParameters,
      ecdh-params	[1] ECParameters,
      group		[2] INTEGER (0..65536),
      ...
   }

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 31 Jan 2005 11:40:59 -0600

> to make such an change at such a late stage.

Not only message size, but implementation complexity, if the use of
numbers is required for known groups -- an integer is easier to encode/
decode that are DomainParameters or ECParameters, and is easier to match
against.  Yes, yes, it's no big deal -- but's not just message size.

Nico
--