Subject: [saag] Updates Needed for draft-hotz-kx509-00

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 13 May 2010 18:32:19 -0700

I was able to circulate this draft privately before I had clearance to submit it.  Based on feedback from two implementors of the protocol I can already say:

1) There should be a standards-track version of an update to the protocol which takes advantage of the evolution of both Kerberos and PKI since the protocol was created.

2) The draft, though written to be standards-track, should instead be informational.

I welcome other feedback.  Comments I have so far are:

Should use the kerberos checksum instead of HMAC-SHA1 (IMO bumps protocol version).

Error codes should be standardized, allowing better client failover.

Public Key type needs more specification.  In particular some specification (or negotiation) of minimum key size, and allowable key types.  (Existing client implementations seem to only generate 512-bit RSA keys.  Needs updating, but that doesn't force a version change.)

Certificate encoding needs more specification.  In particular I'm told that the issued certificates should include:

	• KCA  "1.3.6.1.4.1.250.42"
	• KCA AUTH REALM   "1.3.6.1.4.1.250.42.1"
	• Krb5 Principal Name "1.3.6.1.5.2.2"
	• Use of subject Alt e-mail field for principal name
(I think I disagree with the last, since IMO a principal only looks like an email address, and it won't necessarily work as one.  If it's existing practice, then fine, but delete it in the new version.)

Add text to the security considerations noting that there is no proof the requester is in possession of the corresponding private key, which opens up a number of issues.  Shouldn't use these certs for digital signature.  (Need to fix this in the next version.  Isn't there a chicken-and-egg problem with using the PKI key pair for standard digital signatures in advance of having an actual certificate?)

Reference TAGPMA requirements.

Error text should be UTF8String instead of VisibleString  (IMO should change in new version.)

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 14 May 2010 14:29:28 -0700

I should have checked this first, but the third item is identically the kerberos principal name described in RFC4556, section 3.2.2.  I do believe the cert should unambiguously record what it's based on, and I think this is the correct way to do it.

On May 14, 2010, at 11:24 AM, Martin Rex wrote:

> Henry B. Hotz wrote:
>> 
>> Certificate encoding needs more specification.
>> In particular I'm told that the issued certificates should include:
>> 
>> 	o  KCA  "1.3.6.1.4.1.250.42"
>> 	o  KCA AUTH REALM   "1.3.6.1.4.1.250.42.1"
>> 	o  Krb5 Principal Name "1.3.6.1.5.2.2"
>> 	o  Use of subject Alt e-mail field for principal name
>> 
>> (I think I disagree with the last, since IMO a principal only looks
>> like an email address, and it won't necessarily work as one.
>> If it's existing practice, then fine, but delete it in the new version.)
> 
> I agree to your disagreement with the last.
> 
> The problematic thing with the rfc822Name subjectAltName is
> the underlying ASN.1 type:
> 
> http://tools.ietf.org/html/rfc5280#page-128
> 
> GeneralName ::= CHOICE {
>     otherName                 [0]  AnotherName,
>     rfc822Name                [1]  IA5String,
>     dNSName                   [2]  IA5String,
> 
> I don't recall a desision that I18N for Kerberos principal names
> was going to use an "ascii compatible encoding"...  8-]
> 
> 
> -Martin
> 
> _______________________________________________
> ietf-krb-wg mailing list
> [email-masked]
> https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Michael StJohns <[email-masked]>
Date: Thu, 13 May 2010 22:20:03 -0400

>(I think I disagree with the last, since IMO a principal only looks like an email address, and it won't necessarily work as one.  If it's existing practice, then fine, but delete it in the new versi…

See RFC4456 - specifically the id-pkinit-san subject alternative name encoding which defines a kerberos centric certificate name encoding.

Mike

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 May 2010 20:24:02 +0200 (MEST)

GeneralName ::= CHOICE {

-Martin