On Thu, 9 Feb 2006, Elwyn Davies wrote: > One item which should be carefully checked before final > publication: There are a number of OIDs embedded in comments in the > ASN.1 (e.g., the comments to the definition of PA-PK-AS-REQ in s3.2.1) > and these can only be checked manually.
Noted. > Issues: > s3.2.3.2: Key usage magic number 6. This number is presumably taken > from the list in RFC4120 but I can't tally the usage in this draft with > the specification in RFC4120 > > 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, > > keyed with the TGS session key (Section 5.5.1) > I suspect that this is NOT the same usage as #6 in RFC4120 and > rfc1510ter draft and it needs a new key usage number allocated. This is an interesting issue, and one I think I will want to take back to the working group. I agree the usage described in PKINIT 3.2.3.2 is not the same as that described in RFC4120 for this number. However, it will never be the case that the same key is used in both situations, and the data being checksummed in each case cannot be mistaken for each other (both are checksums of the encodings of distinct ASN.1 types; some bits of the encoding are constant in each case and cannot be the same). The main issue is taht there may already be implementations which it is too late to chnage, in which case we'll have to weigh the benefits of assigning a unique key usage for this case against the interoperability cost. > I tried to find the registries apparently set up by RFC4120 but I > couldn't find them! Because they don't exist. RFC4120 section 9 states: ... Until a subsequent RFC specifies otherwise, or the Kerberos working group is shut down, allocations of additional protocol constants and other defined values required for extensions to the Kerberos protocol will be administered by the Kerberos working group.... The "subsequent RFC" referred to is the upcoming revision to the Kerberos spec, which draft-ietf-krb-wg-rfc1510ter-02.txt is intended eventually to become. Until then, the namespaces defined in RFC4120 are being managed by the working group. Needless to say, this has caused some confusion during review of documents issued in the interim. > s6: 'This document has no actions for IANA.': This is not correct. Actually, it is. AD, PA, and TD types and error codes are all in the category of namespaces being managed by the WG for now. Key usages are as well, to the extend that becomes an issue. Encryption types (defined in RFC3961) are the subject of an IANA registry, but the values used by PKINIT were pre-assigned when the registry was created. > Appendix C: This talks mainly about Windows 2000 and states 'It is > anticipated that the next release of Windows is already too far along to > allow it to support the issuing KDC certificates with id-pkinit-san SAN > as specified in this RFC. Instead, ...'. I think this appendix is a > victim of the long gestation time of this draft. Maybe something > definite can be said about Windows XP if this is thought useful? Actually, this appendix is a very recent addition. To my knowledge, the behavior described applies to Windows 2000 and all newer versions released to date. The "next release of Windows" to which it refers has not in fact been released. > Very minor: > s3.2.3.1: Derivation of AS reply key, Step 3: '...K-truncate truncates > its input to the first K bits.' s/first/leftmost/ possibly. Possibly. I will note that bits in a bitstream are ordered, so you can speak clearly of the first bit. On the other hand, which bit is leftmost depends on the order in which you choose to write them down. > Editorial: > s1, para 2: s/The corner-stone of Kerberos V5 is/The corner-stones of > Kerberos V5 are/ Yup; this can be fixed in editing. > s1,bullets 1 and 2: the acronyms AS and TGS are slightly overloaded (S > stands for either Service or Server in both cases). Yes; they are, but it's a natural overloading. RFC4120 is less than consistent in which term it chooses to use, and in fact defines the terms "Server" and "Service" somewhat confusingly. > s8,para: s/In addition, if any CA is trusted to issue KDC certificates > can also/In addition, if any CA that is trusted to issue KDC > certificates can also Yes. Thanks for your comments. To my knowledge, yours are the only comments we received during IETF last call which originated outside the working group. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Chair, IETF Kerberos Working Group Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
