Subject: RE: pkinit-20 checksum problem

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 20 Oct 2004 02:10:59 -0700

Ken wrote:
>  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.

The delay of PKINIT will make it miss the boat for our next release,
something I wanted to avoid at all cost.

A delay of 8 weeks by kcrypto won't have such an impact (we already have
the AES support based on it). The worst scenario I can see is that we
have kcrypto ready again when PKINIT is ready.

-- larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2004 2:03 AM
To: Liqiang(Larry) Zhu
Cc: IETF Kerberos Working Group
Subject: Re: pkinit-20 checksum problem

On Oct 20, 2004, at 04:26, Liqiang(Larry) Zhu wrote:
>  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.

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

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

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

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

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

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Oct 2004 05:24:37 -0400

> have kcrypto ready again when PKINIT is ready.

Pulling kcrypto means also pulling Clarifications.  Both documents
are sitting in the RFC editors queue.  They are approved documents
which are now "Proposed Standards".  The fact that the RFC Editor
has not formatted them for publication does not change that fact.
A decision by the working group to pull the documents at this stage
will cause the working group to lose all credibility with the IESG,
the IETF Secretariat and the RFC Editor.  Never again will we be
able to give them something for review without them second guessing
us.  The formation of the Kitten working group might also be placed
in jeopardy since so many of the involved parties overlap.

As I have said previously, you cannot pull the existing documents.
If you wish to ask the working group to consider "kcrypto-bis"
you may do so.

 > something I wanted to avoid at all cost.

Then I suggest that PKINIT be defined in such a way that it is
standalone and includes all of the functionality necessary for it
to be implemented without reliance on additional external specifications.

Jeffrey Altman