Subject: [Fwd: Re: Kerberos Working Group Last Call - PKINIT]

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 09 Feb 2001 11:03:51 -0600

As we discussed yesterday while at the ISOC NDSS, Matt, you where
 going to get some comments to the list on Ken's comments on PKINIT. 

I have added some comments of my own below. 

-------- Original Message --------
Subject: Re: Kerberos Working Group Last Call - PKINIT
Date: 31 Jan 2001 16:32:41 -0500
From: Ken Raeburn <[email-masked]>
To: [email-masked]
References: <[email-masked]>

Just a few comments so far.  For reasons (2), (3), and (5) especially,
I don't think this should be the final version of PKINIT.

1) I'd like to see a few more examples of name handling (principal
   names, realm names, transited-realm encoding).  I think I
   kind of understand what's being described, but not being an expert
   on some of the PKI, confirmation wouldn't hurt.

[DEE Don't think this is a problem we can live without more examples.]

2) Some of us are working on revising section 6 of RFC1510bis to be a
   bit more structured, to define a "profile" for a cryptosystem
   definition and rewrite the existing ones to fit that profile.
   IMNSHO, it would be a big win if PKINIT used this framework.

   For example, rather than "truncate to n bits and maybe fix parity",
   wouldn't "use the encryption algorithm's key generation function X"
   make it cleaner to extend to new cryptosystems where a random
   string of bits might not be a valid key (whether because of weak
   key checks, or use of prime numbers, or whatever)?  If PKINIT can't
   fit into the framework we set up for cryptosystems, perhaps other
   preauth schemes will have problems too; in that case, we need to
   adjust the framework.

   Yes, I know it's hard to write to a spec that hasn't been seen yet.
   I'm the editor for these changes, and hope to have something out
   for comments by the end of this week or early next week.

[DEE This should not stop the working group last call on this. In the long run,
may want to go back to the PKINIT to have it use the framework, but this
should not stop the current version.]    

3) As I understood it, PKINIT is supposedly dependent on 1510bis.  If
   that's the case, the references to RFC 1510 should be changed to
   whatever 1510bis will be.

[DEE I listed that as the one change to be made in the call. So this is not
a problem, and will be fixed.]

4) At line 624, "mapping mapping" is probably supposed to be just
   "mapping".

[DEE Minor editing error, This can be fixed, when we update the reference.] 

5) Around line 643, the handling of email addresses mentions the
   possibility of doing name canonicalization.  Does this mean that
   (if the KDC chooses to handle the S/MIME case through
   canonicalization) the email address should be treated as any other
   SMTP-type principal name for which canonicalization is requested?
   If it's not canonicalizing as the KDC would for a client specifying
   the same name and type (which type PKINIT should specify), then the
   spec shouldn't use "canonicalization" but should instead talk about
   some sort of database lookup that doesn't need to be tied to name
   canonicalization.

[DEE Authors need to comment.] 

6) Section 3.1: It might be worth noting that PrincipalName in
   Kerberos will be using UTF-8 strings (are we going with the
   "KerberosString" type?) even though the ASN.1 language says
   GeneralString, so converting to a CertPrincipalName will require no
   translation of the strings.

   I don't know about the constraints on ASN.1 use in the PK specs or
   implementations, but if it isn't strict, maybe the Kerberos types
   could just be used directly, letting an implementation simply copy
   objects rather than re-encoding them.  A strict implementation
   already won't work for Kerberos, though of course using two
   separate implementations, one for PK and one for Kerberos, might
   yield a situation where Kerberos is implemented with lax ASN.1
   conformance and the PK bits are strict.

[DEE Authors need to comment. But I don't think this is a problem.]  

I'll try to get some time to read it more carefully, but I'm really
trying to get 1510bis section 6 taken care of right now...

[DEE Yes, Ken, keep after the section 6, as thisis critical to the
revisions, which is out top priority.]

---

From: Ken Raeburn <[email-masked]>
Date: 09 Feb 2001 12:42:06 -0500

"Douglas E. Engert" <[email-masked]> writes:

>    IMNSHO, it would be a big win if PKINIT used this framework. [...]

Not if we've already standardized and deployed something else.  I'll
get a draft of section 6 with some annotations out to the PKINIT
authors; I don't want to send it off to all the WG just yet, until
I've run it by the rest of the "cabal" that came up with this
framework idea.

> a problem, and will be fixed.]

Yes, sorry, I overlooked that.