Subject: RE: I-D ACTION:draft-ietf-cat-kerberos-pk-init-20.txt

From: "Eric Rosenfeld" <[email-masked]>
Date: Thu, 22 Jul 2004 08:39:45 -0600

I'd like to thank Brian for getting pkinit-20 ready for the WG meeting
in August. In anticipation of the meeting, I'd like to confirm that,
subject to review of the latest draft, everyone believes that all issues
have been addressed except for caching of DH keys. Please respond to
this email if you believe there are other open issues.

Sam is working on some text for caching DH keys, and believes he can
send something to the WG by Monday, July 23rd.

Thanks,
Eric

Eric S. Rosenfeld
Project Director, PacketCable Security
CableLabs
858 Coal Creek Circle
Louisville, CO  80027-9750
Phone: 303-661-9100
Fax: 303-661-9199
Web: www.cablelabs.com
Email: [email-masked]
Direct Phone: 303-661-3841
Direct Fax: 303-664-8195

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 20, 2004 2:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-init-20.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Kerberos WG Working Group of the IETF.

	Title		: Public Key Cryptography for Initial
Authentication in Kerberos
	Author(s)	: B. Tung, et al.
	Filename	: draft-ietf-cat-kerberos-pk-init-20.txt
	Pages		: 0
	Date		: 2004-7-20
	
This draft describes protocol extensions (hereafter called PKINIT)
to the Kerberos protocol specification (RFC 1510bis [1]).  These
extensions provide a method for integrating public key cryptography
into the initial authentication exchange, by passing cryptographic
certificates and associated authenticators in preauthentication data
fields.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-20.t
xt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of
the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-cat-kerberos-pk-init-20.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-20.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 22 Jul 2004 11:05:02 -0400

> this email if you believe there are other open issues.

I'm still working through my issues list; _I_ don't yet believe all of the 
issues have been resolved.  When I believe the document is ready for last 
call, I'll start one.  In the meantime, if folks have other issues with 
PKINIT, feel free to bring them up on the list.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Co-chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

---

From: Love <[email-masked]>
Date: Thu, 22 Jul 2004 19:01:01 +0200

> this email if you believe there are other open issues.

* CMS structures should be put inside OCTET STRING

PK-INIT cant put restrictions on CMS encodings.

references:
<[email-masked]>
<[email-masked]>
<[email-masked]>

* Encryption certificate is removed

"3.2.  PKINIT Preauthentication Syntax and Use"

Still contains references to this, the list of certificates are in the CMS
part of the message, and thus unsigned.

There is that issue that it might be unwise to use the same rsa-key to
encrypt data that was used to sign data.

    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.

I still need to go over my issue list and see if everything is ok now.

Love

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jul 2004 13:40:16 -0400

>>>>> "Eric" == Eric Rosenfeld <[email-masked]> writes:

    Eric> I'd like to thank Brian for getting pkinit-20 ready for the
    Eric> WG meeting in August. In anticipation of the meeting, I'd
    Eric> like to confirm that, subject to review of the latest draft,
    Eric> everyone believes that all issues have been addressed except
    Eric> for caching of DH keys. Please respond to this email if you
    Eric> believe there are other open issues.
1) This draft does not include OCSP text.  IT looked like Larry's OCSP
   proposal has received somewhat more review than Nico's OCSP
   proposal.  If the working group decides Larry's proposal is what we
   want then we need to integrate this text.

2) The ad-initial-verified-cas text has not been updated even though
    we had a fairly strong consensus that it was under specified
    currently.  Nico was going to supply text for this.

---

From: Love <[email-masked]>
Date: Thu, 29 Jul 2004 17:45:48 +0200

> <[email-masked]>

I need to stress on this again now that I've yestoday found CMS software
that unconditionally will generate BER for some parts of SignedData, there
is no way to make not do it.

Also I dislike the use of ContentInfo for almost all
SignedData/EnvelopedData, just store the SignedData/EnvelopedData directly
in a IMPLICIT OCTET STRING like in Larrys proposal.

Love