Subject: Feedback from PKINIT Review...

From: "Eric Rosenfeld" <[email-masked]>
Date: Tue, 30 Mar 2004 16:34:44 -0700

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: Jeffrey Altman <[email-masked]>
Date: Tue, 30 Mar 2004 18:44:08 -0500

Eric Rosenfeld wrote:

> 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
>
There is no requirement that draft-19 be the last call draft. 
Brian, please submit the draft for publication so that it can be 
discussed by the list.

Jeffrey Altman

---

From: Brian Tung <[email-masked]>
Date: Tue, 30 Mar 2004 18:57:10 -0800

> perform major surgery here.

The problem is that PKIX1Explicit88 (and OTHER-NAME within it) does not
use the object information model, which (I seem to recall from our
hallway meeting in Minn) we wanted to use in lieu of AnotherName, which
uses EXPLICIT ANY DEFINED BY type-id, which I thought we did not want to
use.  Did I misremember?  (It wouldn't be the first time.)

> above, it would be good if we could get some discussion and resolution

Jeff, I agree that we should post it as soon as I look at it.

Brian Tung <[email-masked]>

---

From: Love <[email-masked]>
Date: Wed, 31 Mar 2004 07:01:23 +0200

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

>         - 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.

-18 uses AnotherName, what is the problem ?

>         - 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.

Talking about the subjectAltName and OtherName, that is the syntax and
semantics when it it is uesd in Name Constraints ? And how does that apply
to the use of OtherName in subjectAltName for pk-init ?

Love