Subject: Differences between Kerbeors revisions and PKINIT

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 31 Jul 2000 12:47:28 -0500

Tim Polk, said:

>Thanks for the update.  We expect to take the new PKIX profile into Last 
>Call immediately after the Pittsburgh meeting.  That means I need a way to 
>finesse the content *in* and the document reference *out*.

>Doug - are the krb5PrincipalName OID and KerberosName syntax stable?  One 
>strategy would be to embed the ASN.1 into our document.  Would you be 
>comfortable with this strategy?

krb5PrincipalName OID and KerberosName comes from PKINIT.

The use of the ASN1 and OID from PKINIT requires the Kerberos Revisions.
or RFC 1510 to define Realm and the name-type.   

I have a question: PKINIT defines CertPrincipalName using UTF8String
when the Revisions and 1510 defines PrincipalName using GeneralString. Both of
these contian the same information. This looks like it was done
on purpose, can someone explain why?  

PKINIT has:

     CertPrincipalName ::= SEQUENCE {
                        name-type[0]     INTEGER,
                        name-string[1]   SEQUENCE OF UTF8String
        }
...
    For the purpose of specifying a Kerberos principal name, the value
    in OtherName shall be a KerberosName as defined in RFC 1510, but with
    the PrincipalName replaced by CertPrincipalName as mentioned in
    Section 3.1:

        KerberosName ::= SEQUENCE {
            realm           [0] Realm,
            principalName   [1] CertPrincipalName  -- defined above
        }

    This specific syntax is identified within subjectAltName by setting
    the type-id in OtherName to krb5PrincipalName, where (from the
    Kerberos specification) we have

        krb5 OBJECT IDENTIFIER ::= { iso (1)
                                     org (3)
                                     dod (6)
                                     internet (1)
                                     security (5)
                                     kerberosv5 (2) }

        krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 }

Kerberos revisions has Realm and PrincipalName:

Realm ::=           GeneralString
PrincipalName ::=   SEQUENCE {
                    name-type[0]     INTEGER,
                    name-string[1]   SEQUENCE OF GeneralString
}

... 

name-type      value   meaning

    NT-UNKNOWN        0   Name type not known
    NT-PRINCIPAL      1   General principal name (e.g. username, DCE
principal)
    NT-SRV-INST       2   Service and other unique instance (krbtgt)
    NT-SRV-HST        3   Service with host name as instance (telnet, rcmds)
    NT-SRV-XHST       4   Service with slash-separated host name components
    NT-UID            5   Unique ID
    NT-X500-PRINCIPAL 6   Encoded X.509 Distingished name [RFC 1779]
    NT-SMTP-NAME      7   Name in form of SMTP email name (e.g.
[email-masked])

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Tom Yu <[email-masked]>
Date: 31 Jul 2000 16:50:04 -0400

>>>>> "deengert" == Douglas E Engert <[email-masked]> writes:

deengert> I have a question: PKINIT defines CertPrincipalName using
deengert> UTF8String when the Revisions and 1510 defines PrincipalName
deengert> using GeneralString. Both of these contian the same
deengert> information. This looks like it was done on purpose, can
deengert> someone explain why?

GeneralString is a mistake.  It should never have been in the base
Kerberos spec but there was no UTF8String defined in ASN.1 originally.
GeneralString is seven or eight bit characters with shift encodings as
per ISO 2022 I believe, which is really hideous to handle properly.
There's been a sort of agreement to treat everything that's tagged
GeneralString in Kerberos as actually being UTFString.  I don't know
offhand whether this causes problems with any ASN.1 compilers though.

---Tom