>>>>> "Elwyn" == Elwyn Davies <[EMAIL PROTECTED]> writes:
Elwyn> Well, I fear I may be going to provoke another version,
Elwyn> because although it is IMO almost ready for PS, the IANA
Elwyn> considerations need some attention.
But as you will see below, not from this draft.
Elwyn> I am also unsure if
Elwyn> the key usage number that is cited in s3.2.3.2 is right
Elwyn> (see detailed comment below).
Elwyn> It would also be good to make Appendix C a little more up
Elwyn> to the minute if it is going to remain in place.
It's as up to the minute as it can be.
The release of Windows anticipated by appendix C is Vista.
Note that the primary editor is the lead Kerberos developer for Microsoft.
Elwyn> Issues: s3.2.3.2: Key usage magic number 6. This number is
Elwyn> presumably taken from the list in RFC4120 but I can't tally
Elwyn> 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)
Elwyn> I suspect that this is NOT the same usage as #6 in RFC4120
Elwyn> and rfc1510ter draft and it needs a new key usage number
Elwyn> allocated.
*sigh* I suspect that it's too late to change this in all the
implementations. I agree it should not be the same key usage number.
However since key usage 6 is currently only used with the session key,
there is not a security problem using 6 again with the reply key for
this checksum. I think several vendors have shipping/almost shipping
code that works this way. So in order to change things you'd need to
show an actual security problem. I'm confident no such problem
exists.
I'll confirm with the WG chair and authors and probably end up
preparing an rfc editor note to describe the issue and to confirm 6 is
intended.
Elwyn> I tried to find the registries apparently set up by RFC4120
Elwyn> but I couldn't find them! Maybe I was looking in the wrong
Elwyn> place as I did find a message discussing the expert review
Elwyn> for allocating some new key usage numbers for KINK and
Elwyn> there is also a list in
Elwyn> draft-ietf-krb-wg-rfc1510ter-02.txt.
No, the registries are not set up by RFC 4120. Kerberos does not yet
use IANA for anything besides encryption types. RFC 4120 includes a
bunch of constants. 1510ter actually sets up IANA registries and
populates them with a superset of what is in 4120. The Kink request
was not so much an expert review as a confirmation that the values
Kink is publishing with made it into 1510ter so they make it into the
initial registry.
Elwyn> s6: 'This document has no actions for IANA.': This is not
Elwyn> correct. At least s3.1.2 defines new error codes and other
Elwyn> items which need to be registered. RFC4120 reserves a
Elwyn> number of error codes for pkinit but doesn't give actual
Elwyn> meaning, but additional ones have been defined here (#s
Elwyn> 77-80). The authorization data type is new and
Elwyn> TD_DH_PARAMETERS is new. Also RFC4120 reserves two unused
Elwyn> pre-authentication data types for pkinit (..._OLD - #s 14
Elwyn> and 15) - these should probably be noted as deprecated. I
Elwyn> am not sure about the items in s3.1.3. I also think the
Elwyn> key usage number needs registration (and a name?).
Again, these are not yet handled by IANA. I'll definitely ask the
1510ter editor to confirm he has all the pkinit changes.
Elwyn> Appendix C: This talks mainly about Windows 2000 and states
Elwyn> 'It is anticipated that the next release of Windows is
Elwyn> already too far along to allow it to support the issuing
Elwyn> KDC certificates with id-pkinit-san SAN as specified in
Elwyn> this RFC. Instead, ...'. I think this appendix is a victim
Elwyn> of the long gestation time of this draft. Maybe something
Elwyn> definite can be said about Windows XP if this is thought
Elwyn> useful?
XP is not a server OS; 2003 is roughly the same as 2000. This
appendix is mostly trying to talk about Vista.
In conclusion, I don't think a new version is needed for this issue,
although -34 has been submitted to address comments in the WG.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
