Subject: PKINIT-30 editorial changes

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 28 Nov 2005 03:30:55 -0800

Attached should contain all agreed-upon changes so far. I also tried to
write somewhat more detailed descriptions for each change.

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                     Microsoft Corporation
Expires: June 1, 2006                                            B. Tung
                                      USC Information Sciences Institute

[lzhu] this change would make sense, wouldn't it?

   In this document, an empty sequence in an optional field can be
   either included or omitted: both encodings are permitted and
   considered equivalent.

[lzhu] this is what we agreed in IETF64.

   In this document, the term "Modular Exponential Diffie-Hellman" is
   used to refer to the Diffie-Hellman key exchange as described in
   [RFC2631], in order to differentiate it from other equivalent
   representations of the same key agreement algorithm.

[lzhu] this was what confused Jeff about the references. Additional
changes were made to make the specific references clear to read. Such as

       des-ede3-cbc (three-key 3DES, CBC mode, as defined in [RFC3370])
       rc2-cbc       (RC2, CBC mode, as defined in [RFC3370])
       id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])

       Notes to CMS
       implementers: the signed attribute content-type MUST be present
       in this SignedData instance and its value is id-pkinit-authData
       according to [RFC3852].

[lzhu] added per request from Love, there are 2 other similar changes
but the same reason.

   The ExternalPrincipalIdentifier structure is used in this document to
   identify the subject's public key thereby the subject principal.
   This structure is filled out as follows:

   1.  The subjectName field contains a PKIX type Name encoded according
       to [RFC3280].  This field identifies the certificate subject by
       the distinguished subject name.  This field is REQUIRED when
       there is a distinguished subject name present in the certificate
       being used.

   2.  The issuerAndSerialNumber field contains a CMS type
       IssuerAndSerialNumber encoded according to [RFC3852].  This field
       identifies a certificate of the subject.  This field is REQUIRED
       for TD-INVALID-CERTIFICATES and TD-TRUSTED-CERTIFIERS (both
       structures are defined in Section 3.2.2).

   3.  The subjectKeyIdentifier [RFC3852] field identifies the subject's
       public key by a key identifier.  When an X.509 certificate is
       referenced, this key identifier matches the X.509
       subjectKeyIdentifier extension value.  When other certificate
       formats are referenced, the documents that specify the
       certificate format and their use with the CMS must include
       details on matching the key identifier to the appropriate
       certificate field.  This field is RECOMMENDED for TD-TRUSTED-
       CERTIFIERS (as defined in Section 3.2.2).

[lzhu] added per request from Love.

How to fill in PKAuthenticator and part of AuthPack is currently missing
in the main body of the text, I can not argue it is not normative, but
the current description is rather clear. This is the part of comments I
found agreeable from jeff's email. In theory all I need to do is to copy
the comments to the main body for these fields, if this working group
feels strong about doing that, I can do that too.

   The AlgorithmIdentifier structure is defined in [RFC3280] and is
   filled in according to [RFC3279].  More specifically Section 2.3.3 of
   [RFC3279] describes how to fill in the AlgorithmIdentifier structure
   in the case where MODP Diffie-Hellman key exchange is used.

[lzhu] requested by Love.

   Furthermore the KDC computes the checksum of the AS-REQ in the client
   request.  This checksum is performed over the type AS-REQ and the
   protocol key [RFC3961] of the checksum operation is the replyKey and
   the key usage number is 6.  If the replyKey's enctype is "newer"
   [RFC4120] [RFC4121], the checksum operation is the required checksum
   operation [RFC3961] of that enctype.

[lzhu] requested by love.

   When the Diffie-Hellman key exchange method is used, additional pre-
   authentication data [RFC4120] (in addition to the PA_PK_AS_REQ as
   defined in this specification) is not bound to the AS_REQ by the
   mechanisms discussed in this specification (meaning it may be dropped
   from the request by attackers without being detected by either the
   client or the KDC).  Designers of additional pre-authentication data
   should take that into consideration if such additional pre-
   authentication data can be used in conjunction with the PA_PK_AS_REQ.
   The future work of the Kerberos working group is expected to update
   the hash algorithms specified in this document and provide a generic
   mechanism to bind additional pre-authentication data with the
   accompanying AS_REQ.

[lzhu] requested by Aaron and Love.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 28 Nov 2005 10:58:44 -0500

Larry:

> changes were made to make the specific references clear to read. Such as

This does indeed clarify what is intended.

>        id-aes256-CBC (AES-256, CBC mode, as defined in [RFC3565])

The identifier "id-aes256-CBC" is only referenced in the 3.1.3 list.  It 
is not used anywhere else in the document.   Most importantly, the 
algorithm has not been assigned an encryption type value in Section 
3.1.2.  Is there a reason why 3.1.2 does not contain something similar to:

        id-aes256-CBC-EnvOID                          XX
           -- Indicates that the client supports id-aes256-CBC

What is the relationship between the identifiers found here in 3.1.3 and 
  the enctype value assignments in 3.1.2?  Assuming that 
"sha1WithRSAEncryption refers to "sha-1WithRSAEncryption" as listed in 
3.1.3, shouldn't the comment in 3.1.2 at the very least reference the 
3.1.3 identifier?

> feels strong about doing that, I can do that too.

Making this change would make it much easier for someone trying to 
implement the draft as they would not have to bounce back and forth 
between different sections of the document in order to understand what 
must be done.

I still believe that adding "(see Section 3.2.1)" after 
"ExternalPrincipalIdentifier" in the ASN.1 comments of 
AD-INITIAL-VERIFIED-CAS would be helpful as well.  Another solution 
would be to duplicate the "ExternalPrincipalIdentifier" ASN.1 in Section 
3.2.2.

----

In addition to the listed changes, I want to point out for the benefit 
of the group that you also addressed some other concerns I raised:

* the extraneous reference to X.509-97 that was not being used was
   removed

* the typographical errors in 3.2.3.1 were fixed

* the source of "dhpublicnumber" was corrected to reference RFC3279
   although without the reference to X9.42.  X9.42 is the original
   source of this identifier.

   [X9.42]   ANSI X9.42-2000, "Public Key Cryptography for The Financial
   Services Industry: Agreement of Symmetric Keys Using Discrete
   Logarithm Cryptography", December, 1999.

* the awkward text in 3.2.3.2 was fixed.

Thank you.

Jeffrey Altman