Subject: | PKINIT trusted_ca encoding issues |
draft-ietf-cat-kerberos-pk-init-09 defines TrustedCA as:
TrustedCas ::= CHOICE {
principalName [0] KerberosName,
caName [1] Name
issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL
}
(OPTIONAL is not syntactically valid ASN.1 within a CHOICE, so let's
ignore that.) Per this spec, each alternative should consist of an
explicit context-specific tag followed by the encoding of the specified
object.
Our encoder for this type generates a primitive context tag for all
three alternatives, as if they were wrapped in IMPLICIT OCTET STRING.
Also, for the principalName alternative, it encodes an RFC 4120
PrincipalName instead of a KerberosName as defined by PKINIT (as a
sequence containing a [0] Realm and a [1] PrincipalName).
Our decoder for this type does not care whether the context tags are
primitive or constructed. It expects a KerberosName for the
principalName alternative, which matches the spec but not the encoder.
It grabs whatever is inside the context-specific tag for the other two
alternatives, so should correctly process either a spec-compliant or
encoder-generated caName or issuerAndSerial.
For reference, Heimdal defines its version of the type as:
TrustedCA-Win2k ::= CHOICE {
caName [1] heim_any,
isuerAndSerial [2] IssuerAndSerialNumber
}
which presumably results in the use of constructed context tags. Note
the absence of a principalName alternative.
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.
TrustedCas ::= CHOICE {
principalName [0] KerberosName,
caName [1] Name
issuerAndSerial [2] IssuerAndSerialNumber OPTIONAL
}
(OPTIONAL is not syntactically valid ASN.1 within a CHOICE, so let's
ignore that.) Per this spec, each alternative should consist of an
explicit context-specific tag followed by the encoding of the specified
object.
Our encoder for this type generates a primitive context tag for all
three alternatives, as if they were wrapped in IMPLICIT OCTET STRING.
Also, for the principalName alternative, it encodes an RFC 4120
PrincipalName instead of a KerberosName as defined by PKINIT (as a
sequence containing a [0] Realm and a [1] PrincipalName).
Our decoder for this type does not care whether the context tags are
primitive or constructed. It expects a KerberosName for the
principalName alternative, which matches the spec but not the encoder.
It grabs whatever is inside the context-specific tag for the other two
alternatives, so should correctly process either a spec-compliant or
encoder-generated caName or issuerAndSerial.
For reference, Heimdal defines its version of the type as:
TrustedCA-Win2k ::= CHOICE {
caName [1] heim_any,
isuerAndSerial [2] IssuerAndSerialNumber
}
which presumably results in the use of constructed context tags. Note
the absence of a principalName alternative.
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.