Subject: Re: PKINIT: various [resend due to message overflow]

From: Ken Raeburn <[email-masked]>
Date: 02 Mar 2001 17:09:20 -0500

> If and when RFC 1510bis specifies uniform key generation functions for
> various cryptosystems, and doing so makes it appropriate to change
> PKINIT to reflect this change, we'll revisit this segment of the spec
> (3.1.1) at that time.

The rewrite of section 6 I sent out a pointer to (it's to big to mail
out) does so, though I haven't heard any feedback on it.

I could probably have emphasized more which functions should be
avaliable for preauth and other facilities to use.  I already will
need to add more key usage numbers for Tom's changes to section 5, so
a new version will be needed.

> SH:
> > 3) In the same paragraph, it describes how to set the name string for
> >    the x500 principal.  Don't we already do that in revisions?  Why
> >    does pkinit need to either do something different that standard
> >    practice for x500 principals, or if it is specifying the same
> >    thing, specify by value rather than reference?  When standards do
> >    this, I as an implementer must check to make sure the standard
> >    specifies the same thing as the referenced standard before I can
> >    reuse libraries.  This is very annoying and when the standards
> >    needlessly conflict, damaging.
> 
> At the present time, RFC 1510 revisions does not give a complete
> specification of how to encode X.500 names.  It provides an example
> (Section 7.1) which is not sufficient to flesh out a standard for
> interoperability.  PKINIT achieves this by adhering to a known
> standard--viz, RFC 2253.  

Then that's a bug in kerberos-revisions, in an area some of us haven't
been paying much attention to.  Why don't you propose a fix for that
document instead?

> SH:
> > 6)  I agree with Ken that 3.1.1 should hold off until we get 
> >     section 6 for revisions.  The current text is unfortunately DES specific.
> 
> Read the text carefully; it's not DES-specific.  DES is only used
> as an example.

It's not quite DES specific, but it's specific to certain key
representations.  Specifically, purely random bitstrings, or
bitstrings with parity.  If someday an encryption scheme is used with
some other key format, it'll break.  (Perhaps a random integer value
constrained to be less than some specified prime, but expressed with
enough bits to encode all the valid values and a few invalid ones
besides up to the next power of two -- the existing spec can't support
handle that constraint.)  The setup in kerberos-revisions section 6 is
intended to allow for that possibility.