Subject: Comments and questions on rfc1510ter-04

From: KAMADA Ken'ichi <[email-masked]>
Date: Tue, 12 Jun 2007 14:01:03 +0900

I have read through rfc1510ter-04 (hereinafter [ter04]) and Tom's
material at IETF-67 (hereinafter [Yu67]).  Here are my comments and
questions except those already listed in the Tom's open issues.
Considering the alternatives to 1510ter, I'm uncertain about the
direction of 1510ter, but I'm sending this for a record.

* UTF8String

  ** Preparation for password string
	The string preparation for password seems missing.  It doesn't
	transmitted over the wire, but without the preparation,
	decoding EncryptedData would fail on the receiver.

  ** Mixture of IA5 and UTF8 in a principal name
	From the definition of PrincipalNameEither [ter04 section 5.2],
	it seems possible to mix different choices (ia5 or utf8) in
	the components of a principal name.  I don't think it is
	desirable.

  ** Which of IA5String and UTF8String is used in a unconstrained
     KerberosString?

* Signed Types

  ** KeyToUse
	Some Signed types have no or undefined keys to be used.
	- TicketExt: key-ticket is not defined.
	- {AS,TGS}-REP-EXT: key-reply is not defined.
	- KRB-ERROR-EXT: KeyToUse is empty.

  ** Unsigned KRB-ERROR
	[ter04 section 9]
	The text says KRB-ERROR-EXT is optionally signed, but
	its ASN.1 type doesn't say so.

	If there is no key to sign a KRB-ERROR, what should we do?
	a) Use KRB-ERROR-EXT without signing?
	   --> Fix ASN.1 type definition to make this possible.
	b) Fallback to KRB-ERROR-1510?
	   --> But we might want to use UTF8String for e-text.

* Are the goals of 1510ter [Yu67 page 2] satisfied?

  ** Can other WG items move forward?
	+ PKCROSS
		TicketExtensions
	+ I18N
		UTF8String
	+ any other?

  ** PK extensions
	[Yu67 page 2] says:
	> Where possible, support PK extensions
	Is anything other than PKINIT assumed?

  ** shared KDB and keys
	[Yu67 page 2] says:
	> Protocol guarantees shared KDB and keys
	I have no idea what is meant by "shared KDB and keys".

* ASN.1
	[ter04 section 8.1]
	In the definition of KDC-REQ-BODY-EXT, "lang-tags" has tag
	number 5, but it duplicates the number of "till".  Is it okay?

	[ter04 section 8.1]
	In the definition of KDC-REQ-BODY-EXT, a comma seems missing
	after the first extension marker.

	[ter04 section 8.4]
	EncKDCRepPartCom is used without a definition.

	[ter04 section 8.4]
	In the definition of req-cksum, a parameterized type (KDC-REP-EXT)
	is used without any parameter.

	[ter04 section 10.1 and 11.1]
	ApReqExtensions, KRB-SAFE-1510, and KRB-SAFE-EXT are not defined
	in the body, but only in appendix.

	[ter04 section 11.2]
	Why KRB-PRIV does not have 1510 and EXT versions like other types?

	[ter04 several places]
	Unparameterized PricipalNames are used.  Is it okay?
	Should PrincipalNameEither be used?
	(And same for Realm.)

* misc
	[ter04 section 4.7.2] (actually inherited from RFC 4120...)
	> IPv4-mapped IPv6 addresses MUST be represented as addresses of
	> type 2.
	I think "IPv4-mapped IPv6 addresses MUST be represented as
	corresponding IPv4 addresses of type 2" is clearer.

	[ter04 section 5.6]
	I can't parse the first sentence.  Possibly due to my poor English
	parser, but I feel there is a copy-and-paste error.

	[ter04 section 8.3.5]
	Break after "Address Processing".

* Duplicated texts
	Section 6.4, the description of KeyUsages

	Section 7 and 7.5

	Section 8.1, the definition of KDC-REQ-*

-- 
KAMADA Ken'ichi <[email-masked]>