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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 27 Sep 2004 00:47:48 -0700

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