It turned out that early in the development cycle, one of our developers
picked the "next" PADATA type in krb5.hin, and we said, "We've got to
fix that when we get the real one assigned" ... and we never did. Noticed
by Ezra Peisach.
Also, the definition for sam-pk-for-sad was changed to OCTET STRING from
EncryptionKey in the draft and the code, but we never updated the ASN.1
definition. Also noticed by Ezra Peisach.
ticket: new
git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@14945
dc483132-0cff-0310-8789-
dd5450dbe970
+2002-10-30 Ken Hornstein <kenh@cmf.nrl.navy.mil>
+
+ * krb5.hin: Change definitions of new SAM preauth types to
+ match kerberos-clarifications.
+
2002-10-24 Ken Hornstein <kenh@cmf.nrl.navy.mil>
* k5-int.h, krb5.hin: Add new protocols, definitions, and
#define KRB5_PADATA_ETYPE_INFO 11 /* Etype info for preauth */
#define KRB5_PADATA_SAM_CHALLENGE 12 /* draft challenge system */
#define KRB5_PADATA_SAM_RESPONSE 13 /* draft challenge system response */
-#define KRB5_PADATA_SAM_CHALLENGE_2 14 /* draft challenge system, updated */
-#define KRB5_PADATA_SAM_RESPONSE_2 15 /* draft challenge system, updated */
+#define KRB5_PADATA_PK_AS_REQ 14 /* PKINIT */
+#define KRB5_PADATA_PK_AS_REP 15 /* PKINIT */
+
+#define KRB5_PADATA_SAM_CHALLENGE_2 30 /* draft challenge system, updated */
+#define KRB5_PADATA_SAM_RESPONSE_2 31 /* draft challenge system, updated */
#define KRB5_SAM_USE_SAD_AS_KEY 0x80000000
#define KRB5_SAM_SEND_ENCRYPTED_SAD 0x40000000
+2002-10-30 Ken Hornstein <kenh@cmf.nrl.navy.mil>
+
+ * KRB5-asn.py: Fix definition for sam-pk-for-sad element.
+
2002-10-24 Ken Hornstein <kenh@cmf.nrl.navy.mil>
* KRB5-asn.py, asn1_k_decode.c, asn1_k_decode.h, asn1_k_encode.c,
sam-challenge-label[4] GeneralString OPTIONAL,
sam-challenge[5] GeneralString OPTIONAL,
sam-response-prompt[6] GeneralString OPTIONAL,
- sam-pk-for-sad[7] EncryptionKey OPTIONAL,
+ sam-pk-for-sad[7] OCTET STRING OPTIONAL,
sam-nonce[8] INTEGER OPTIONAL,
sam-cksum[9] Checksum OPTIONAL
}