Subject: RE: PKINIT-19 comments

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 27 Apr 2004 08:53:02 -0700

Nicolas Williams wrote:
> What's wrong with having subjectAltName as mandatory to implement?

subjectAltName implies you know the mapped principal's realm when you
issue the certificate, this might not be always possible.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Tuesday, April 27, 2004 8:48 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Sam Hartman
Subject: Re: PKINIT-19 comments

On Tue, Apr 27, 2004 at 02:24:14AM -0700, Liqiang(Larry) Zhu wrote:
> 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
>         ...
>     }

While I think this would be nice, we don't need this in order to "ship"
a PKINIT spec -- we can add features later.

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

What's wrong with having subjectAltName as mandatory to implement?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 27 Apr 2004 10:56:49 -0500

> issue the certificate, this might not be always possible.

I don't find this upsetting.

---

From: Martin Rex <[email-masked]>
Date: Wed, 28 Apr 2004 13:26:35 +0200 (MET DST)

> issue the certificate, this might not be always possible.

Rolling out a PKI to a large user base is (a) a huge effort and
(b) a costly effort.  This is particularly true if one is using
personalized crypto tokens (smartcards) holding the keys.

There are not only PKIs which are already in place that customers
will want to use for PKINIT, there is also the issue that new
Kerberos realms will be created/installed in the future for which
a PKI that is just being rolled out is not prepared.  i.e. the
installed base problem will never go away, therefore mandating a
particular mapping will be a serious problem for a significant
user base.

You also need to address 1:n mapping of certificates to
Kerberos accounts.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 28 Apr 2004 09:33:10 -0400

>You also need to address 1:n mapping of certificates to
Mapping of a Certificate to an organizations account unless being
performed using a well-known field of the certificate has always been
an organization specific process.  Often times this involves the
delivery of the client certificate or fingerprint to the organization
so that a mapping table from certificate to user can be created.

The PKINIT-19 draft specifies that organizational mappings
supercede everything else.  The question on the table is whether
there would be another mandatory to implement mechanism.
As far as I am concerned, the mandatory to implement mechanism
is the subjectAltName mapping.  This does not make it mandatory
for deployers to use.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 Apr 2004 10:29:06 -0500

> is the subjectAltName mapping.  This does not make it mandatory

Exactly.