Subject: RE: draft-ietf-cat-kerberos-pk-init-09.txt

From: "Linn, John" <[email-masked]>
Date: Wed, 7 Jul 1999 16:25:04 -0400

Sasha,

Thanks for the quick explanatory reply. I'd suggest that it would be useful
to call out distinctions between signature and D-H certificates as they
arise within the document, in preference to references to certificates
without further qualification, and to describe the characteristics of the
usage modes as you've done here.  Some confusion may have arisen from
pre-existing text which covered the RSA case, but which may not be precisely
analogous for to D-H and its subcases. A few points embedded. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 07, 1999 1:10 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: draft-ietf-cat-kerberos-pk-init-09.txt
> 
> 
> John,
> 
> We defined two different D-H modes: Ephermal-Ephermal and 
> Static-Ephermal,
> where the client side is static and requires a DH certificate (chain).
> 
> The mandatory Ephermal-Ephermal D-H mode does not utilize DH 
> certificates.
> In that case, the client's certificate chain is for its signature
> verification key, not the D-H key.  Instead, the client 
> public D-H value is
> included in the data that is signed by the client.

OK; the public value is client-authenticated rather than being certified by
a 3rd party.  A specific suggestion: in the 2nd paragraph of sec. 3.2, drop
or qualify the statement that "It is assumed that all public keys are signed
by some certification authority (CA)." 

> 
> The optional Static-Ephermal D-H mode was added in the last 
> revision, based
> on comments that we received.  In this case, the client will send two
> certificate chains: one for the DH key and one for its RSA signature
> verification key.  

Within the set of required algorithms per 3.2.2, this could be DSA. 

This is where we refer to the client's D-H 
> certificate.
> This D-H certificate replaces the D-H public value inside the 
> AuthPack data
> structure. 
> 
> We did not refer to KDC's D-H certificates, as far as I know. 
>  In the D-H
> modes, KDC always generates an ephermal D-H public value and 
> returns it
> inside SignedData.

The description of "Usage of SignedData" within the KDC reply discusses "the
KDC's certificate", and means to derive trust in it.  Suggest, for
clarification, that this text be qualified to refer to "KDC's signature
certificate". 

> Regards,
> Sasha.

--jl

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]