Subject: PKINIT-22 comments [jhutz]

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 03 Jan 2005 20:51:44 -0500

Overall, I am very happy with the reformatting introduced in pkinit-22;
moving from manually-maintained text to xml2rfc has made a definite
improvement.  I believe this document is very nearly ready for last call,
with one possible exception, which I will bring up in a separate message.

This version resolves #674 (PKINIT checksum negotiation), and appears to
also resolve #509 (DH key derivation).  I'd like to ask Sam to take a
look and see if he agrees that #509 is correctly resolved.

The following tickets are still outstanding:

 501  PKINIT 009 - Update PA types
      Values were filled in for the PA types and a couple of other
      numbers; Cliff needs to verify that these are appropriate.

 507  PKINIT 015 - Indicating PKINIT support
      There is new text to be incorporated describing handling of the
      content of the METHOD-DATA for PA-PK-AS-REQ

 509  PKINIT 017 - DH key derivation
      I believe this is actually resolved, but it needs Sam to verify.

 530  PKINIT 038 - DH groups selection
      This change did not appear in -22 and is still outstanding.

 612  algorithm OID for AES
      This change did not appear in -22 and is still outstanding.

I've added the following new tickets for issues I discovered in looking
at the differences between -21 and -22:

 765  PKINIT ASN.1 module OID
      Tom Yu needs to verify the selected OID is available.

 766  REQUIRED reply key delivery method change
      ...
      21< - Reply key delivery method: ephemeral-ephemeral Diffie-Hellman
      21<   with a non-zero nonce.
      ---
      22> o Reply key delivery method: RSA or ephemeral-ephemeral
      22>   Diffie-Hellman.

      This is a substantive change in requirements, which I do not recall
      being the subject of a working group concensus.  The effect of this
      change, as I read it, is to REQUIRE that implementations support at
      least one of RSA or DH, instead of requiring that all implementations
      support DH.

 767  reasons for rejecting a PKINIT client
      In Secton 3.2.2, the paragraph starting "Even if the chain is
      validated..." has been significantly reworded.  While the new text
      is somewhat clearer, the rewording has the apparently unintentional
      side-effect of restricting the reasons for which the KDC may choose
      not to trust the client.  The new text says "... the KDC may decide
      to reject requests on the basis of the absence or presence of
      specific EKU OIDs", while in the old text this is only one example
      of a reason the KDC may have for not trusting a client.

 768  DHRepInfo.dhSignedData has wrong type
      The dhSignedData field has type ContentInfo rather than
      WrapContentInfo.  This usage of an unwrapped CMS type is not
      consistent with our previous decision to wrap every CMS type in
      an OCTET STRING.

The idnits scanner finds no problems with pkinit-22.
It seems to comply with the id-checklist requirements.

In the Security Considerations section, please remove the redundant
comment "[This seems to reflect the consensus of the Kerberos working
group.]".  Only things that reflect the consensus of the WG will appear
in any document we send to the IESG.