Subject: RE: Feedback from PKINIT Review...

From: "Eric Rosenfeld" <[email-masked]>
Date: Wed, 14 Apr 2004 12:47:40 -0600

OK, now that Brian has posted PKINIT-19, I'd like to review the basic
open issues that were included in the email that I sent a couple of
weeks ago.
 
1) OCSP - We'd like to see OCSP removed from the draft and placed into a
separate draft. It is being added to PKINIT too late in the process, and
doesn't address all the ways in which OCSP could be used to verify
certificates.
 
2) ASN.1 module - Brian has accepted all of our changes to the ASN.1
objects (there are a couple of small errors that I will document below).
I would like to see a standalone ASN.1 module in an Appendix. This will
remove all the imports from the body of the document, and will more
easily allow for ASN.1 syntax checking.
 
3) Make the AD-INITIAL-VERIFIED-CAS optional.
 
4) Address Microsoft's "blank" cname issue. Larry has proposed the
addition of a new name type "NT-ENTERPRISE-X500-PRINCIPAL" to force name
canonicalization.

Also, here are some edits that were missed in Brian's PKINIT-19 post:
 
Section 3 "Extensions" - Step #2 has two number twos.
 
Section 3 "Extensions" - Step 3.a. - Change "KDC?s" to "KDC's" and
change "client?s" to "client's"
 
Section 3.2.2 "Validation of Client Request" - Paragraph just above the
definition of the PKINIT EKU OID - Changed "Enxtended" to "Extended"
 
Section 3.2.2 "Validation of Client Request" - 2nd paragraph just below
the definition of PKINIT EKU OID - Change "recommendations" to
"recommended". Change "MUSTreturn" to "MUST return"
 
Section 3.2.3 "KDC Reply" - In the ASN.1 definition of
InitialVerifiedCAs - Change "Validated" to "validated"
 
Section 3.2.3 "KDC Reply" - In the ASN.1 definition of PA-PK-AS-REP -
Change "-- Type is SignedData." to "-- Type is EnvelopedData.". Change
"-- Content is ReplyKeyPack" to "-- Content is SignedData (over
ReplyKeyPack)".
 
Thanks,
Eric

Eric S. Rosenfeld 
Project Director, PacketCable Security 
CableLabs 
858 Coal Creek Circle 
Louisville, CO  80027-9750 

Email: [email-masked] 
Phone: 303-661-3841 
Fax: 303-661-9199 

	-----Original Message-----
	From: Eric Rosenfeld 
	Sent: Tuesday, March 30, 2004 4:35 PM
	To: [email-masked]
	Subject: Feedback from PKINIT Review...

	Sasha Medvinsky, Doc Evans, and myself began a detailed review
of PKINIT draft 19 in anticipation of a last-call once the draft is
posted. This was agreed to during the Kerberos Jabber session of the
IETF meeting in Seoul. Given that a lot of the text in this draft has
not been seen on the reflector, this is the first time that a great deal
of this document has been reviewed by folks other than the authors. So
far we have lots of grammatical changes, editorial changes, and
reference updates. Unfortunately, we have also encountered a bunch of
technical issues that I wanted to bring to the group's attention.

	1) OCSP - The latest draft defines a tunneling mechanism for
OCSP. OCSP could be used in different ways, so the use of OCSP really
should be separate from OCSP, especially a tunneling mechanism as
defined in the draft. We are concerned that brand new functionality is
being added to a draft that we are trying to move to last call. OCSP
support was not agreed upon at the interim meeting (it was only decided
that Microsoft would provide OCSP feedback), and certainly a tunneling
mechanism was not discussed. It seems like the right way to approach
this issue would be to remove OCSP from PKINIT, and turn it into a
separate draft.

	2) ASN.1 - We found several problems with the ASN.1. We think it
would be a good idea to have a complete ASN.1 module in an Appendix. The
problems that we found so far:

	        - The latest draft imported the wrong ASN.1 module for
PKIX. It imported PKIX1Explicit93, but RFC3280 (and RFC2459 before it)
use PKIX1Explicit88.

	        - Incorrect Import statements, and multiple Imports for
the same module. A single module in an appendix would allow for a single
import for each module.

	        - Definition of subjectAltName was incorrect. It used
OTHER-NAME, which was in RFC2459, but defined differently in RFC3280
because of incompatibilities between 93 syntax and 88 syntax. We had to
perform major surgery here.

	3) There is no need to make the AD-INITIAL-VERIFIED-CAS data
type (and the InitialVerifiedCAs ASN.1 object) a MUST. This was an issue
that I objected to at the interim meeting, but shelved my objections in
order to make progress at the meeting. The proposed text has confirmed
my original concern. I would really like to see this data type be made
optional.

	4) Still need to define the "blank" cname that Microsoft
requested. It is currently defined as [special "blank" 
	name], and this needs to be resolved before the draft can be
posted. 

	We should be finished with our review tomorrow, and will hand
the results back to Brian Tung then. We will have additional comments
that need to be addressed. However, given the importance of the issues
raised above, it would be good if we could get some discussion and
resolution before posting draft 19.

	Thanks, 
	Eric 

	Eric S. Rosenfeld 
	Project Director, PacketCable Security 
	CableLabs 
	858 Coal Creek Circle 
	Louisville, CO  80027-9750 

	Email: [email-masked] 
	Phone: 303-661-3841 
	Fax: 303-661-9199

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Apr 2004 13:55:07 -0400

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

    Eric> 3) Make the AD-INITIAL-VERIFIED-CAS optional.

I continue to object to this.
 
    Eric> 4) Address Microsoft's "blank" cname issue. Larry has
    Eric> proposed the addition of a new name type
    Eric> "NT-ENTERPRISE-X500-PRINCIPAL" to force name
    Eric> canonicalization.

I continue to believe that removing this entirely and addressing in
referals is correct.  Larry proposed text that would allow for this.
He also proposed discussing the specific name and name type in pkinit;
I believe that is unnecessary.

In practice I wonder whether just sending a empty string as a single
component, or sending a name with no components is appropriate for
pkinit clients who don't know the mapping and are using the referals
draft.