Subject: Additional comments re PKINIT-07

From: "Linn, John" <[email-masked]>
Date: Thu, 19 Nov 1998 16:58:22 -0500

I've some further comments and questions about PKINIT-07, beyond the
question posted earlier as to whether there are dependencies on, or
incompatibilities with, anticipated changes in kerberos-revisions relative
to RFC-1510.

Per discussion on the list on 17-18 August, I believe that the references
(e.g., in Sec. 3.2) to using PKCS #6 as a means towards PKIX alignment
should be expunged.  PKIX certificates are X.509v3, which is already covered
by another case in the certType definition, and PKCS #6 wasn't referenced in
PKIX.  

In the same discussion, I pointed out an identified cryptographic
vulnerability with use of pre-V2 PKCS #1 padding for encryption purposes,
which Matt Hur suggested could be addressed within a security considerations
note.  The current version of the CMS document (draft-ietf-smime-cms-08)
contains in its security considerations section a pair of paragraphs on this
topic, which could be adapted into PKINIT's security considerations section.
Alternately, PKINIT's section 3.1.2.3, where the RSAEncryption OID is
referenced, could reference RFC-2437 (the current V2 of PKCS #1, which
includes a padding mode resolving the vulnerability). 

Section 3.1.2.5 on rc2CBC parameters seems like a large body of material to
include within this spec; the same material is covered in section 6 of
RFC-2268 so can be referenced from there.  More generally, RFC-2268 may be a
better citation for RC2 description purposes than [13], given its easy
accessibility.  Similarly, PKCS #7 (V 1.5) can be cited as RFC-2315. 

The working proposal reported to the CAT session at the LA meeting was to
adopt portions of PKCS #7 within PKINIT, but not to incorporate PKCS #7 or
CMS by reference.  The current document is consistent with this approach,
noting, e.g., that "The EnvelopedKeyPack data type ... is similar to
EnvelopedData, defined in CMS [11] and PKCS #7 [12]".  For clarification
purposes, would it be feasible and useful to identify areas where the
adopted structure definitions diverge from RFC-2315, with associated
rationale?  

In the header and author listings, note that John Wray's current affiliation
is with Iris Associates. 

--jl
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]