Subject: pkinit asn1 module

From: Love <[email-masked]>
Date: Mon, 17 May 2004 16:01:07 +0200

Below is the a (slightly) cleaned up asn1 module for pkinit.

It doesn't include my proposal for CMS encryption/checksum types.

Love

-- PKINIT asn1 module --

KerberosV5-PK-INIT-SPEC {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosV5(2) modules(4) pkinit(TBD)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN

    IMPORTS
        SubjectPublicKeyInfo, AlgorithmIdentifier, Name
            FROM PKIX1Explicit88 { iso (1) identified-organization (3)
              dod (6) internet (1) security (5) mechanisms (5)
              pkix (7) id-mod (0) id-pkix1-explicit (18) }

        ContentInfo, IssuerAndSerialNumber
            FROM CryptographicMessageSyntax { iso(1) member-body(2)
              us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
              modules(0) cms(1) }

        KerberosTime, Checksum, TYPED-DATA, PrincipalName, Realm, EncryptionKey
            FROM KerberosV5Spec2 { iso(1) identified-organization(3)
              dod(6) internet(1) security(5) kerberosV5(2) modules(4)
              krb5spec2(2) } ;

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

    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
    id-pkdhkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 2 }
    id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
    id-pkekuoid  OBJECT IDENTIFIER  ::= { id-pkinit 4 }

    pa-pk-as-req INTEGER ::=                 TBD
    pa-pk-as-rep INTEGER ::=                 TBD
    pa-pk-ocsp-req INTEGER ::=               TBD
    pa-pk-ocsp-rep INTEGER ::=               TBD

    ad-initial-verified-cas INTEGER ::=      TBD

    td-dh-parameters INTEGER ::=             TBD
    td-trusted-certifiers INTEGER ::=        104
    td-certificate-index INTEGER ::=         105

    PA-PK-AS-REQ ::= SEQUENCE {
        signedAuthPack          [0] ContentInfo,
        trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
        kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
        encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
        ...
    }

    TrustedCA ::= CHOICE {
        caName                  [0] Name,
        issuerAndSerial         [2] IssuerAndSerialNumber,
        ...
    }

    AuthPack ::= SEQUENCE {
        pkAuthenticator         [0] PKAuthenticator,
        clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
        ...
    }

    PKAuthenticator ::= SEQUENCE {
        cusec                   [0] INTEGER,
        ctime                   [1] KerberosTime,
        nonce                   [2] INTEGER (0..4294967295),
        paChecksum              [3] Checksum,
        ...
    }

    TrustedCertifiers ::= SEQUENCE OF Name

    CertificateIndex ::= IssuerAndSerialNumber

    KRB5PrincipalName ::= SEQUENCE {
        realm                   [0] Realm,
        principalName           [1] PrincipalName
    }

    InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
        ca                      [0] Name,
        validated               [1] BOOLEAN,
        ...
    }

    PA-PK-AS-REP ::= CHOICE {
        dhSignedData            [0] ContentInfo,
        encKeyPack              [1] ContentInfo,
        ...
    }

    KDCDHKeyInfo ::= SEQUENCE {
        subjectPublicKey        [0] BIT STRING,
        nonce                   [1] INTEGER,
        dhKeyExpiration         [2] KerberosTime OPTIONAL,
        ...
    }

    ReplyKeyPack ::= SEQUENCE {
        replyKey                [0] EncryptionKey,
        nonce                   [1] INTEGER (0..4294967295),
        ...
    }

END

---

From: Brian Tung <[email-masked]>
Date: Mon, 17 May 2004 08:42:43 -0700

> It doesn't include my proposal for CMS encryption/checksum types.

Thanks, Love.  I wonder, would people find the draft easier to read if
*all* of the ASN.1 was at the end, and the text simply referred to the
module?

b

---

From: Love <[email-masked]>
Date: Mon, 17 May 2004 17:54:48 +0200

> *all* of the ASN.1 was at the end, and the text simply referred to the

I think the module should be include as an appendix, and all core structure
(not all the IMPORT for example) included within the document where they
are disussed. This will require us to make sure they are in sync, but will
make for easier reading.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 17 May 2004 15:29:25 -0400

On Monday, May 17, 2004 17:54:48 +0200 Love <[email-masked]> wrote:

> I think the module should be include as an appendix, and all core
> structure (not all the IMPORT for example) included within the document
> where they are disussed. This will require us to make sure they are in
> sync, but will make for easier reading.

I'm inclined to agree.  This worked well in kerberos-clarifications, and I 
think it will work well for PKINIT, provided that the document is clear on 
which is normative.

Note that the module must be valid ASN.1 and it _must_ compile, or the 
document cannot go to the IESG.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 May 2004 17:22:36 -0400

This module looks good.

However I believe that the Kerberos practice of defining what key and
data are used for each encrypted/checksummed item is a good one.

I'd recommend doing that here as well once we figure out the naswer.

---

From: Love <[email-masked]>
Date: Tue, 18 May 2004 11:36:29 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I'm inclined to agree.  This worked well in kerberos-clarifications,
> and I think it will work well for PKINIT, provided that the document
> is clear on which is normative.
>

it compiles with asnp and heimdal compiler (slightly modifies since
heimdal's compiler can't handle oid definitions).

Love