Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
draft-ietf-cat-kerberos-pk-init-34

Logging the major comments from Gen-ART review by Elwyn Davies, on the pk-init draft:

1) While doing the LC review I was somewhat confused about the registrations of 'magic numbers' across the various Kerberos RFCs/drafts.  I would normally have expected that RFC4120 established a number of IANA registries for things such as the 'key usage' numbers and 'error numbers' but I have now had it explained that registration 'has been retained in the Working Group' probably until rfc1510ter is published.  I personally have some qualms about the integrity of this unusual practice, and I don't see a single public list of the registrations (although somebody clearly knows them all!). It appears that RFC4120 'pre-registered' some of the items needed for this draft (flagged with [pkinit] in RFC4120) but in the subsequent development of this draft additional items have become necessary. I think it should be made clear which additional items are new and which were already registered in RFC4120 just as would be the case if there were IANA considerations.

2) The key usage number that is cited in s3.2.3.2 is overloaded (see detailed comment below).  Discussion indicates that this does not result in a security problem (because it is used with a different key) but there needs to be some comment to explain that this has happened and why it isn't a problem.

3) Appendix C should mention Windows XP.  Discussion indicates that the 'next version' after Windows 2003 Server referred to is not in fact Windows XP as this naive reader assumed but something that might have an internal code name of Vista.  However, I think this actually makes it more important to clarify the position of the KDC in Windows XP Professional.  Windows XP Professional is not just a Kerberos client but can also act as a server if I understand correctly because Windows XP Professional can act as a Windows security domain controller in which role the KDC has to offer services even if the whole system is not a 'server' in the sense that Windows 2003 Server edition implies.

draft-ietf-cat-kerberos-pk-init-34 says:

 All data structures carried in OCTET  STRINGs must be encoded according to the rules specified in
   corresponding specifications.

"Corresponding specification" isn't very clear here, as it isn't clear how it relates to the data structures
spec.  I think this example is clear:

 PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].

For this, the OCTET STRING is, in fact, encoded according to RFC3852 (CMS).
There are other data structures referring to other documents (e.g. 3280), but
this wasn't very clear from the original phrasing.  Would this be clearer?

Each data structure using OCTET STRINGs will provide a specific reference to the encoding
it uses.