Subject: RE: PKINIT issues

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 1 Jun 2004 02:17:40 -0700

Jeffrey Hutzelm wrote:
> -- diffie-hellman open issues
>   - Larry Zhu has volunteered to research this

I would like to explore the options of allowing both the KDC and clients
insert randomness into the exchanged key, thus enabling static-static DH
key exchange. I am writing up a simpler proposal for this (simpler than
the one I sent over a while back), to address the complexity issue. I
shall be able to send it out within the next two weeks or so.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Wednesday, May 19, 2004 9:20 AM
To: Brian Tung
Cc: [email-masked]
Subject: Re: PKINIT issues

On Tuesday, May 18, 2004 21:45:44 -0700 Brian Tung <[email-masked]>
wrote:

> Jeffrey Hutzelman wrote:
>> I'm including below my accumulated state so far on open issues.
>
> Did I miss it?  Was it supposed to be a list?

My bad; I forgot to actually append the file...

MILESTONES:

NOV 21  - submit pkinit-17
JAN 12  - submit pkinit-18 with all updates above
MAR     - WG last call

OPEN ISSUES:
-- Update PA types [Cliff Neuman + editor; last]
-- ASN.1 errata - wrong module import for PKIX
-- ASN.1 errata - incorrect/multiple import statements
-- ASN.1 errata - subjectAltName definition
-- ASN.1 errata - wrong context tag in TrustedCas (0->1, 1->2)
   Dropping principalName[0] should not have renumbered other fields

-- ASN.1 module appendix
   - Eric Rosenfeld would like to see a complete module in an appendix

-- OCSP tunneling:
   - Microsoft's OCSP text included defining a tunneling mechanism for
OCSP
     in PKINIT.  Eric Rosenfeld objects to including this in PKINIT; he
     suggests moving it to a separate draft.
   - Sam Hartman says it was his understanding that this was what we
     were expecting.  He asks what we lose by moving it into a separate
     draft, and whether we have people interested in handling it as a
     separate draft.

-- AD-INITIAL-VERIFIED-CAs
   - Nico provided text for an AD type to include CA's used in cert
     verification by the KDC.
   - Eric Rosenfeld objects to making this mandatory for PKINIT
   - Sam believes this needs to be mandatory, as it performs a function
     analgous to that of transited-realms, and is needed for the same
     reasons.

-- diffie-hellman open issues
   - Larry Zhu has volunteered to research this

-- comments on PA-PK-AS-REP (from lha)
-- KDC certificate issue (from lha)
-- enctype vs OID issue (from lha)

CLOSED ISSUES:
++ REMOVE use of raw public keys [editor] REMOVE name transformation 
++ [editor] REMOVE principal name as trusted-CA [editor] 
++ Internationalization of strings [Jeff Altman] Extensibility [Jeff 
++ Hutzelman] Confirm alignment with CMS [Todd Stecher/Microsoft] 
++ initial flag issue [initial flag SET for pkinit; confirmed on list] 
++ transited CA's AUTH-DATA [bcn, Nico Williams] OCSP and optional 
++ revocation information [JK] Security of cached DH values and use of a

++ nonce [JK] Confirm alignment with kerberos-clarifications [Nico 
++ Williams] How to transform DH shared secret into a key [Sasha 
++ Medvinsky] Confirm alignment with kcrypto [Sasha Medvinsky] client 
++ name canonicalization problems (from Nico)
xx refactoring preauth [Sam Hartman]
++ name canonicalization / cname optionality
   - MS requested "blank" name for use when requesting canonicalization
   - Sam Hartman - still an open issue whether this is allowed
   - Larry indicates MS is fine with moving this feature to referrals
++ specify subjectAltName for user cert [tlyu, jaltman, editor]

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Jun 2004 14:06:26 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> Jeffrey Hutzelm wrote:
    >> -- diffie-hellman open issues - Larry Zhu has volunteered to
    >> research this

    Liqiang(Larry)> I would like to explore the options of allowing
    Liqiang(Larry)> both the KDC and clients insert randomness into
    Liqiang(Larry)> the exchanged key, thus enabling static-static DH
    Liqiang(Larry)> key exchange. I am writing up a simpler proposal
    Liqiang(Larry)> for this (simpler than the one I sent over a while
    Liqiang(Larry)> back), to address the complexity issue. I shall be
    Liqiang(Larry)> able to send it out within the next two weeks or
    Liqiang(Larry)> so.

Please restrict yourself to the operations defined in kcrypto.  We
convinced ourselves that generating a combine keys function was
possible with those operations.  I believe kenh has the notes on this.

Actually, wait, doesn't the existing proposal *require* both sides to
contribute randomness to keys?