Subject: RE: PKINIT 20 comments (was RE: PKINIT-19 comments)

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 22 Nov 2004 02:52:37 -0800

Proposed changes in section 3.2.2:

========================================================

        The otherName field (of type AnotherName)
        in the SubjectAltName extension MUST contain one of the
following:

        1) 
        The type-id is:

        krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod
(6)
        internet (1) security (5) kerberosv5 (2) 2 }

        The value is:

        KRB5PrincipalName ::= SEQUENCE {
            realm                   [0] Realm,
            principalName           [1] PrincipalName
        }

      2) the type-id is

        krb5EnterprisePrincipalName OBJECT IDENTIFIER ::= { iso (1) org
(3) dod (6)
        internet (1) private(4) enterprise(1) microsoft(311)
certificates(20) 
        name-types(2) kerberosv5-user-principal-name(3) }

        The value is a RFC 822 style email name, and it contains the
single component of the name type NT-ENTERPRISE [reference to the
referral draft here].

==========================

With these, we shall be able to close the ticket for the client
mappings.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Liqiang(Larry) Zhu
Sent: Monday, September 27, 2004 12:48 AM
To: [email-masked]; Jeffrey Hutzelman
Cc: Sam Hartman
Subject: PKINIT 20 comments (was RE: PKINIT-19 comments)

Larry Zhu Wrote:
> 2) we should define mandatory-to-implement certificate mapping, this 
> is the way toward having interoperable and consistent behavior among 
> different implementations. I can send the initial proposal for
this item.

Jeff kindly reminded me about this thread.

What we have found is that different customers want to do the mapping in
different ways.

Plausible ways include:

1) UPN as defined by the referral draft -- this can not be the
mandatory-to-implement mapping because some of our customers won't add
application specific data into their certificates
 
2) Subject DN -- it is assumed that this is globally unique

3) the public Key or key hash -- this is always present

4) Issuer/serial number -- not preserved across name and key changes

Short of proposing a mandatory-to-implement mapping method, we like to
propose the following changes:

1) it should be noted that UPN is strictly more flexible than
cname+crealm
(any name of the form cname@crealm is acceptable as a UPN)

2) Windows 2000 uses a different SubjectAltName-OtherName OID for UPN,
this SHOULD be specified in the PKINIT draft.  We have large amount of
existing smartcards/certificates with this OtherName OID.

-- Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Liqiang(Larry) Zhu
Sent: Tuesday, April 27, 2004 2:24 AM
To: [email-masked]
Cc: Sam Hartman
Subject: PKINIT-19 comments

1) DH key agreement: initial conversation with Dan Simon at Microsoft
indicated that the truncation is probably safe. I am not sure if I can
answer Sam's the questions at this point, but one suggestion that Dan
brought up is that why can't we just allow for negotiation and support
of multiple algorithms for the pseudorandom function/MAC calculation?
Sam you won't object to hashing the entire ZZ if we can do it without
depending on a particular checksum algorithm, correct?

Here I propose adding a checksum type field into the KDCDHKeyInfo that
is going to use for symmetric key derivations (see below).

Also the KDC should be able to insert some randomness if it decides to
use cached DH, to mitigate the threat of stolen-session-keys:

   KDCDHKeyInfo ::= SEQUENCE {
        << cut >>
        HMAC-PRF-Cksumtype            [3] Int32 OPTIONAL, 
               -- used in HMAC to derive a symmetric key from ZZ, 
               -- this is an un-keyed checksum.
               -- if absent, use truncation of ZZ as the key 
               -- generation seed
        Additional-data-to-hash       [4] OCTET STRING OPTIONAL, 
               -- append it to ZZ before key derivations if applicable
        ...
    }

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Nov 2004 18:31:44 -0500

On Monday, November 22, 2004 02:52:37 -0800 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

>         krb5PrincipalName OBJECT IDENTIFIER ::= { iso (1) org (3) dod (6)
(3) dod (6)
certificates(20)
> single component of the name type NT-ENTERPRISE [reference to the

The actual change here is adding case (2), which describes an additional
possibility for what constitutes a "Kerberos name in the otherName field".

This is one of the few outstanding issues holding up WGLC for PKINIT,
so I need to see some comments indicating whether people support this
change.  Sooner is better...

-- Jeff

---

From: Luke Howard <[email-masked]>
Date: Wed, 1 Dec 2004 12:39:57 +1100

>change.  Sooner is better...

I would support this in the interests of interoperability. Our 
implementation does. But I can agree that including vendor-specific
extensions/OIDs might be undesirable.

-- Luke

--