Skip Menu |

Subject: PKINIT trusted_ca encoding issues
Download (untitled) / with headers
text/plain 1.6KiB
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

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.
As noted in issue #7062, the PKINIT client code never encodes a TrustedCas
value as part of a draft9 PA-PK-AS-REQ. So making changes to the encoder
should not affect interop.

The PKINIT server code does potentially decode a TrustedCas value when
decoding a draft9 PA-PK-AS-REQ (if Win2k clients ever send them).
However, it does nothing with this field during processing.