[krbdev.mit.edu #7062] PKINIT pa_pk_as_req_draft9 encoding issues

Greg Hudson via RT rt-comment at krbdev.mit.edu
Sun Jan 8 23:29:37 EST 2012


draft-ietf-cat-kerberos-pk-init-09 defines PA-PK-AS-REQ as:

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

Per this spec, all four fields (when present) should have constructed 
context-specific tags wrapping universal constructed sequence tags, with 
the sequence contents for SignedData and IssuerAndSerialNumber defined 
by RFC 2630.

Our encoder for this type generates primitive context tags for the 
first, third, and fourth fields, as if the CMS encodings were wrapped in 
IMPLICIT OCTET STRING.  (CMS types in PKINIT are actually specified this 
way in draft 20 and onward, but not in draft 9.)

Our decoder for this type is not consistent with either the draft or the 
encoder.  It expects a primitive context tag for the first field, but 
expects a constructed context tag for the third and fourth fields.  It 
also expects the fourth field to have the context tag number 2 instead 
of 3, which is apparently a typo.

For reference, Heimdal defines its version of the structure as:

PA-PK-AS-REQ-Win2k ::= SEQUENCE {
    signed-auth-pack        [0] IMPLICIT OCTET STRING,
    trusted-certifiers      [2] SEQUENCE OF TrustedCA-Win2k OPTIONAL,
    kdc-cert                [3] IMPLICIT OCTET STRING OPTIONAL,
    encryption-cert         [4] IMPLICIT OCTET STRING OPTIONAL
}

Note that (like us) this definition uses primtive context tags for the 
CMS types; unlike us, the tag numbers for the second, third, and fourth 
field are shifted upward by one.

The purpose of our draft9 code is to interoperate with Windows 2000, not 
to faithfully implement the draft9 spec, so we probably don't want to 
change anything without interop testing.  It seems likely that decoding 
pa_pk_as_req_draft9 was never tested, so it's probably an unusual case 
(Windows 2000 client against MIT KDC).



More information about the krb5-bugs mailing list