Subject: | PKINIT pk_as_rep_draft9 encoding issues |
draft-ietf-cat-kerberos-pk-init-09 defines PA-PK-AS-REP as:
PA-PK-AS-REP ::= CHOICE {
dhSignedData [0] SignedData,
encKeyPack [1] EnvelopedData,
}
Per this spec, each alternative should consist of a constructed context-
specific tag followed by the encoding of SignedData or EnvelopeData as
defined by RFC 2630.
Our encoder for this type generates primitive context tags for both
alternatives, as if the CMS types 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 is not consistent with our encoder or with the spec. For
both alternatives, it expects a sequence tag containing a constructed
context tag containing an octet string tag containing the encoding of
the CMS type. It seems unlikely that this decoder interoperates with
any implementation.
For reference, Heimdal defines its version of the type as:
PA-PK-AS-REP-Win2k ::= CHOICE {
dhSignedData [0] IMPLICIT OCTET STRING,
encKeyPack [1] IMPLICIT OCTET STRING
}
which is consistent with our encoder.
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.
PA-PK-AS-REP ::= CHOICE {
dhSignedData [0] SignedData,
encKeyPack [1] EnvelopedData,
}
Per this spec, each alternative should consist of a constructed context-
specific tag followed by the encoding of SignedData or EnvelopeData as
defined by RFC 2630.
Our encoder for this type generates primitive context tags for both
alternatives, as if the CMS types 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 is not consistent with our encoder or with the spec. For
both alternatives, it expects a sequence tag containing a constructed
context tag containing an octet string tag containing the encoding of
the CMS type. It seems unlikely that this decoder interoperates with
any implementation.
For reference, Heimdal defines its version of the type as:
PA-PK-AS-REP-Win2k ::= CHOICE {
dhSignedData [0] IMPLICIT OCTET STRING,
encKeyPack [1] IMPLICIT OCTET STRING
}
which is consistent with our encoder.
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.