Subject: PKINIT open issues

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 19 Apr 2004 17:34:37 -0400

These are the open issues I currently have for PKINIT.  This document was 
to go to the IESG last month, and it's still not done.  I'd like to see 
these issues resolved in the next few days (perhaps some already have been):

-- specify subjectAltName for user cert [tlyu, jaltman, editor]
   Can someone please tell me what this means, and if it is done?

-- Update PA types [Cliff Neuman + editor; last]
   Brian and Cliff should get together and make sure new types are
   assigned and appear in the -20 version of the document.  I would
   like to be able to last-call -20 when it appears...

-- ASN.1 errata - wrong module import for PKIX
-- ASN.1 errata - incorrect/multiple import statements
-- ASN.1 errata - subjectAltName definition
   Have these been fixed?

-- ASN.1 module appendix
   This is probably a good idea.  I'd like to see an ASN.1 module
   appendix in the next version of the draft.  Brian, can you do this,
   or do you need help?

-- OCSP tunneling:
   Eric objects to including this in PKINIT, and suggested moving it to a
   separate draft.  It appears that Sam agrees this would be acceptable.
   I've seen no comment from anyone at Microsoft on this issue, nor from
   anyone else.

     Does anyone object to moving this work to a separate draft?
     Does anyone care enough about this to volunteer to edit a draft?

   Depending on the answers to these questions, and on the ensuing
   discussion, we will either drop the OCSP tunneling entirely, move
   it to a separate draft, or keep it in PKINIT.

-- AD-INITIAL-VERIFIED-CAs
   Nico provided text defining this AD type, to address the problem of
   being able to tell whether PKINIT was used to obtain a ticket and,
   if so, what CA's were involved.  This problem was discussed in some
   detail, along with some proposed solutions.

   Sam and Nico both believe that this data must be REQUIRED, since it
   plays a role analogous to that played by the transited-realms field,
   providing information about the entities involved in the authentication
   process which may be used by servers in making authorization decisions.
   Eric objects to making this data REQUIRED.

   I need to see the following:
   - Comments from Eric on why he wants to be able to omit this data.
   - Comments from Eric on why he believes that being able to omit this
     data does not adversely affect the security properties of the
     protocol.
   - Comments from the rest of the WG on any aspect of this issue, and
     especially on whether they support or oppose making this data
     REQUIRED.

-- Open issues on DH key exchanges
   I have seen no traffic on this in several days.  I need a volunteer to
   take responsibility for researching and resolving this issue.

-- Love's comments on PA-PK-AS-REP and similar types.

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

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 20 Apr 2004 08:17:36 -0600

Jeffrey Hutzelman said the following at 04/19/2004 03:34 PM:-

>   separate draft.  It appears that Sam agrees this would be acceptable.

I have the same objection as Eric.

> -- Love's comments on PA-PK-AS-REP and similar types.

I did not understand Love's comments at all. I don't immediately see 
what's wrong with the current text.

   Doc

-- 

-----------------------------------------------------------
Office:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Tue, 20 Apr 2004 13:38:24 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> -- OCSP tunneling: Eric objects to including this in
    Jeffrey> PKINIT, and suggested moving it to a separate draft.  It
    Jeffrey> appears that Sam agrees this would be acceptable.  I've
    Jeffrey> seen no comment from anyone at Microsoft on this issue,
    Jeffrey> nor from anyone else.

I actually simply asked some questions (so far unanswered) to try and
determine what I thought about the issue.

One concern I have is that the problem may be important to solve but
not important enough that people will actually solve it in another
draft.

--Sam

---

From: Love <[email-masked]>
Date: Tue, 20 Apr 2004 21:01:28 +0200

> what's wrong with the current text.

Like its refering the fields that doesn't exists nor tell you what key to
use ?

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 20 Apr 2004 15:17:16 -0400

> determine what I thought about the issue.

OK; I guess I inferred from your questions a position you hadn't actually 
taken.  Sorry.

> not important enough that people will actually solve it in another

Yes, that's a possibility.  The result may be that the only way to get this 
done is to hold up PKINIT for it, and then we have to decide if it's 
important enough for that.  I'm still hoping to see comments from more WG 
members on that question...

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Apr 2004 14:33:42 -0500

> members on that question...

I'm for moving the OCSP tunneling to a separate draft.  It's a new
feature that, unlike the CAs-verified authz-data element, isn't crucial
for security and interoperability, even if it is desirable.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 20 Apr 2004 15:45:13 -0400

>for security and interoperability, even if it is desirable.
I concur.  OCSP should be moved to a new draft.

Jeffrey Altman

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 20 Apr 2004 13:56:51 -0600

Love said the following at 04/20/2004 01:01 PM:-
> Like its refering the fields that doesn't exists nor tell you what key to

Back up here.

1. Here was the text that you quoted:

 >PA-PK-AS-REP ::= CHOICE {
 >>        dhSignedData            [0] ContentInfo,
 >>                                    -- Type is SignedData.
 >>                                    -- Content is KDCDHKeyInfo
 >>                                    -- (defined below).
 >>        encKeyPack              [1] ContentInfo,
 >>                                    -- Type is SignedData.
 >>                                   -- Content is ReplyKeyPack
 >>                                    -- (defined below).

and you said that the comments were confusing. What is confusing about 
them? Is it because we don't go into detail about the ContentInfo type 
or say where it comes from? I guess that we could include a refrence to 
CMS in the comments if that's the problem, although since we do state 
elsewhere where ContentInfo comes from, I don't think that it's really 
necessary.

That was the only part of the draft that you quoted, so I assume 
(wrongly?) that that was the part to which you were objecting.

2. You said: "The text below is descripting the
case that almost made sense before is just now plainly broken."

I cannot parse that in any way that makes sense to me, so I don't 
understand what you are complaining about :-( The text that followed it 
in your e-mail (which, I guess, is the "text below" to which you refer), 
was also unparseable by me. I'm sorry; I expect that it's probably just 
a language problem, but I honestly can't figure out what you are trying 
to say.

I just went back and looked at the current draft text, and I still don't 
see what the problem is. I'm probably being blind.

   Doc

--

---

From: Love <[email-masked]>
Date: Wed, 21 Apr 2004 00:50:00 +0200

lets start over, I'm confusing things.

1) what key should the reply be enveloped with in the encKey case ?
2) what encoding should be used ? CMS allow both DER and BER.
3) what is encryptedContentType ?

these three are are why I'm finding the text confusing

4) what is encryptionCert
5) I ask two times now for TrustedCAs issuerAndSerial should be [2] not [1]
 the second time brian told me that this would change
 see <[email-masked]> to [email-masked]
6) INTEGER use <[email-masked]>

7) 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 ?

   <[email-masked]>

   pkix only define syntax for id-krb5, not sematics. how do I make
   restrictions on OtherName ? ie CA trusted for authentiation but not
   authorization.

Love