Subject: RE: pkinit-20 checksum problem

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 20 Oct 2004 01:26:48 -0700

Ken Raeburn wrote:

> Working on it, I found myself thinking that maybe it's the wrong
direction.

Perhaps you can recognize the need of hash functions in the messages
Paul and Sam and I had recently.

> the key-usage value could still be incorporated into a Kerberos
checksum
>  that ignores the supplied key, and 
> I think it would still have to be considered "unkeyed".

get_mic() does not use the key usage number.

> This seem more suited to the intended use and the CMS-oriented 
> context than the Kerberos types, and the 
> SHA-1 algorithm identifier is already in RFC 2630.

I would object introducing yet another new CMS object type at this state
of game.  We are closing down all the loosing ends, and let's ship the
document!

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Tuesday, October 19, 2004 5:05 PM
To: [email-masked]
Subject: Re: pkinit-20 checksum problem

As I agreed with Jeff to do, I've submitted a draft that specifies an
unkeyed sha1 checksum type, assigns checksum type number 14 to it, and
releases checksum type number 10 for future assignment.  (Though I think
the releasing of a number is totally unsupported by the IANA guidelines
we put together...maybe it'll just have to be "reserved"?)

Working on it, I found myself thinking that maybe it's the wrong
direction.

Any general use of Kerberos checksums must indicate the key and key
usage value to be used.  Put another way, the "unkeyed" algorithms
*do* have key and key-usage input parameters, they're just ignored.
And, to be picky, the key-usage value could still be incorporated into a
Kerberos checksum that ignores the supplied key, and I think it would
still have to be considered "unkeyed".

An explicitly unkeyed use like in PKINIT is an attempt to borrow a data
type from Kerberos to wrap up a message digest and an algorithm
identifier together, with no real relationship to checksums as used in
Kerberos.

I wonder, then, if perhaps PKAuthenticator, buried inside a CMS
SignedData field, should have two fields using existing CMS types:

    paDigestType  [3] DigestAlgorithmIdentifier,
    paDigest      [4] Digest

(RFC 2630 doesn't seem to include a message type with a digest but
omitting the message itself.)

This seem more suited to the intended use and the CMS-oriented context
than the Kerberos types, and the SHA-1 algorithm identifier is already
in RFC 2630.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 20 Oct 2004 05:02:57 -0400

> Paul and Sam and I had recently.

Need for hash functions, yes.  As part of the Kerberos crypto 
framework, no.

> get_mic() does not use the key usage number.

Not directly.  It uses a "specific key", which is derived from a 
"protocol key" and a key usage number.  We're usually referring to the 
protocol key when we say "key", so you can view get_mic as needing a 
protocol key and a key usage number, in addition to the message, though 
it is imprecise (as is constructing a bit string and asserting that you 
now have an encryption key, in the kcrypto framework).

> of game.  We are closing down all the loosing ends, and let's ship the

You didn't seem too worried about making last-minute changes to the 
crypto spec, and it's much further along (in terms of both technical 
completion and approval/publication process) than PKINIT.

Ken