Subject: Re: Kerberos Working Group Last Call - PKINIT

From: Sam Hartman <[email-masked]>
Date: 11 Feb 2001 16:46:14 -0500

I have several comments  so far:

1) There are normative references to pkcross and pktapp in the
    introduction.  These documents have not been reviewed and it is
    not clear we have committed to these directions; perhaps these
    documents should backreference to pkinit instead.

2) Around line 218, the document uses the word shall; I really think
   it means MUST.  However, I'm also concerned with the text.  It
   requires the KDC to use a specific name type for x500 principals
   and requires the client to do the same.  So far, we have not
   actually required the name type be used, or at least we have always
   allowed the unknown name type to be used and required that it work.
   I do not agree with this change, and certainly think more effort
   should be put into thinking through the implications of this
   change.

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.

4) Around line 260, the text refers to principals given as
   user+instance.  I don't think that RFC1510 defines instance as
   related to users, nor does it   really use instance as a
   well-defined term.  I really think you want to define the matching
   rules in terms of components, without treating components as
   distinguished.  

5) Still in the same constraint matching, isn't  a x500 realm name
   likely to  be of type other since the encoding  specified earlier
   in the document  requires it?  Won't this mean we always get
   byte-for-byte matches even for x500 realms?

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.

7) In the header to 3.2, the text states that certs are not needed if
   the case where the KDC maintains public keys.  Yet on line 448, the
   text requires the client to include at least a signature cert.
   Reconcile please.

8) I am also uncomfortable with the current S/MIME text and would need
   more clarification.  After I understand what is going on, I am
   likely to raise objections to doing it, but I cannot formulate such
   objections at this time as I do not understand the text.  

9) In 3.2.2, why do we prefer a KDC cert issued by the client's CA to
   one issued by one of the client's trusted certifiers?

10) Around line 693, please reference some authority whose
   implementation you follow.  Including explanatory text is
   reasonable, but pkinit should not be authoritative for  DH.
   Mentioning DES keys specifically seems bad.

11) Around line 756  the text specifies that RSA  keys must be used
    for KeyTransRecipientInfo .  This seems out of place for pkinit.
    Pkinit should require RSA support, but should not limit what
    encryption can be used.

12) On line 801 indicate that you are taking encryptionkey from
    revissions;  you do not define it yourself.

13) On line 811, the document flow must be improved.  We have just
    concluded text on the non-DH case, and the text jumps to dealing
    with transited realms with no section break or other marker that
    people skipping the non-DH case should start paying attention
    again.  I could even make a weak argument that those only looking
    at DH don't need to implement that section of text based on the
    flow.

14) The introduction claims that the KDC can store private keys, but
    the mechanisms to do that appear to have disappeared.  This is
    probably good, but the references to thes mechanisms should be
    removed.

In all, this document has improved a lot since I last examined it.
I'd still like to see someone from the public key community read the
document and say that the use of standards are appropriate--things
that are included by value should be included by value; references are
to the most reasonable thing to refer to; abstractions are used
appropriately.