Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10970; 1 Aug 94 18:56 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10966; 1 Aug 94 18:56 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa19569; 1 Aug 94 18:56 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma024393; Mon Aug 1 18:26:57 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa08762; 1 Aug 94 18:16 EDT Received: from sol.tis.com by magellan.TIS.COM id aa08758; 1 Aug 94 18:13 EDT Message-Id: <9408011758.AA20330@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma020322; Mon Aug 1 13:57:51 1994 To: minutes@CNRI.Reston.VA.US Cc: pem-dev@tis.com Subject: meeting minutes Date: Mon, 01 Aug 94 13:51:10 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent PEM WG Meeting at the Toronto IETF (7/26/94) The major focus of this meeting was review of two very recent Internet Drafts: "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted," and "PEM Security Services and MIME." Presentations on both I-Ds were made by Jim Galvin, who is a co- author on both documents. The first I-D, defines two multipart content types: one for use when encrypting body parts, and one for use when signing body parts. The intent is that these generic multipart content types can then be customized for use with different security protocols that would operate in the MIME environment, not just PEM. For each such protocol, a separate RFC will be required to specify the details of how that protocol makes use of these basic context types. The current form of this I-D also contains brief specifications for two control body parts, one for keys and one for signature information. However, the authors concluded that these body parts proved to be insufficiently general to be included in this I-D, and thus they will part of the protocol- specific documents. Most of the discussion centered on the second ID, that provides a PEM specification of how to employ the encryption and signature content types. The discussion highlighted major differences between the previous draft and the current draft: - MIME headers are included in the signature, to be consistent with the inclusion of headers in encrypted contents. - The hash algorithm ID is included in the header of the (signed) data body part to facilitate one-pass processing of signed messages, but the rest of the signature data is retained in the control body part to make display of signed but not encrypted data easy for non-PEM users. - To retain an ability for non-PEM users to read signed messages, and to avoid the canonicalization problems that have plagued previous attempts at PEM-MIME integration, this I-D calls for 7bit encoding for all data that is signed. There is an additional requirement for canonical line delineation, and this is addressed by requiring use of CRLF for computation of the signature hash value, although the CRLF transformed body part is not transmitted. Instead, recipients are required to re-encode received, signed body parts to this format when checking the hash. There is general agreement that this is a painful approach (e.g., it will entail multiple encodings when a message is both signed and encrypted), but it is only means developed so far to address the canonicalization problem in a fashion that is consistent with existing MIME conventions. There also was agreement that additional details are required to completely nail down the canonicalization step, e.g., conventions for representation of tabs. - A question was raised as to whether the complexity of the resulting system is worthwhile, e.g., relative to the simpler proposal put forth over 6 months ago by Jeff Schiller. The approached in the current I-Ds allows for recursive application of PEM processing, but does not include syntax for semantics such as serial vs. parallel signatures. There was no substantive discussion on this question. - The current I-D does not include support for symmetric key management, unlike RFC 1421. The rationale provided for dropping this facility was a lack of implementations including this facility. It was observed, however, that many of the independent implementations (if not the more widely distributed TIS implementation) have included symmetric key management support and that these implementations have bootstrapped interoperability testing using that form of key management. Nonetheless, the PEM RFCs have clearly expressed a strong preference for public-key key management, and no RFC comparable to 1422 has been published for symmetric key management. However, an I-D for use of PEM with X9.17 key management, for support of authenticated (not encrypted) messaging, is in preparation, as a result of interest from a member of the banking community. (X9.17 is an ANSI standard, and there is a corresponding Federal Information Processing Standard, for DES key management in the wholesale financial banking community. However, one attendee question whether the banking community had a substantial X9.17 infrastructure in place.) It was suggested that it may suffice to revise 1421 to accommodate this requested change, not propagating it to MIME-PEM. - There was extensive discussion of the "name form" and "key identifier" concepts presented in the new I-D. It was observed that some public-key certificates provide key identifiers that do not fit the model presented in this I-D and that the model proposed in this I-D required a much less efficient representation for such an identifier than is necessary in some cases. - It was suggested that the syntactic requirements for originator and recipient asymmetric key management IDs need not be identical, as is reflected in the current PEM RFC (1421). The originator ID is used to convey information needed to select the public-key used by an originator to sign a message and to identity the originator. This selection may involve directory access, or may be satisfied directly by conveying the originator's certificate in the message header (an identification option not accommodated by the proposed syntax). For some encryption algorithms, there is also a need to convey per-message parameters for decryption; such parameters properly belong in the "keys" body part but not necessarily as part of the originator- ID. In contrast, a recipient ID is used by a recipient to select the token in the message header that matches a private key held by the recipient. A recipient may hold multiple sets of keying material, either under different identities (including mail list identities), or serially under the same identity. So the recipient ID may be viewed as a means of selecting the proper private key among those available to the recipient. This argument suggests that requiring an identical format for both originator and recipient key identifiers may be inappropriate. - The "TYPE-KEYID-STRING" syntax was criticized as an attempt to over generalize the concepts here, since (as noted above) not all legitimate approaches to providing key selectors fit the mold very well. The "IS" construct already deviates from the general model somewhat, and the DN part of the that construct is not the same DN as in the "DN" construct, which could lead to some confusion. (In the latter case, the distinguished name is that of the issuer of a certificate, whereas in the former case it is the distinguished name of the user.) As noted earlier, there are much more efficient key identifier constructs for some algorithms and certificates that also don't fit this model. - Discussion of the "STR" construct strongly suggested that it should be renamed "DS" for "domain specific," and that an explicit domain identifier (registered with the IANA) should be employed to avoid the ambiguity inherent in any domain- specific identifier form. There also was a suggestion that the US-ASCII restriction, which is present because of MIME encoding concerns, be relaxed to 7bit and that a field be included to indicate (explicitly) the "native" character set of this string if it was encoded. - There was some discussion about the rationale for inclusion of the PGP2 construct here. It was observed that PGP can be carried by MIME using the constructs defined in the companion I-D. One possible explanation is that one may make use of the PGP key management and thus this field should be present. Alternatively, the inclusion of this key identifier format may pave the way for a migration of PGP users to a common format with PEM. It was suggested that these, and/or other rationales, be explicitly included in the I-D text. - It was noted that the format for use of email addresses as user names (EN) does not have an accompanying certificate format defined. The rationale for not using X.509 certificates is that the use of email names as distinguished names is incompatible with most X.500 directory schema conventions, even though it is syntactically feasible. One of the I-D authors indicated that use of signed body parts as certificates was a possible remedy for this situation, but no mention of this approach is cited in the I-D. - It was observed that the statement in the ID that calls for different certificates for signature and key management public keys is not strictly required, and is incompatible with X.509 certificates that combine both. This latter approach is more efficient than requiring duplication of most of the certificate format just to change the SubjectPublicKeyInfo field. - It also was observed that the syntax in the I-D mixes certificates and CRLs in certificate lists, while there also a separate CRL list construct. It was suggested that the certificate list construct be simplified to eliminate CRLs, maintaining them only in the latter, more appropriately named data structure. This would require changing the processing description of the latter structure, which describes it as being used only for returning CRLs in response to requests, as opposed to being provided unilaterally by a message originator. In general, a concern was voiced by several attendees about possible combinatoric explosion of options adversely affecting interoperability of the resulting protocol. There also was a suggestion by the chair that these I-Ds should be viewed only as defining the use of PEM with MIME, not as supplanting RFC 1421, which defines the use of PEM with non-MIME messages. This approach would retain RFC 1424 (which the "PEM for MIME" I-D calls for making obsolete) and would also require that the new PEM-MIME I-D be more self-contained, i.e., not expressed as changes relative to 1421.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09955; 2 Aug 94 13:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09951; 2 Aug 94 13:18 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa11504; 2 Aug 94 13:18 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smab07202; Tue Aug 2 13:08:34 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa00883; 2 Aug 94 13:05 EDT Received: from sol.tis.com by magellan.TIS.COM id aa00879; 2 Aug 94 13:02 EDT Received: from uu4.psi.com(38.146.21.2) by relay via smap (V1.3) id sma007070; Tue Aug 2 13:03:10 1994 Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA26631 for ; Tue, 2 Aug 94 12:40:57 -0400 Received: from cc:Mail by uu0892.spyrus.com id AA775844985 Tue, 02 Aug 94 09:29:45 Date: Tue, 02 Aug 94 09:29:45 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Housley, Russ" Encoding: 1249 Text Message-Id: <9407027758.AA775844985@uu0892.spyrus.com> To: galvin@tis.com, sandy@tis.com, crocker@tis.com, ned@innosoft.com Cc: pem-dev@tis.com Subject: Comment on draft-ietf-pem-signenc-01.txt Dear Authors: The ID defines two MIME content types: multipart/signed and multipart/encrypted. At this time, I do not wish to make any comments about the definition of these content types, rather I wish to comment on the lack of any statement about the relationship of these two content types. I assume that a MIME message body can be both signed and encrypted by applying both multipart/signed and multipart/encrypted. First, I think that this should be stated explicitly. Second, the order of the encapsulation is very important. In general, the didital signature should be applied before encryption. If the message is signed before it is encrypted, then the signed MIME message body can be forwarded to another recipient. However, if the the message is encrypted before it is signed, then forwarding signed MIME message body to another recipient is not sufficient for that user to process the message; the user should not have the keys to decrypt the signed ciphertext. While there might be some esoteric cases where the ciphertext MIME message body should be signed, I do ot believe that this is the normal case. I suggest that a section be added to the ID which details this relationship. Russ   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11113; 2 Aug 94 14:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11109; 2 Aug 94 14:38 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa13319; 2 Aug 94 14:38 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma008993; Tue Aug 2 14:27:06 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa01190; 2 Aug 94 14:14 EDT Received: from sol.tis.com by magellan.TIS.COM id aa01186; 2 Aug 94 14:11 EDT Message-Id: <9408021811.AA08470@relay.tis.com> Received: from atlas.arc.nasa.gov(128.102.17.47) by relay via smap (V1.3) id sma008464; Tue Aug 2 14:11:44 1994 Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Tue, 2 Aug 1994 11:11:22 -0700 Cc: pem-dev@tis.com Subject: Re: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message of "Tue, 02 Aug 1994 09:29:45." <9407027758.AA775844985@uu0892.spyrus.com> Date: Tue, 02 Aug 1994 11:11:19 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Williams >From: "Housley, Russ" >Subject: Comment on draft-ietf-pem-signenc-01.txt >Date: Tue, 02 Aug 94 09:29:45 >While there might be some esoteric cases where the ciphertext MIME message >body should be signed, I do ot believe that this is the normal case. I >suggest that a section be added to the ID which details this relationship. > >Russ It depends upon the nature of the element of service one is trying to provide, surely: message origin authentication (a service TIS folk believe is that demanded by the PEM-like market) may certainly be provided by signing the encrypted content, though this mechanism would thereby not entail provision of the non-repudiation of message content element of service, thereby. This is the stumbling point PEM has traditionally not sumounted, until perhaps quite recently; many believe that disassociating non-repudiation from authentication to be a key to actual PEM deployment (when used in support of its non-privacy-related authentication services), both for key distribution, and secure messaging services. And so, all credit to the authors for bring all the discussion to the point of concrete specification. It is generally true that the new I-D requires a detailed statement of the security services it pretends to provide, though, and the creation of a rationale framework which enables one to ensure that protocol/security-mechanism interactions are always state-safe wrt to the specific and well-defined (or referenced) secure elements of service being claimed. This would clear up many of the ambiguities of the statement of design. The current I-D comes across as something designed bottom-up to take advantage of technological innovations and available MIME deployment which might make the practice of secure e-mail more likely to be taken up by the (growing) MIME user-base. The design concept does seem based upon a philosophical belief of what the market requires, and addresses a belief of what has held up deployment to date; yet, intellectually, and in terms of security, it is indeed hard to know what you actually have in terms of security offerings, at the end of the day. (I know Russ, you dont think much of trusted agent security designs. But, MOA signatures computed by the MTA switch (without complex crypto, albeit), over potentially-encrypted content are actually being used between commercial VANs to perform charging and settlement. Of course this has nothing to do with the VAN users. Not does it have much to do with privacy or confidentiality. but there is more to commercial provider-based message switching than just the users.)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13776; 2 Aug 94 16:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13772; 2 Aug 94 16:54 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa16745; 2 Aug 94 16:54 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa11976; Tue Aug 2 16:42:15 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa02441; 2 Aug 94 16:41 EDT Received: from sol.tis.com by magellan.TIS.COM id aa02436; 2 Aug 94 16:38 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma011899; Tue Aug 2 16:38:52 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA25566; Tue, 2 Aug 94 16:38:07 EDT Message-Id: <9408022038.AA25566@tis.com> Reply-To: James M Galvin To: Jeff Thompson Cc: pem-dev@tis.com Subject: Re: PEM and MIME documents In-Reply-To: 's message of Sat, 30 Jul 1994 19:39:43 PDT. <199407310239.TAA06336@netcom11.netcom.com> Date: Tue, 02 Aug 1994 16:38:09 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin According to the current PEM/MIME what is the recommended interaction between a user and a PCA for getting the latest CRL? In RFC 1424, I would compose a CRL-RETRIEVAL-REQUEST with the Issuer: field set to the issuer's name. But the for the application/key-request has no "DN only" form like this. How would I request the CRL for the TIS PCA, for example? What you would do is send an application/key-request message with the Issuer field only to set to an appropriate value. For example, Content-Type: application/key-request Issuer: DN, , An obvious question to ask is, "what do I set to, since it must be non-null?" The answer is that you use the key identifier for the public key of the issuer identified by the distinguished name specified in the ISSUER field that signed the CRL you wish to retrieve. Boy is that a mouthful. Keep in mind that an issuer may have multiple public keys, perhaps one for each of the "many" algorithms it supports. Thus, an issuer may have multiple CRLs that it issues, one for each public key. I agree that if an issuer (or any user for that matter) has exactly one public key then the inclusion of the key identifier is superfluous. However, in order to guarantee forward compatibility with the future existence of multiple keys, it is best to require it. Jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14324; 2 Aug 94 17:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14320; 2 Aug 94 17:37 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa17636; 2 Aug 94 17:37 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma012928; Tue Aug 2 17:27:29 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa02764; 2 Aug 94 17:23 EDT Received: from sol.tis.com by magellan.TIS.COM id aa02760; 2 Aug 94 17:21 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma012787; Tue Aug 2 17:21:52 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA28321; Tue, 2 Aug 94 17:21:06 EDT Message-Id: <9408022121.AA28321@tis.com> Reply-To: James M Galvin To: Steve Kent Cc: minutes@CNRI.Reston.VA.US, pem-dev@tis.com Subject: Re: meeting minutes In-Reply-To: Steve Kent's message of Mon, 01 Aug 1994 13:51:10 EDT. <9408011758.AA20330@relay.tis.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa0" Date: Tue, 02 Aug 1994 17:21:09 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1548.775862444.2@tis.com> I have a couple of corrections to the minutes. The first I-D, defines two multipart content types: one for use when encrypting body parts, and one for use when signing body parts. The intent is that these generic multipart content types can then be customized for use with different security protocols that would operate in the MIME environment, not just PEM. ... However, the authors concluded that these body parts proved to be insufficiently general to be included in this I-D, and thus they will part of the protocol- specific documents. Actually, the authors concluded that the movement of application/signature and application/keys body parts from the multipart document to the PEM-MIME document was purely administrative/editorial. The issue was the use of the protocol parameter on the multipart header required yet another table of values that implementations needed knowledge of and had to be maintained by IANA. Discussions with other MIME experts caused us to realize that the information being conveyed by the value of the protocol parameter could just as easily be conveyed by having protocol specific content types for the control information. Thus, instead of using "protocol=pem" on the multipart header and a generic control information content type of "application/signature", we would use "application/pem-signature" on the control information content type and use "control=application/pem-signature" on the multipart header. The latter parameter is still required in support of one-pass processing. Note that it differs substantially from the "protocol=XXX" by not requiring a new table to be maintained. This is because the "MIME specification" would state that the value is a content type, which already has a well-defined grammar specification and existing tables. This was believed to be a "win-win" change that in no way changes the technical aspects of the specification. - It was suggested that the syntactic requirements for originator and recipient asymmetric key management IDs need not be identical, as is reflected in the current PEM RFC (1421). The originator ID is used to convey information needed to select the public-key used by an originator to sign a message and to identity the originator. This selection may involve directory access, or may be satisfied directly by conveying the originator's certificate in the message header (an identification option not accommodated by the proposed syntax). Actually, it is accommodated by the proposed syntax, since all that is required is for an originator to include an "application/key-data" content in the message with the "multipart/signed" content. We believe that the most common usage will be for originators to indicate pointers to the correct public/private keys that were used. Thus, we optimized the PEM services syntax for this. However, there is the problem of conveying the certificates the first time. This accommodated by the definition of the application/key-data content type and MIME accommodates its inclusion with a signed content type in a straightforward way. Jim ------- =_aaaaaaaaaa0 Content-Type: application/signature Content-ID: <1548.775862444.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,XWnCiKaalp9MVD7s3CkRJy6vs5M2V/SkiXJLnLh0TkXQSNJVvkO8= psoHscuXST1obUOFf1KnGI0FLV2bDFMV7V4V1iWbeKZxtRSnfOPG9gqMvIZfq5PVMDdQmbjnRM= DO ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15030; 2 Aug 94 18:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15026; 2 Aug 94 18:51 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa19211; 2 Aug 94 18:51 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma013884; Tue Aug 2 18:44:12 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa02860; 2 Aug 94 18:41 EDT Received: from sol.tis.com by magellan.TIS.COM id aa02856; 2 Aug 94 18:39 EDT Message-Id: <9408022239.AA13831@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma013821; Tue Aug 2 18:39:21 1994 To: James M Galvin Cc: minutes@CNRI.Reston.VA.US, pem-dev@tis.com Subject: Re: meeting minutes In-Reply-To: Your message of Tue, 02 Aug 94 17:21:09 -0400. <9408022121.AA28321@tis.com> Date: Tue, 02 Aug 94 18:36:25 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent Jim, I accept the rationale you provided re why the authors of the first ID elected to move the definition of the keys and signature control body parts out of the first ID, but I maintain that my characterization of why they should be moved is valid. I question the utility of establishing control body part definitions that are so generic as to embody almost no syntactic or semantic constraints. However, if such a construct turns out not to be really generic, then it clearly belongs in the document that defines the more detailed syntax for a specific application. That was my interpretation of a good reason for moving the body part definitions in question, though I defer to your explanation for the author's rationale and I agree that the minutes should be amended to reflect that author's rationale for this proposed change. As for the generality of originator and recipient IDs, I think we disagree again. Here, the second I-D specifies a generic format for both IDs and gives the impression that the generic character is intended to unify expression of both forms of ID. My notes point out reasons why this may be an inapporpriate generalization. While I agree with your observation that one can fnd the necessary constructs in the I-Ds to transfer all of the requisite information, there was no argument, no supporting rationale, that a particular mode of use would be more common than another, and thus the design should be optimized on that basis. I don't necessarily agree with the suggestion that the transmission of one or more certificates will be the rare case, as that may require too much state or too much thought by originators, especially for messages sent to multiple recipients. My point about the different requirements for both forms of ID still stand. Since the minutes characterize this point as a suggestion made by a WG attendee, I think the minutes are accurate in that regard and should not be amended. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07606; 3 Aug 94 12:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07601; 3 Aug 94 12:26 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa10155; 3 Aug 94 12:26 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma023840; Wed Aug 3 12:14:43 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa04225; 3 Aug 94 12:04 EDT Received: from sol.tis.com by magellan.TIS.COM id aa04221; 3 Aug 94 11:59 EDT Received: from uu4.psi.com(38.146.21.2) by relay via smap (V1.3) id sma022772; Wed Aug 3 11:03:51 1994 Received: by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA09453 for ; Wed, 3 Aug 94 10:40:35 -0400 Received: from cc:Mail by uu0892.spyrus.com id AA775923847 Wed, 03 Aug 94 07:24:07 Date: Wed, 03 Aug 94 07:24:07 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Housley, Russ" Encoding: 1256 Text Message-Id: <9407037759.AA775923847@uu0892.spyrus.com> To: Peter Williams Cc: pem-dev@tis.com Subject: Re[2]: Comment on draft-ietf-pem-signenc-01.txt Peter: > ... all credit to the authors for bring all the discussion to > the point of concrete specification. I agree. Based on your comments, we both agree that the I-D should describe the security services that are provided by each MIME-PEM content type. I think that the I-D should also describe the security services that are provided by the possible combinations. In my opinion, few users will care about the services offered by signed ciphertext. > (I know Russ, you don't think much of trusted agent security > designs. But, MOA signatures computed by the MTA switch (without > complex crypto, albeit), over potentially-encrypted content are > actually being used between commercial VANs to perform charging > and settlement. Of course this has nothing to do with the VAN > users. Not does it have much to do with privacy or confidentiality. > but there is more to commercial provider-based message switching > than just the users.) Peter, I understand this scenario, but I think that MIME-PEM would not be well suited to this task. The VAN operator would rather have a mechanism that signed the whole content. RFC1421 PEM is better suited to this task because it always protects the whole content. Russ   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04199; 4 Aug 94 10:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04191; 4 Aug 94 10:25 EDT Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa05257; 4 Aug 94 10:25 EDT Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP id ; Thu, 4 Aug 1994 10:07:01 -0400 Received: from pad-thai.aktis.com by MIT.EDU with SMTP id AA26071; Thu, 4 Aug 94 10:05:35 EDT Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP id ; Thu, 4 Aug 1994 10:06:41 -0400 Received: by winkl.aktis.com (4.1/4.7) id AA09817; Thu, 4 Aug 94 10:06:40 EDT Message-Id: <9408041406.AA09817@winkl.aktis.com> To: cat-ietf@mit.edu, pem-dev@tis.com Cc: linn@cam.ov.com, gomberg@gateway.mitre.org Subject: GSS-API extensions for store-and-forward support Date: Thu, 04 Aug 1994 10:06:39 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Linn CAT list members have already seen the attached, excerpted from an ongoing discussion we've been having in response to a informal liaison request from Dave Gomberg on behalf of ISO/IEC JTC 1/SC21 WG8, who are looking to incorporate or define store-and-forward messaging API primitives for use in conjunction with GSS-API. Several people have commented with interest and belief that such a definition would be a Good and Reasonable Thing. I'm sending this to pem-dev as well in the interest of informing potentially-interested participants who haven't previously been involved with GSS-API, and of surveying the likely pool of volunteers who might be interested in drafting a spec. I'd envision the appropriate spec as being a standalone document referencing GSS-API, probably accepting GSS-API credentials (rather than security contexts) as input to the protect/unprotect primitives for store-and forward messaging. For mechanisms capable of supporting both on-line, association-oriented and store-and-forward services, this would facilitate access to both with a single login. Comments? Interest? --jl ------- Forwarded Message Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP id ; Wed, 3 Aug 1994 08:16:54 -0400 Received: by winkl.aktis.com (4.1/4.7) id AA09176; Wed, 3 Aug 94 08:16:51 EDT Message-Id: <9408031216.AA09176@winkl.aktis.com> To: tytso@MIT.EDU (Theodore Ts'o) Cc: p.v.mcmahon.rea0803@oasis.icl.co.uk, vipin.samar@eng.sun.com, cat-ietf@MIT.EDU, linn@cam.ov.com Subject: Re: Query re work on GSS-API extensions for store-and-fwd support In-Reply-To: Your message of "Tue, 02 Aug 1994 22:52:31 EDT." <9408030252.AA03428@tsx-11.MIT.EDU> Date: Wed, 03 Aug 1994 08:16:50 -0400 From: John Linn Piers and Ted write: > From: p.v.mcmahon.rea0803@oasis.icl.co.uk > Date: Tue, 2 Aug 94 23:10:08 BST > Reply-To: p.v.mcmahon.rea0803@oasis.icl.co.uk > > I too think that such an interface would be a good thing. But, being > devil's advocate, what Internet applications would be potential > consumers of such APIs? While EDI and email are two obvious candidates, > doesn't the existence of existing specifications and/or implementations of > store-and-forward security embedded within such applications (PEM, PGP, > X.402, EDIFACT, Pedi etc) limit the motivation for introduction of a > new generic, and possibly non-interoperable, paradigm for implementing > the same services? > >Well, a generic API that defined how to take a blob of data and creating >a PEM or PGP encrypted (and possibly ASCII armored) message would be >quite useful. I don't think this would necessarily be a new, >non-interoperable paradigm, since there generally isn't a commonly used >API in use now for these services that's callable from other programs. >(Right now, there's just a command-line interface for PEM and PGP.) > >I'm assuming here that the packet formats of PEM, PGP, etc. would not >change under this new API. Clearly, introducing non-interoperability is a non-useful thing. This implies to me that messaging support primitives would want to accept input selector parameters to prescribe which of a set of already-defined encapsulation formats (e.g., PEM, PGP, PEM-MIME, ...) they're to output or process as input. Each of these formats would correspond (loosely) to a GSS-API mechanism, and this seems to me like a useful means to construct messaging toolkits allowing applications to use multiple protection formats. We appear to have consensus that S&F GSS-API extensions would be a useful idea; now, we need to decide if and how to progress this as a work item. Ted, Piers: would it be OK with you if I forwarded this message to the pem-dev list, as a vehicle to involve interested members of the PEM development community who may not previously have been concerned with GSS-API? - --jl ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06066; 4 Aug 94 12:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06062; 4 Aug 94 12:00 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa08062; 4 Aug 94 12:00 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma011565; Thu Aug 4 11:45:24 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa07343; 4 Aug 94 11:42 EDT Received: from sol.tis.com by magellan.TIS.COM id aa07316; 4 Aug 94 11:38 EDT Received: from thor.innosoft.com(192.160.253.66) by relay via smap (V1.3) id sma011441; Thu Aug 4 11:38:15 1994 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-9 #1234) id <01HFH7QSU10W9KM0D9@INNOSOFT.COM>; Thu, 04 Aug 1994 08:37:46 -0700 (PDT) Date: Thu, 04 Aug 1994 08:22:46 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message dated "Wed, 03 Aug 1994 07:24:07 +0000" <9407037759.AA775923847@uu0892.spyrus.com> To: "Housley, Russ" Cc: Peter Williams , pem-dev@tis.com Message-Id: <01HFI74J6B7U9KM0D9@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > > ... all credit to the authors for bring all the discussion to > > the point of concrete specification. > I agree. Based on your comments, we both agree that the I-D should > describe the security services that are provided by each MIME-PEM content > type. I think that the I-D should also describe the security services that > are provided by the possible combinations. In my opinion, few users will > care about the services offered by signed ciphertext. Describing all the possible service combinations is a nice idea, but it is also intrinsicly impossible to do. Both of these security services are building blocks that can be combined in arbitrary ways with quite a few other MIME services. (A set that is guaranteed to grow over time.) The result is a combinatorial explosion of service combinations. And while some combinations may not make any sense, there are certainly many others that do which we haven't thought of yet. There is a very real danger that in attempting to enumerate all the combinations that make sense we'll condemn by implication some useful combination of services we didn't think of and didn't document. I've seen this happen as a result of overenthusiastic enumeration attempts in specifications several times now. As such, which I completely agree that the provided services need to be fully described, I also think that that attempting to document combinations is very risky and probably more of a disservice than a service. A few demonstrably useful ones can be documented if need be, and preferably in some ancillary informational document, but it needs to be clear that other combinations are possible. > > (I know Russ, you don't think much of trusted agent security > > designs. But, MOA signatures computed by the MTA switch (without > > complex crypto, albeit), over potentially-encrypted content are > > actually being used between commercial VANs to perform charging > > and settlement. Of course this has nothing to do with the VAN > > users. Not does it have much to do with privacy or confidentiality. > > but there is more to commercial provider-based message switching > > than just the users.) > Peter, I understand this scenario, but I think that MIME-PEM would not be > well suited to this task. The VAN operator would rather have a mechanism > that signed the whole content. RFC1421 PEM is better suited to this task > because it always protects the whole content. I disagree. First of all, there is nothing that says that RFC1421 always protects the entire content. Second, MIME-PEM can be used to protect not only the entire content but also the outermost message headers, making it a superior service in this regard. Third, the price you pay for using RFC1421 is the loss of content labelling. In many cases this is too high a price to pay. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08805; 4 Aug 94 14:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08800; 4 Aug 94 14:27 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa10991; 4 Aug 94 14:27 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma014097; Thu Aug 4 14:15:36 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa07704; 4 Aug 94 14:09 EDT Received: from sol.tis.com by magellan.TIS.COM id aa07700; 4 Aug 94 14:06 EDT Message-Id: <9408041807.AA13957@relay.tis.com> Received: from atlas.arc.nasa.gov(128.102.17.47) by relay via smap (V1.3) id sma013955; Thu Aug 4 14:07:03 1994 Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Thu, 4 Aug 1994 11:06:36 -0700 To: pem-dev@tis.com Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message of "Thu, 04 Aug 1994 08:22:46 PDT." <01HFI74J6B7U9KM0D9@INNOSOFT.COM> Date: Thu, 04 Aug 1994 11:06:34 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Williams >From: Ned Freed >Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt >Date: Thu, 04 Aug 1994 08:22:46 -0700 (PDT) >As such, which I completely agree that the provided services need to be fully >described, I also think that that attempting to document combinations is very >risky and probably more of a disservice than a service. A few demonstrably >useful ones can be documented if need be, and preferably in some ancillary >informational document, but it needs to be clear that other combinations are >possible. Its even worse than you may realize. Not only must one document the specific security services properties, and demonstrate that the that the various mechanisms do not collide in the provision of the claimed service, but one must phrase the specification in terms of assurance evaluation criteria, even for the lower levels of such classification systems, at least when producing products likely to be recogised by the professional security and banking industry. Choosing, for example, between a design for a large miltary messaging system, based, on open technology, where technical material supporting one technical bid spec. has such a documentation format, and another does not, would be a big factor in eliminating technical bids, I would judge. Who wants to buy a design which refuses to make claim of what it does, and what it does not, and what it is designed and built to not do?! >I disagree. First of all, there is nothing that says that RFC1421 always >protects the entire content. Second, MIME-PEM can be used to protect not only >the entire content but also the outermost message headers, making it a superior >service in this regard. Third, the price you pay for using RFC1421 is the loss >of content labelling. In many cases this is too high a price to pay. > Ned Such a superiority argument is not particularly valid when when cannot judge its rationale against the objective it purports to support. However I recognise its subjective emotional appeal. A communications security design which require protection of such addressing information can easily be attacked on the difficulty which such designs make of operating such protected systems in a massive, open technnology communities involving many nations (as with NATO), international comms treaties, GATT tarrifing, n generations of technology, ... but, then, thats not what we are doing here at the IETF, is it?! we need to concentrate on design enhancement for the privacy of Internet messages, for the community of research and educational Internet users. For the argument to stand as it stands now, it implies that the design objective of the existing PEM is not being satisfied by the protocol known as RFC 1421. And this implication itself, if true, would certainly be very significant. We should know find out from you what makes the original assertion true, Ned, remembering the scope of our activity. I do recognise that research aimed at providing connectionless security using messaging is an active subject. MIME-PEM is certainly a major on-going contribution to that R&D process.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15273; 4 Aug 94 20:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15269; 4 Aug 94 20:39 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa19259; 4 Aug 94 20:39 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma020074; Thu Aug 4 20:27:25 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa08169; 4 Aug 94 20:18 EDT Received: from sol.tis.com by magellan.TIS.COM id aa08165; 4 Aug 94 20:16 EDT Received: from sigurd.innosoft.com(192.160.253.70) by relay via smap (V1.3) id sma019980; Thu Aug 4 20:16:32 1994 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HFIFYDV4AO95MRFH@SIGURD.INNOSOFT.COM>; Thu, 04 Aug 1994 17:15:55 -0700 (PDT) Date: Thu, 04 Aug 1994 16:52:46 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message dated "Thu, 04 Aug 1994 11:06:34 -0700" <9408041807.AA13957@relay.tis.com> To: Peter Williams Cc: pem-dev@tis.com Message-Id: <01HFIP7Y4PXU95MRFH@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 7BIT > Choosing, for example, between a design for a large miltary messaging > system, based, on open technology, where technical material supporting > one technical bid spec. has such a documentation format, and another > does not, would be a big factor in eliminating technical bids, I would > judge. Who wants to buy a design which refuses to make claim of what it > does, and what it does not, and what it is designed and built to not do?! This level of description goes far beyond what these specifications can or should be doing. These are general facilities for applying security services to MIME messages. The properties of the result are far more dependent on the specific service being applied than on the encapsulation methodology used. > > I disagree. First of all, there is nothing that says that RFC1421 always > > protects the entire content. Second, MIME-PEM can be used to protect not only > > the entire content but also the outermost message headers, making it a superior > > service in this regard. Third, the price you pay for using RFC1421 is the loss > > of content labelling. In many cases this is too high a price to pay. > Such a superiority argument is not particularly valid when when cannot > judge its rationale against the objective it purports to support. I quite honestly have no idea what you are talking about here. > However I recognise its subjective emotional appeal. I'm sorry, but I see this as a purely technical matter. It is a fact that both encapsulation schemes can be used to secure the entire message content or only a part of it. It is therefore incorrect to see RFC1421 supposed inability to secure anything but the entire message as an advantage. This supposed inability and hence the enhanced security it purports to provide do not in fact exist. It is also a fact that RFC1421 services are not defined in a way that allows for protection of parts of the message header, whereas MIME-PEM can be used this way. It is also a fact that RFC1421 is not defined in a fashion that allows the secured content's format to be identified. These are not subjective issues. > A communications > security design which require protection of such addressing information > can easily be attacked on the difficulty which such designs make of > operating such protected systems in a massive, open technnology > communities involving many nations (as with NATO), international comms > treaties, GATT tarrifing, n generations of technology, ... but, then, > thats not what we are doing here at the IETF, is it?! Nobody has said a single word about securing addressing information until now. This information is part of the message envelope, not the header, and none of these scheme provide any means to secure the message envelope. (I realize that addressing information may appear in the message header, but there is little point in securing this material when the stuff that matters is elsewhere.) The purpose of securing headers is not to secure addressing information, which in fact is an exercise in futility, but instead to secure all the other information headers can contain. I thought this was all pretty obvious and hence not worth dwelling on. > we need to > concentrate on design enhancement for the privacy of Internet messages, > for the community of research and educational Internet users. I don't know where this comment comes from or why it is at all relevant, but I disagree with it. While the needs of research and educational users are very important, the needs of commercial users are also important and cannot be ignored. > For the argument to stand as it stands now, it implies that the design > objective of the existing PEM is not being satisfied by the protocol > known as RFC 1421. And this implication itself, if true, would certainly be > very significant. We should know find out from you what makes the original > assertion true, Ned, remembering the scope of our activity. I'm sorry, but all this is hopelessly out of scope. Recall that we were discussing whether or not the RFC1421 provides a superior service because of its supposed inability to secure anything other than an entire message. That's all we were discussing. I merely pointed out that this supposed inability does not in fact exist, making RFC1421 and MIME-PEM peers on this point, and that at least two other directly related factors could be seen as making MIME-PEM the superior choice in this extremely limited context. A general discussion of general utility of MIME-PEM and the inadequacies of RFC1421 is a much broader topic, involving a multitude of other issues we haven't even touched on here. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15517; 4 Aug 94 21:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15513; 4 Aug 94 21:15 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa19760; 4 Aug 94 21:15 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma020502; Thu Aug 4 21:07:35 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa08229; 4 Aug 94 20:59 EDT Received: from sol.tis.com by magellan.TIS.COM id aa08225; 4 Aug 94 20:58 EDT Received: from netcom14.netcom.com(192.100.81.126) by relay via smap (V1.3) id sma020405; Thu Aug 4 20:58:45 1994 Received: by netcom14.netcom.com (8.6.8.1/Netcom) id RAA19985; Thu, 4 Aug 1994 17:58:42 -0700 Date: Thu, 4 Aug 1994 17:58:42 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeff Thompson Message-Id: <199408050058.RAA19985@netcom14.netcom.com> To: galvin@tis.com Cc: pem-dev@tis.com In-Reply-To: <9408022038.AA25566@tis.com> (message from James M Galvin on Tue, 02 Aug 1994 16:38:09 -0400) Subject: Re: PEM and MIME documents > According to the current PEM/MIME what is the recommended > interaction between a user and a PCA for getting the latest CRL? > In RFC 1424, I would compose a CRL-RETRIEVAL-REQUEST with the > Issuer: field set to the issuer's name. But the for the > application/key-request has no "DN only" form like this. How > would I request the CRL for the TIS PCA, for example? > > What you would do is send an application/key-request message with the > Issuer field only to set to an appropriate value. For example, > > Content-Type: application/key-request > > Issuer: DN, , > > An obvious question to ask is, "what do I set to, since it must > be non-null?" > > The answer is that you use the key identifier for the public key of the > issuer identified by the distinguished name specified in the ISSUER > field that signed the CRL you wish to retrieve. Boy is that a mouthful. Let met ask this way: Suppose I receive a PEM/MIME signed message from someone and they also include an application/key-data with a . (And suppose the sender has not included the optional fields.) Where do I find the for the issuers to request the CRLs ? It is not in the . Am I missing an interchange that has to happen somewhere? - Jeff   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04653; 5 Aug 94 11:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04649; 5 Aug 94 11:09 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa08786; 5 Aug 94 11:09 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma025653; Fri Aug 5 10:58:44 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09181; 5 Aug 94 10:46 EDT Received: from sol.tis.com by magellan.TIS.COM id aa09177; 5 Aug 94 10:43 EDT Message-Id: <9408051443.AA25432@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma025423; Fri Aug 5 10:43:37 1994 To: Ned Freed Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt Cc: Peter Williams Cc: pem-dev@tis.com Date: Fri, 05 Aug 94 10:38:10 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent Ned, In a two messages recentlt you commented about the 1421 version of PEM not being restricted to protecting an entire message content. I don't think this is true in the most general sense, although there is room for confusion here. We did, at one time, experiment with partial context protection, but found it too complex in the vanilla (non-MIME) 822 context, so we dropped the facility. One can forward a 1421-PEM protected message, so there is some aspect of partial content protection, but certainly not nearly as felxible as what is being developed for MIME-PEM. Also, one can apply PEM to any text (or any data encoded into text format) in an offline fashion and then insert the result into a message, which would, indeed, yield a content with mixed PEM and non-PEM components. However, the general model for PEM when integrated with a UA is one in which the entire content is protected. Another reason we dropped the partial content protection, as a major feature, was that we were concerned about the ability of user agents to accurately represent to a user just what portions of a message were and were not protected, especially with regard to authenticated and integrity checked (but not encrypted) data. I think these concerns are still valid in the MIME-PEM context, and we just have to hope that user agents do a good enough job to prevent users from being spoofed. Perhaps this is one of the concerns Peter is alluding to. You also commented about the inability of PEM to identify the format of a secured content. We did include the Content-Domain construct as a hook for representing other than simple text messages as the protected content, though this is certainly not as flexible and general as the MIME facilities. In fact, the intent was to use this as a simple means of identifying when MIME messages were the protecte content. Again, though, the result is not nearly as general as that described in the current set of IDs. PEM explicitly does not include message header information because some of that information is changed between source and destination and thus it would be inapprorpiate to include it, in general. (You rightly distinguish between headers and envelope info, which makes sense in MIME but is harder to break out in non-MIME mail.) PEM does provide for inclusion of header/envelope fields by the user, but does not treat them specially, and we recommened against doing this in general. For example, the TO and CC fields may be transformed on an outgoing message (from local representations to fullly qualified mailbox names), so including the original form of this field within a protective, opaque boundary will yield a value at a recipient that may be of little value and might even cause confusion and problems, e.g., the value may be totally unsuitable for REPLY purposes. Still, in MIME, if some of the headers contain (redundant?) envelope information, the possiblity for confusion exists. Perhaps, in this vein, Peter is arguing that there is a need to provide advice about what does and does not make sense in terms of the very general capabilities offered by the generic encryption and signature constructs. However, because these constructs are so general, I agree with your observation that it is impossible to enumerate allowed and not allowed uses. One can adopt a more restrictive approach in an effort to protect users from surprizes, or can adopt a more flexible approach and hope for the best. Each approach has its pros and cons, as have been argued here before. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04685; 5 Aug 94 11:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04681; 5 Aug 94 11:12 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa08837; 5 Aug 94 11:12 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smac25653; Fri Aug 5 10:58:50 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09208; 5 Aug 94 10:53 EDT Received: from sol.tis.com by magellan.TIS.COM id aa09204; 5 Aug 94 10:51 EDT Received: from swan.cl.cam.ac.uk(128.232.0.56) by relay via smap (V1.3) id sma025532; Fri Aug 5 10:51:23 1994 Received: from ely.cl.cam.ac.uk (user mrr (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Fri, 5 Aug 1994 15:49:42 +0100 To: pem-dev@tis.com Cc: Michael.Roe@cl.cam.ac.uk Subject: Notes from Southampton certificate extensions meeting Date: Fri, 05 Aug 94 15:49:35 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Roe Message-Id: <"swan.cl.cam.:016790:940805144950"@cl.cam.ac.uk> I took the following notes at the session on ISO 9595-8 certificate extensions at the Southmapton SC 21 meeting. These are *not* the official minutes, and may contain inaccuracies or personal bias. I'm posting these notes to pem-dev as I expect they'll be of interest. Michael Roe Computer Security Group Cambridge University Computer Laboratory =========================================================================== Notes on Certificate Extensions Meeting Southampton, July 1994 Attendance Hoyt Kesterson (US, project editor) Dave Chadwick (UK) Michael Roe (UK) Warwick Ford (Canada) Junichi Yamaguchi (Japan) Ella Gardner (US) Debra Ansen (CH) Documents The following documents were distributed at the meeting: * ANSI X9.30 (draft) Public Key Cryptography Using Irreversible Algorithms for the Financial Services Industry * SC 21/WG1/N1261 US Contribution on NP for Extensions to ISO/IEN 9594-8 * SC 21/WG4/N1971 Canadian Contribution on proposed extensions to X.509 Certificates * (Canada temp doc) Explanatory support for proposed extensions to X.509 CA Certificates * (Canada temp doc) Latest ANSI X9.30-3 Certificate Formats Discussion 1. Certificate Extensions Hoyt Kesterson explained his proposal for adding an extensions field to certificates and CRLs. Each extension is accompanied by a criticality indicator; if an extension is marked as non-critical, it may be safely ignored. It was asked how can the verifier of a certificate compute the DER encoding of an extension it doesn't understand. As the computation of the DER encoding of the certificate is an essential part of certificate verification, it must be possible to do this. Hoyt Kesterson said that he was very displeased that existing implementations re-calculate the DER encoding; it was his original intention that the signature be computed on the octets as received. It was pointed out that implementors do this because the published standard tells them to do so. Two solutions to this problem were proposed: a) Require that all certificate extensions use explicit tagging everywhere b) Encapsulate each extension inside something (e.g. an ASN.1 EXTERNAL) in order to ensure that the octets as received will be identical to the DER encoding. Both of these proposals suffer from some technical problems: a) DER of EXTERNAL Even if extensions are encapsulated, certificate verification will still require the computation of the DER encoding of the whole certificate, including the encapsulated extensions. The definition of DER (and the related Canonical Encoding Rules, CER) neglects to define the encoding of an EXTERNAL. It was suggested that what implementors would do (in the absence of clear guidance from the standard) was to replace EXTERNAL with its ISO 8824 definition (which is a sequence of various elements) and then apply DER to this sequence. This would probably have the right effect. Hoyt pointed out that there is also a CHOICE construct in the definition of EXTERNAL, and the DER definition doesn't define the encoding of a CHOICE either. Again, it is clear what a sensible implementor would do, but the standard itself could do with being made more precise. b) DER of SET and SET-OF The ASN.1 constructs SET and SET OF share the same tag value. However, the rules for computing the DER of these two constructs are different. HHHH ence the first proposal (require all certificate extensions to use explicit tagging everywhere) won't work if a certificate extension contains a SET or SET OF construct. If the certificate verifier doesn't understand the extension, they will be able to tell from the explicit tag that the extension is either a SET or SET OF, but this is not sufficient to enable the verifier to compute the DER encoding. It was pointed out that the rules for SET and SET OF have the same effect in many cases. Thus, even if the verifier makes a wrong guess as to whether the extension is a SET or SET OF, they can still end up getting the right answer. If the two rules always had the same effect in all cases, then the fact that the verifier doesn't know which rule to apply wouldn't matter. Unfortunately, we were able to find a case in which the two rules have different effects. This is when a SET contains items with context-specific tags, and at least one tag value is so large that it cannot be represented in a single octet. c) The 1994 version of ASN.1 It was pointed out that EXTERNAL is treated differently in the 1994 version of ASN.1. There is a new construct, called EMBEDDED-PDV. The final text of the new ASN.1 was not available during this meeting. It was resolved that we would consult with ASN.1 experts to find out what is the ``recommended'' way of encapsulating an encoding with the new ASN.1 2. Progression of the work Hoyt asked whether this work should be progressed a defect report or a NWI. If we progress it as a defect report, the changes can be made to the `version 2' certificate, but if we progress it as a NWI the changes will result in a `version 3' certificate. Resolution: We will try and have the text stable by the meeting in Phoenix this December. We will aim to have a PDAM for ballot before next year's SC 21 meeting. Warwick asked if the work on CRLs should be in the same document as the work on certificates. The work on CRLs is considerably less mature, and it might delay progress to combine them. Resolution: Certificate extensions and CRL extensions will be in the same document for the time being. They can be separated later if this causes problems. 3. Relationship with SC 27 work Debra Ansen drew the meeting's attention to the SC 27 work on certificates. The SC 27 certificates are seeing some real use, notably in the European Commission funded TEDIS and SESAME projects. Why are there two different, incompatible standards for what appears to be the same thing? Michael Roe pointed out that SC 21 has received a liaison statement from SC 27 describing their work on certificates. This meeting was therefore formally entitled to consider the SC 27 work and (if necessary) send a liaison statement back. Unnecessary proliferation of similar but conflicting standards was felt to be undesirable. Resolution: Liaison statements are to be sent to the following bodies: (a) SC 27 (b) Implementor's workshops, e.g. the NIST OIW (c) The IETF 4. Canadian proposal for certificate extensions 4.1 Naming Jurisdiction Rules It was asked whether the support for naming jurisdiction rules was necessary. Hoyt said that it would have to be included to make the proposal acceptable to the Internet Privacy Enhanced Mail community, where such naming rules are part of the official security policy. It was pointed out that the Internet naming jurisdiction rules (in their current form) are a direct consequence of the certificate extensions NWI having taken several years to get going. If ISO 9594-8 had been extended earlier to provide a better mechanism, then the Internet community might have used it. Hoyt expressed an opinion that the new policy constraints extension could be used to serve the same purpose as naming jurisdiction rules, and furthermore had the advantage of not confusing naming with security policies. Michael Roe suggested that the essence of the naming jurisdiction rules were that the name of an entity was being used to determine which security policy applies to it. Thus, if a message is received from an entity whose name starts c=US;o=IBM it is inferred that the applicable security policy is the one dealing with interactions between the recipient and IBM. (In particular, it is inferred that the sender's certification authority ought to be the IBM certification authority). There was widepread disagreement with this interpretation. Dave Chadwick suggested that the name could be considered as being a parameter of the security policy. 4.2 Multiple Keys It was asked how the proposed extensions will permit different keys to be used for different purposes, and would this be backwards compatible with the current scheme. Warwick explained the proposal as follows: Version 1 certificates use a generic algorithm identifier (e.g. `rsa') in the subjectPublicKeyInfo field. This is interpreted to mean that the key can be used with the RSA algorithm for any purpose. New certificates may contain a different algorithm identifier (e.g. rsaWithMD5) which restricts the usage of the associated key to a specific purpose (in this case, digital signature). The permitted purposes are part of the definition of the algorithm identifier. New certificates may also contain additional keys in extension fields. In this case, each additional key is accompanied by a list of the purposes for which it may be used. 5. Certificate Revocation Lists 5.1 Revocation of Expired Certificates It has been proposed that text be added to X.509 permitting a certification authority to revoke a certificate which has expired. It was asked why would a certification authority ever want to do this; what is the meaning of a revoked, expired certificate supposed to be; what action is a certificate user supposed to take when this happens; and what is the effect on the non-repudiation service. From the point of view of a certificate verifier, there appears to be no difference. If the certificate has expired, then the verifier should reject it. Explicitly revoking an expired certificate makes no difference to the verifier's behavior, and hence appears to be pointless. It was argued that revoking an expired certificate can assist disaster recovery. Suppose the events happen in the following order: 1. A's key is compromised 2. Attacker uses A's key to forge a message to B 3. B accepts the forged message, as A's certificate is neither expired nor revoked. 4. A's certificate expires 5. A detects the compromise, and reports it to the CA 6. The CA wishes to inform B that A's key was compromised Depending on what B did as a result of the forged message, it may or may not be too late for B to take corrective action. In the cases where it is not too late for B to take corrective action, clearly B would like to be told that the compromise occurred. This is an argument in favour of allowing expired certificates to be revoked. The second argument in favour of revoking expired certificates was that with the non-repudiation service, an adjudicator would like to know when the key compromise happened. It was pointed out that the adjudicator will typically look at the certification authority's paper records, and not the on-line Directory Service, when resolving disputes. An argument against permitting back-dated revocation was that is causes problems with the non-repudiation service. In the example above, who would be legally liable for the consequences of B having acted on the basis of the forged certificate? A? B? The certification authority? It was pointed out that the real problem here is that undetected compromises can happen, and this is a problem irrespective of whether or not revocation can be back- dated. 5.2 Temporary Hold Facility X9.30 describes a mechanism whereby a CA can put a certificate `on hold'. Verifiers should reject certificates that are on hold, but a CA can change the status of a certificate from being on hold to being valid again. This is different from revocation, which is permanent. A revoked certificate can never be made valid again. This facility is useful when the CA suspects a compromise has occurred, but isn't sure; the certificate can be put on hold while the CA investigates further. The general principle was considered to be a reasonable one. The issue was raised as to whether this sort of mechanism was best provided using the Directory CRL attribute, or by using a specialized on-line server. For this mechanism to be effective, changes must propagate rapidly. Some well-known Directory implementations are not very good at rapidly propagating frequent changes. Dave Chadwick said that not all Directory implementations were as bad as QUIPU. 5.3 Alternative CRL Formats We identified two types of certificate users for which the current CRL format is not well suited. These were a) Large transaction processing systems, with plenty of stable storage. These systems would like to receive revocation information as `what's changed' updates which can be applied to their locally stored copy of the revocation list. b) Cryptographic modules with limited memory and long term storage. These systems would like to receive revocation information split into blocks, with each block stating the minimum and maximum serial number. When verifying a certificate, the cryptographic module need only load the relevant block, and not the entire list of all revoked certificates. It would also be desirable to have an on-line revocation server, for applications were it is necessary to be sure that a certificate is valid at that moment (and hasn't been revoked a few hours previously). A comparison was made with credit cards, were high-value transactions require an on-line check that the card has not been revoked, but low-value transactions do not. It was noted that the US DOD's MOSAIC system provides two separate CRL mechanisms: A fast propagating one for urgent revocation (e.g. after a key is compromised) and a slow propagating one for non-urgent revocation (e.g. when a user's organisational affiliation changes). 5.4 Key used to sign CRLs It was pointed out that a CA may want to use different keys for signing certificates and for signing CRLs. CRL signing needs to be done at regular intervals. For this reason, the CA may use a different computer system for signing CRLs than for signing certificates, and the CRL signing system may be more vulnerable to attack (e.g. because it has a more direct connection to a computer network). The consequences of the CRL-signing key being compromised are less serious than those of the certificate-signing key being compromised. (A forged CRL will at worst result in denial of service). The extension allowing different keys for different purposes (e.g. signing and key exchange) could also be used to provide separate keys for CRL-signing and certificate-signing. Hoyt asked if it was also possible to use two different keys for the same purpose. For example, an on-line server and an off-line server have different private keys, but both might be permitted to sign CRLs. It was pointed out that this would require a key version identifier in the CRL, so that the CRL verifier knew which of the two possible keys to use for signature verification. The approach of trying all possible keys until one works was acknowledged to be viable, but was considered inelegant. ========================================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05228; 5 Aug 94 11:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05224; 5 Aug 94 11:46 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa09640; 5 Aug 94 11:46 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa26446; Fri Aug 5 11:37:33 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09353; 5 Aug 94 11:35 EDT Received: from sol.tis.com by magellan.TIS.COM id aa09349; 5 Aug 94 11:33 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma026340; Fri Aug 5 11:33:23 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA03695; Fri, 5 Aug 94 11:32:28 EDT Message-Id: <9408051532.AA03695@tis.com> To: Steve Kent Cc: pem-dev@tis.com Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message of "Fri, 05 Aug 94 10:38:10 EDT." <9408051443.AA25432@relay.tis.com> Date: Fri, 05 Aug 94 11:32:46 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker Steve, One of the things you didn't emphasize is the current 1421 spec does provide for alternation of enhanced and non-enhanced body parts, so it would be possible to cobble together a user agent that generated a single message with different enhancements. I don't know of any user agents capable to generating such messages very easily, and I'm pretty sure that most user agents would not know how to parse a message that has alternating enhanced and unenhanced sections. Handling of multiple body parts is native to MIME on the other hand, so I have hopes that it will be far more natural to deal with multiple enhancements within MIME than it is outside of MIME. MIME also provides explicit support for encapsulating of messages (as distinct from message bodies) and for recursive encapsulation. How well all this works out in practice remains to be seen, of course. A different question is whether it's possible to build and distribute a MIME-PEM implementation that does not require full MIME support and then fits into the same environment that a 1421 implementation would fit into. If so, then I think the MIME-PEM spec is a fair candidate to replace 1421 entirely. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05898; 5 Aug 94 12:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05894; 5 Aug 94 12:39 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa10733; 5 Aug 94 12:39 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smac27675; Fri Aug 5 12:30:14 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09549; 5 Aug 94 12:26 EDT Received: from sol.tis.com by magellan.TIS.COM id aa09545; 5 Aug 94 12:24 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma027517; Fri Aug 5 12:25:05 1994 Received: from happy.tis.com by tis.com (4.1/SUN-5.64) id AA17283; Fri, 5 Aug 94 12:24:10 EDT Message-Id: <9408051624.AA17283@tis.com> To: Steve Kent Cc: pem-dev@tis.com Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message of "Fri, 05 Aug 94 12:05:41 EDT." <9408051608.AA27261@relay.tis.com> Date: Fri, 05 Aug 94 12:24:24 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker Steve, It's good that this issue is coming up for explicit discussion. It should indeed be possible to build a minimal MIME reader and writer that handles just what's necessary for MIME-PEM, and doesn't handle audio, video, image, complex forms of text or any applications other than PEM, and it should be possible to do so with roughly the same cost as the existing 1421 machinery. But until there's a worked example, I'm reluctant to assert this claim too loudly. My own belief, however, is that this indeed doable, and it remains on our queue to demonstrate. We definitely have not given up on this tack. Steve > Long ago it was a shared goal develop a version of MIME-PEm > that would be easily processed by users without full MIME capability, > and the first few drafts, I recall, tried thatb approach without > success. That idea also motivated Jeff's proposal, which he later > rescinded. The current I-Ds don't seem to consider this feature, > and so I assumed that we had given up on that tact. > > Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05913; 5 Aug 94 12:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05909; 5 Aug 94 12:39 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa10744; 5 Aug 94 12:39 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa27675; Fri Aug 5 12:30:07 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa09500; 5 Aug 94 12:09 EDT Received: from sol.tis.com by magellan.TIS.COM id aa09496; 5 Aug 94 12:07 EDT Message-Id: <9408051608.AA27261@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma027256; Fri Aug 5 12:07:55 1994 To: Stephen D Crocker Cc: pem-dev@tis.com Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message of Fri, 05 Aug 94 11:32:46 -0400. <9408051532.AA03695@tis.com> Date: Fri, 05 Aug 94 12:05:41 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent Steve, You're right that 1421 makes an explicit mention of the syntactic ability to intersperse PEM and non-PEM body parts in a single content. As I noted, there were concerns about user interface issues and so we downplayed that potential facility and I don't believe any implementations support it in any automated fashion. Long ago it was a shared goal develop a version of MIME-PEm that would be easily processed by users without full MIME capability, and the first few drafts, I recall, tried thatb approach without success. That idea also motivated Jeff's proposal, which he later rescinded. The current I-Ds don't seem to consider this feature, and so I assumed that we had given up on that tact. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08980; 5 Aug 94 15:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08976; 5 Aug 94 15:50 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa14914; 5 Aug 94 15:50 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma000888; Fri Aug 5 15:40:45 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa10022; 5 Aug 94 15:38 EDT Received: from sol.tis.com by magellan.TIS.COM id aa10018; 5 Aug 94 15:35 EDT Message-Id: <9408051936.AA00819@relay.tis.com> Received: from atlas.arc.nasa.gov(128.102.17.47) by relay via smap (V1.3) id sma000804; Fri Aug 5 15:35:52 1994 Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Fri, 5 Aug 1994 12:35:25 -0700 To: pem-dev@tis.com Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: Your message of "Thu, 04 Aug 1994 11:06:34 PDT." <9408041807.AA13957@relay.tis.com> Date: Fri, 05 Aug 1994 12:35:23 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Williams >From: Peter Williams >Subject: Re: Re[2]: Comment on draft-ietf-pem-signenc-01.txt >Date: Thu, 04 Aug 1994 11:06:34 -0700 >Its even worse than you may realize. Not only must one document the >specific security services properties, and demonstrate that the that >the various mechanisms do not collide in the provision of the claimed >service, but one must phrase the specification in terms of assurance >evaluation criteria, even for the lower levels of such classification >systems, at least when producing products likely to be recogised by the >professional security and banking industry. Generally, in futherence of the the request for comments process: I didn't mean to assert that MIME-PEM standard should follow an assurance evaluation format. Rather, that products evaluation specs would be able to directly refer to the standard, and not face problems when modelling the processes described therein in terms of the functional assurance criteria. This requires simply that the base material is organized up front to assist this later stage, so vital to products derived from this technology. Its vital to be able to make specific and accurate claims for an implemented product, using argument referenced wherever possible from accepted, and standardized base material. The security evaluation process expects certain things, which my comment seeks to point out might be wise to attend to, when considering the scope and intended usage of the standard. Comments were requested; he were some of mime.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09699; 5 Aug 94 16:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09695; 5 Aug 94 16:24 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa15754; 5 Aug 94 16:24 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa01516; Fri Aug 5 16:13:46 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa10111; 5 Aug 94 16:07 EDT Received: from sol.tis.com by magellan.TIS.COM id aa10107; 5 Aug 94 16:05 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma001388; Fri Aug 5 16:05:51 1994 Received: from pulsar.tis.com by tis.com (4.1/SUN-5.64) id AA09771; Fri, 5 Aug 94 16:04:54 EDT Message-Id: <9408052004.AA09771@tis.com> To: Jeff Thompson Cc: galvin@tis.com, pem-dev@tis.com, feldman@tis.com Subject: Re: PEM and MIME documents In-Reply-To: Your message of "Thu, 04 Aug 1994 17:58:42 PDT." <199408050058.RAA19985@netcom14.netcom.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa0" Date: Fri, 05 Aug 1994 16:05:32 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark S Feldman ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5544.776116873.2@tis.com> ... > Let met ask this way: Suppose I receive a PEM/MIME signed message from > someone and they also include an application/key-data with a > . (And suppose the sender has not included the optional > fields.) Where do I find the for the issuers to request > the CRLs ? It is not in the . Am I missing an interchange > that has to happen somewhere? Two of the six name forms can be derived from a certificate directly without the need for a keyid to make them unique. Both the certificate's public key and its Issuer Name/Serial Number are easily converted to IDs that can be used to retrieve a CRL without requiring a keyid or any other information not contained in the certificate. Mark ------- =_aaaaaaaaaa0 Content-Type: application/signature Content-ID: <5544.776116873.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,06 MIC-Info: RSA-MD5,RSA,dkNMTWD4WGV7YlyAl1vkndRlbysSm5q4jOAvrxOUW7BgcUuXkfUh= jmd0qsCtk/0pPB97yKMZjd+DQsWt2+qS+yPYciTErYNvS2eE9FE7Yk1B6v6WljP7l0whJP2jMR= Pp ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04256; 6 Aug 94 15:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04252; 6 Aug 94 15:30 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa08544; 6 Aug 94 15:30 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma006814; Sat Aug 6 15:17:46 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa11202; 6 Aug 94 15:07 EDT Received: from sol.tis.com by magellan.TIS.COM id aa11198; 6 Aug 94 15:03 EDT Received: from netcom13.netcom.com(192.100.81.125) by relay via smap (V1.3) id sma006771; Sat Aug 6 15:04:09 1994 Received: by netcom13.netcom.com (8.6.8.1/Netcom) id MAA01308; Sat, 6 Aug 1994 12:04:14 -0700 Date: Sat, 6 Aug 1994 12:04:14 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeff Thompson Message-Id: <199408061904.MAA01308@netcom13.netcom.com> To: pem-dev@tis.com Subject: Public key checksum as keyid In a recent message, I asked how I could choose an to use in an application/key-request to get the CRL for the TIS PCA based on the certificates I might get in a PEM/MIME message from someone at TIS. The problem was that the certificates included in application/key-data portion of the message don't contain a for me to use in requesting the CRL. It was suggested that I could use one of the two forms that don't require a , which are and . But since the TIS PCA has no issuer, I can't use . This will be the same problem for any entity at the "top" of a chain. And using requires the CRL database to be indexed by public key instead of disinguished name as most are. So, using one of the other forms which still have the unknown may still be necessary. I bring up this example to highlight the implementation difficulties of keeping track of an arbitrary keyid. Nonetheless, we do need a way to distinguish among the public keys that an entity may use. The previous draft, draft-ietf-pem-mime-05.txt, used fields like this: ::= "EN" "," "," "," ::= "STR" "," "," "," ::= "DN" "," "," "," This is basically what we have in the current draft except a public key hash was used instead of the present keyid. It had the advantage that the key identifier was not arbitrary and could be derived directly from the public key. There was no need for a database to seperately store the keyid or for a user to have to convey it. However, this scheme was abandoned because not all applications would be willing to implement the hash algorithm that a sender might use such as MD5 or SHA. I suggest solving this by using the checksum defined by the TCP/IP protocol as the keyid. It is easy to implement and all applications implicitly use it already. It does not need to be irreversible like MD5 or SHA. All we need is to distinguish among the few possible public keys that an entity may use. Therefore, for example, for me would look like: Originator-ID: EN, 1FF3, jefft@netcom.com where 1FF3 is the hex-encoded 16-bit checksum of the DER encoding of my public key. The recipient of my message may look up however many public keys in the database for jefft@netcom.com, compute the checksum on the public key encodings and select the one that matches. Best of all, there is no need to convey or store a seperate arbitrary keyid. - Jeff P.S. The definition of the checksum from the TCP document RFC 793 is: The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. (For our purposes, substitute "public key encoding" for "header and text".) This can be implemented in about 10 lines of C code as shown in RFC 1071.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03581; 8 Aug 94 10:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03577; 8 Aug 94 10:26 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa16857; 8 Aug 94 10:26 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma014003; Mon Aug 8 10:11:26 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa14055; 8 Aug 94 10:02 EDT Received: from sol.tis.com by magellan.TIS.COM id aa14051; 8 Aug 94 9:59 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma013877; Mon Aug 8 09:59:53 1994 Received: from pulsar.tis.com by tis.com (4.1/SUN-5.64) id AA19680; Mon, 8 Aug 94 09:58:47 EDT Message-Id: <9408081358.AA19680@tis.com> To: Jeff Thompson Cc: pem-dev@tis.com, feldman@tis.com Subject: Re: Public key checksum as keyid In-Reply-To: Your message of "Sat, 06 Aug 1994 12:04:14 PDT." <199408061904.MAA01308@netcom13.netcom.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa0" Date: Mon, 08 Aug 1994 09:59:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark S Feldman ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6654.776354253.2@tis.com> ... > It was suggested that I could use one of the two forms that don't > require a , which are and . But > since the TIS PCA has no issuer, I can't use . This will > be the same problem for any entity at the "top" of a chain. The TIS PCA certificate is currently self-signed, so its issuer distinguished name is the same as its subject distinguished name. This should be true for any top-level authority, so will still work. > And using > requires the CRL database to be indexed by public key > instead of disinguished name as most are. So, using one of the other > forms which still have the unknown may still be necessary. If you buy into any of the new naming models it becomes necessary to index certificates by more than just subject name and/or issuer name/serial number as done previously. Using the public key as the index is useful since it is the only truly cryptographically-necessary information. This allows the trust and certificate/CRL retrieval models to be separated from the low-level mechanics of verifying a signature or decrypting a message. With a pubic key, I can *do something* even if the level of trust is unknown. Besides, for a CRL to be useful, I must have the associated certificate, which must have a public key. > I bring up this example to highlight the implementation difficulties > of keeping track of an arbitrary keyid. Nonetheless, we do need a way > to distinguish among the public keys that an entity may use. The > previous draft, draft-ietf-pem-mime-05.txt, used fields like this: > > ::= "EN" "," > "," "," > ::= "STR" "," > "," "," > ::= "DN" "," > "," "," > > This is basically what we have in the current draft except a public > key hash was used instead of the present keyid. It had the advantage > that the key identifier was not arbitrary and could be derived > directly from the public key. There was no need for a database to > seperately store the keyid or for a user to have to convey it. > However, this scheme was abandoned because not all applications would > be willing to implement the hash algorithm that a sender might use > such as MD5 or SHA. One problem with the above, as you stated, is choosing the hash algorithm. It could be chosen on a per-certificate basis based on the signature algorithm being used, but not everyone will implement all signature algorithms. It would be nice to be able to index a certificate even if it can't be used immediately. Since the hash of the public key is merely hinting at the certificate to be used and not trusted information, any hash algoritm can be used. MD5 could be used universally and even if it were possible to produce collisions, it wouldn't matter, except that folks might get bad connotations if the standard used a "broken" hash. > I suggest solving this by using the checksum defined by the TCP/IP > protocol as the keyid. It is easy to implement and all applications > implicitly use it already. It does not need to be irreversible like > MD5 or SHA. All we need is to distinguish among the few possible > public keys that an entity may use. Therefore, for example, > for me would look like: > > Originator-ID: EN, 1FF3, jefft@netcom.com > > where 1FF3 is the hex-encoded 16-bit checksum of the DER encoding of > my public key. The recipient of my message may look up however many > public keys in the database for jefft@netcom.com, compute the checksum > on the public key encodings and select the one that matches. Best of > all, there is no need to convey or store a seperate arbitrary keyid. ... Regardless of what you use as the keyid in the above model, you still need to index by the various name forms or, at least, have a mapping from each name form to a distinguished name (indirect indexing). Also, a problem with a 16-bit checksum is the relatively high probability of a collision. While, as you said, irreversibility is not a problem, collisions are. A 32-bit CRC would be better and MD5 or SHA would be better than that. For complete freedom from collisions, just use the public key. At one point, was called going to be the public key in all name forms. Public keys aren't all that big, aren't too bothersome at the end of the message, and can be used, to some extent, immediately. Nothing to derive. No ambiguity. Nothing arbitrary. Something that everyone must have. A strong objection was raised by one camp to using in all name forms on, I believe, two grounds. First, privacy of the public key. It was claimed that key exchange might take place out-of-band between individuals and making public keys available to snooping adversaries provides a potential weakness. Second, I believe that traffic analysis may have been a concern, but I may not be remembering that correctly. In response to the above objections, if a snooping adversary is a concern, use a bigger key. If traffic analysis is a concern, which has never been addressed by PEM, use trusted, encrypting, re-mailers. The current draft is compromise that allows individuals to keep their public keys hidden and still uniquely identify the keys/certificates to use. Mark ------- =_aaaaaaaaaa0 Content-Type: application/signature Content-ID: <6654.776354253.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,06 MIC-Info: RSA-MD5,RSA,c6RFn/SDVudUfHETQ1izHJSbKG98ZPDlaZOd84HL2UR+ZfRE2rgN= W3fP3q41FdpOy5HNHfPnLFYx8UZX89ecakb1xXLNbx4UA5trxmntEtuYaIrJHQVnvG/WVAxvpM= ug ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23042; 10 Aug 94 0:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23038; 10 Aug 94 0:21 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa26289; 10 Aug 94 0:21 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma007233; Wed Aug 10 00:13:28 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa20428; 10 Aug 94 0:06 EDT Received: from sol.tis.com by magellan.TIS.COM id aa20421; 10 Aug 94 0:00 EDT Received: from netcom7.netcom.com(192.100.81.115) by relay via smap (V1.3) id sma006983; Tue Aug 9 23:38:57 1994 Received: by netcom7.netcom.com (8.6.8.1/Netcom) id UAA25919; Tue, 9 Aug 1994 20:38:58 -0700 Date: Tue, 9 Aug 1994 20:38:58 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeff Thompson Message-Id: <199408100338.UAA25919@netcom7.netcom.com> To: feldman@tis.com Cc: pem-dev@tis.com, feldman@tis.com In-Reply-To: message from Mark S Feldman on Mon, 08 Aug 1994 09:59:31 -0400 Subject: Re: Public key checksum as keyid > > I suggest solving this by using the checksum defined by the TCP/IP > > protocol as the keyid. It is easy to implement and all applications > > implicitly use it already. It does not need to be irreversible like > > MD5 or SHA. All we need is to distinguish among the few possible > > public keys that an entity may use. Therefore, for example, > > for me would look like: > > > > Originator-ID: EN, 1FF3, jefft@netcom.com > > > > where 1FF3 is the hex-encoded 16-bit checksum of the DER encoding of > > my public key. The recipient of my message may look up however many > > public keys in the database for jefft@netcom.com, compute the checksum > > on the public key encodings and select the one that matches. Best of > > all, there is no need to convey or store a seperate arbitrary keyid. > ... > > Regardless of what you use as the keyid in the above model, you still > need to index by the various name forms or, at least, have a mapping > >from each name form to a distinguished name (indirect indexing). Can the draft authors speak to this point? Is an implementation required to process name forms with a keyid in order to be compliant? If so, what exactly is the recommended database mechanism which will let me "index by the various name forms" and how is it supposed to be secured/authenticated? If the keyid is not required, then as Mark very eloquently explains below, just using the public key will suffice. The keyid arose only to keep public keys private for various reasons. > Also, a problem with a 16-bit checksum is the relatively high > probability of a collision. While, as you said, irreversibility is > not a problem, collisions are. A 32-bit CRC would be better and MD5 > or SHA would be better than that. I agree. The TCP/IP style checksum can easily be exteneded to 32 bits or more. As I understand it, using MD5 or SHA was abandoned for political reasons for people who didn't want anything to do with the other's hash algorithm, which is why I proposed something "neutral" like the checksum. > For complete freedom from collisions, just use the public key. At one > point, was called going to be the public key in all name > forms. Public keys aren't all that big, aren't too bothersome at the > end of the message, and can be used, to some extent, immediately. > Nothing to derive. No ambiguity. Nothing arbitrary. Something that > everyone must have. > > A strong objection was raised by one camp to using in all name > forms on, I believe, two grounds. First, privacy of the public key. > It was claimed that key exchange might take place out-of-band between > individuals and making public keys available to snooping adversaries > provides a potential weakness. Second, I believe that traffic > analysis may have been a concern, but I may not be remembering that > correctly. > > In response to the above objections, if a snooping adversary is a > concern, use a bigger key. If traffic analysis is a concern, which > has never been addressed by PEM, use trusted, encrypting, re-mailers. > The current draft is compromise that allows individuals to keep their > public keys hidden and still uniquely identify the keys/certificates > to use. I summary: If my application doesn't implement keyid and is still considered MIME/PEM compliant, I will use the public key and be merrily on my way. If it is required, I propose using the checksum which is non arbitrary and does not need a seperate machanism for keeping track of it. - Jeff   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02228; 12 Aug 94 8:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02218; 12 Aug 94 8:45 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa04893; 12 Aug 94 8:45 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma005559; Fri Aug 12 08:35:22 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa29103; 12 Aug 94 8:32 EDT Received: from sol.tis.com by magellan.TIS.COM id aa29099; 12 Aug 94 8:29 EDT Received: from dub-img-1.compuserve.com(198.4.9.1) by relay via smap (V1.3) id sma005364; Fri Aug 12 08:06:01 1994 Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.940406sam) id IAA22175; Fri, 12 Aug 1994 08:05:34 -0400 Date: 12 Aug 94 08:03:59 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Jonathan M. Backus" <76277.115@compuserve.com> To: PEM DEV Subject: ID: ANSI X9.17-Based Key Management Message-Id: <940812120359_76277.115_FHA46-3@CompuServe.COM> INTERNET-DRAFT J. Backus draft-ietf-pem-ansix9.17-00.txt July 1994 Privacy Enhancement for Internet Electronic Mail: Part V: ANSI X9.17-Based Key Management Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document provides definitions, formats, references, and citations for the use of ANSI X9.17 compliant key management in support of Privacy Enhanced Mail (PEM) in the Internet community. It is intended to become one member of the set of related PEM RFCs. Acknowledgements This document is the product of many discussions about the four pre-existing RFCs on this topic. Contributors include D. Balenson, J. Linn, S. Kent, and P. Rajaram. I would also like to thank contributors to the PEM-DEV mailing list who have provided valuable input which is reflected in this memo. Brief History In 1985, the American National Standards Institute (ANSI) set forth a standard that defined a means of generating, distributing, and maintaining secret cryptographic keys to be used for encryption and/or authentication of data in conjunction with the ANSI Data Encryption Algorithm [1](DEA, Backus [Page 1] INTERNET DRAFT ANSI X9.17-Based Key Management July 1994 also known as DES). This standard, known as X9.17 [2], was originally created for financial institutions, but it has since been widely accepted by the federal government and many parts of the commercial sector. In 1992, the National Institute of Standards and Technology (NIST) published Federal Information Processing Standard Publication (FIPS PUB) 171 [3], which interprets and defines the use of ANSI X9.17 within the federal government. This method of key management presumes that the generation, distribution, and maintenance of the secret keys is occurring externally and separate from an application. The specific application with regards to this memo is Privacy Enhanced Mail (PEM). 1. Executive Summary The ANSI X9.17 standard defines a means of distributing symmetric data keys for later use in DES-based encryption (ANSI X9.23 [4]) and authentication (ANSI X9.9 [5]). This document describes how these secret keys can be used to provide privacy-enhanced mail (PEM) integrity and encryption services. It does not define the use of these secret keys for DES-base message authentication. It gives an overview on the workings of the X9.17 standard, a description and example of X9.17 within PEM, and the necessary changes to RFC1421 and RFC1423 to accommodate the identification and use of X9.17 keys. 2. Overview of ANSI X9.17 Since DES is a "secret key" based algorithm, by definition both parties in a relationship have the same key value. This means that the exchanging of keys must be done in a secure fashion (e.g. split knowledge mailers by certified mail, SmartCards by bonded carrier, etc.). If keys are changed very often this can be expensive, human intensive, and potentially prone to human error or attack. To provide the greatest flexibility the X9.17 standard has defined the ability to use either 1, 2, or 3-layer key hierarchies. In all cases, the highest layer is manually exchanged, and the lowest layer is a data key (KD) which is used to do the actual protection of user data. In a 1-layer hierarchy, the KD is manually exchanged. In the 2 and 3-layer hierarchies, the highest layer is a manually exchanged key encrypting key (KK) which is used to secure and exchange the next lowest layer. In the 2-layer hierarchy, the manually exchanged KK is used to automatically secure and exchange the KD. In the 3-layer relationship, the manually exchanged KK is used to automatically secure and exchange another KK, which is, in Backus [Page 2] INTERNET DRAFT ANSI X9.17-Based Key Management July 1994 turn, used to automatically secure and exchange the KD. Again, in all three cases, the lowest layer is the KD which is used to do the actual protection of user data. Once KD(s) have been exchanged they are stored at each end of the relationship in some secure fashion, typically by encrypting them with a unique Local Master Key (LMK), named, and given some time period within which they may be used. The X9.17 standard defines the use of cryptographic service messages (CSM), and the full protocol within, that are to be used between two parties that wish to exchange keying information. Within the cryptographic service message (CSM) there are subfields that identify the originator of the message (ORG), the recipient of the message (RCV), and the name of the key (IDK1). These three fields are pointed out because of their significance in later sections of this memo. 3. Conveying use of ANSI X9.17 keys Within the PEM protocol, as defined in RFC1421 [6], an IK is identified in a pair of "Originator-ID-Symmetric:" and "Recipient-ID-Symmetric:" header fields, and a corresponding "Key-Info:" header field conveys usage indicators and DEK and MIC values. In PEM, the first item carried in both the "Originator-ID-Symmetric:" and "Recipient-ID-Symmetric:" header fields is an Entity Identifier subfield. For use with ANSI X9.17, the Entity Identifier subfield names the originator and recipient of the previously exchanged KD that is used to protect the PEM message. In particular, the entity identifier subfield of the "Originator-ID-Symmetric:" header contains the name of the KD originator, taken from the ORG subfield of the CSM used to exchange the KD, and the "Recipient-ID-Symmetric:" header contains the name of the KD recipient, taken from the RCV subfield of the CSM used to exchange the KD. In PEM, the "Key-Info:" header field conveys 4 items, an IK Use Indicator, a MIC Algorithm Indicator, a DEK, and a MIC. The IK Use Indicator identifies the algorithm and mode which the identified IK was used for DEK and MIC encryption for a particular recipient. The MIC Algorithm Indicator identifies the MIC computation algorithm used for a particular recipient. The DEK and MIC are symmetrically encrypted under a previously identified IK. For use with ANSI X9.17, instead of an IK Use Indicator, the first subfield of the "Key-Info:" header field is an X9.17 Use Indicator, which indicates the use of an ANSI X9.17 key. Instead of a DEK, the third subfield is the name of the KD, Backus [Page 3] INTERNET DRAFT ANSI X9.17-Based Key Management July 1994 taken from the IDK1 subfield of the CSM used to exchange the KD. The MIC is encrypted under the DEK (KD). This is done for two main reasons. First, the ANSI X9.17 standard allows for a 1-layer relationship. In a 1-layer relationship there would not be a KK to correspond to the PEM interchange key (IK). Secondly, and more importantly, the ANSI X9.17 standard very closely defines the usage of KKs and maintains usage counters for them. To use them for any reason other then to encrypt lower layer keys within CSMs is a violation of the standard. 4. Example and explanation of a message secured with X9.17 keys The following is an example of a privacy-enhanced message using ANSI X9.17 keys: -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,ENCRYPTED Content-Domain: RFC822 DEK-Info: DES-CBC,F814EDE5960C597 Originator-ID-Symmetric: JON-BACKUS Recipient-ID-Symmetric: DAVE-BALENSON Key-Info: DES-KMA,RSA-MD2,KDE0446, B70665BB9BF7CBCDA60195DB94F727D3 Recipient-ID-Symmetric: JOHN-LINN Key-Info: DES-KMA,RSA-MD2,KDE1830, E2EF532C65CBCFF79F83A2658132DB47 Recipient-ID-Symmetric: STEVE-KENT Key-Info: DES-KMA,RSA-MD2,KDE9203, 8DA308493CC4385B96DA720EA394B8A3 LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNS 8tEjmF/zxB+bHiMom8Lr9wloXIKjHUlBL820dkeoY7U7tAngie9EEpk6e1n asDdflkeikck/sap9pel8jj3kKK+3do6720dcBWGGsDLpTpSCnpot3k495z dxd/H5LMDWnonNvPCxQUHt== -----END PRIVACY-ENHANCED MESSAGE----- This message is being sent to three different recipients. The "Originator-ID-Symmetric:" header field contains an X9.17 compliant "ORG" subfield value of "JON-BACKUS." The "Recipient-ID-Symmetric:" header fields contain X9.17 compliant "RCV" subfield values of "DAVE-BALENSON", "JOHN- LINN", and "STEVE-KENT." The first item of the "Key-Info:" header fields contain the X9.17 indicator, "DES-KMA." The third item of the "Key-Info:" header fields contain X9.17 compliant "IDK1" subfield values of "KDE0446", "KDE1830", and "KDE9203." Backus [Page 4] INTERNET DRAFT ANSI X9.17-Based Key Management July 1994 4.1 Implications of this example There is only one "Originator-ID-Symmetric:" header field. This implies that the originator is known by the same X9.17 "ORG" value for all recipients. If for some reason the originator of the message is known by different "ORG" values then they must create separate messages for each group of recipients that know them by a particular "ORG" value. Each originator/recipient pair have a different X9.17 key value. This implies that the PEM application must encrypt this message three separate times, once for each recipient. The example only shows the body of the message encrypted for one of the recipients. The encrypted body would be different for each recipient. 5. Changes to RFC1421 To allow for ANSI X9.17 keys to be used there requires some changes to "Part I: Message Encryption and Authentication Procedures" of "Privacy Enhancement for Internet Electronic Mail" document RFC1421. 5.1 Section 4.6.2.1.2, Originator-ID-Symmetric Fields This section needs modified to reflect that if X9.17 keys are being used then this field will contain the X9.17 "ORG" subfield value that was used in the CSM exchange. 5.2 Section 4.6.4.1.2, Recipient-ID-Symmetric Field This section needs modified to reflect that if X9.17 keys are being used then this field will contain the X9.17 "RCV" subfield value that was used in the CSM exchange. 5.3 Section 4.6.4.2.1, Symmetric Key Management This section needs modified to reflect that the first item of the "Key-Info:" field may convey the presence of ANSI X9.17 keys instead of the usage of the IK, in which case the third item would convey the KD name instead of the IK encrypted DEK. 5.4 Section 9, Descriptive Grammar The BNF needs expanded to reflect the options of and for , with and being defined as 16 characters in compliance with ANSI X9.17 naming conventions. Backus [Page 5] INTERNET DRAFT ANSI X9.17-Based Key Management July 1994 6. Changes to RFC1423 To allow for ANSI X9.17 keys to be used there requires some changes to "Part III: Algorithms, Modes, and Identifiers" of "Privacy Enhancement for Internet Electronic Mail" document RFC1423 [7]. 6.1 Section 3.3, DES in KMA mode (DES-KMA) ** NEW ** A new section, 3.3 DES in KMA mode (DES-KMA), needs created to reflect that in this mode only the MIC is encrypted in DES Electronic Codebook mode and that the character string "DES-KMA" within an encapsulated PEM header field indicates use of this algorithm/mode combination. 6.2 Descriptive Grammar The BNF needs expanded to reflect the option of "DES-KMA" for field and the option of for , with being defined as 16 characters in compliance with ANSI X9.17 naming conventions. NOTES: [1] ANSI X3.92, Data Encryption Algorithm, 1981. [2] ANSI X9.17, Financial Institution Key Management (Wholesale), April 1985. [3] FIPS 171, Key Management using ANSI X9.17, April 1992. [4] ANSI X9.23, Financial Institution Encryption of Wholesale Financial Messages, 1988. [5] ANSI X9.9, Financial Institution Message Authentication (Wholesale), 1986. [6] Linn, J., "Privacy Enhancement of Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC1421, February 1993. [7] Balenson, D., "Privacy Enhancement of Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC1423, February 1993. Author's Address Jonathan M. Backus 15 Catawba Place Hagerstown, MD 21742-6515 Backus [Page 6] INTERNET DRAFT ANSI X9.17-Based Key Management July 1994 Phone: 301-714-0446 Fax: 301-714-1854 EMail: 76277.115@compuserve.com  Backus [Page 7]   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04943; 15 Aug 94 11:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08779; 15 Aug 94 11:28 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04923; 15 Aug 94 11:28 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04626; 15 Aug 94 11:09 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: pem-dev@tis.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pem-ansix9.17-00.txt Date: Mon, 15 Aug 94 11:09:41 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9408151109.aa04626@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy-Enhanced Electronic Mail Working Group of the IETF. Title : Privacy Enhancement for Internet Electronic Mail: Part V: ANSI X9.17-Based Key Management Author(s) : J. Backus Filename : draft-ietf-pem-ansix9.17-00.txt Pages : 7 Date : 08/12/1994 This document provides definitions, formats, references, and citations for the use of ANSI X9.17 compliant key management in support of Privacy Enhanced Mail (PEM) in the Internet community. It is intended to become one member of the set of related PEM RFCs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pem-ansix9.17-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pem-ansix9.17-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940812110805.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pem-ansix9.17-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pem-ansix9.17-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940812110805.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11017; 16 Aug 94 16:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11013; 16 Aug 94 16:16 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa15159; 16 Aug 94 16:16 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma024697; Tue Aug 16 16:03:10 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa16018; 16 Aug 94 16:00 EDT Received: from sol.tis.com by magellan.TIS.COM id aa16010; 16 Aug 94 15:56 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma024623; Tue Aug 16 15:57:01 1994 Received: by tis.com (4.1/SUN-5.64) id AA02981; Tue, 16 Aug 94 15:55:27 EDT Date: Tue, 16 Aug 94 15:55:27 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sandy Murphy Message-Id: <9408161955.AA02981@tis.com> To: jefft@netcom.com Cc: pem-dev@tis.com, sandy@tis.com First, I apologize for taking so long to respond to your question to the "draft authors". I've been the only one of the authors here at TIS for the last week, so the fault is all mine. You say: >Can the draft authors speak to this point? Is an implementation >required to process name forms with a keyid in order to be compliant? Yes, an implementation must be able to process name forms with a keyid in order to be compliant. To make it otherwise would raise the possibility of non-interoperability -- balkanized groups of users who use different implementations and can communicate within the group but not with users of other implementations. And, now that you've mentioned it, I suppose we must explicitly discuss compliance requirements in the text. >If so, what exactly is the recommended database mechanism which will >let me "index by the various name forms" and how is it supposed to be >secured/authenticated? The database mechanism is a local matter. We do not recommend any particular database mechanism. If you are looking for non-binding suggestions, I can tell you what TIS is doing. We have eliminated the certificate orientation for the database as well as the hashing and lookups. We are making the public key itself the fundamental orientation of the database. We are also going to a flat ascii file with no hierarchy. Looking for a match to a received name form will be done with a sequential search. We believe that the number of certificates we were dealing with made the hashing, opening and closing the hash file, etc., actually more expensive than just reading the ascii file. There's a point where the economies of scale come into play and we don't think we'll reach it for an appreciable time. If by "secured/authenticated" you mean how does one trust the binding of a name form to an identity and keep the binding's integrity protected, then you have to realize that these new name forms do not have the trust designed in to them that is designed into the certificate hierarchy. The price you pay for a more user friendly name is no built-in trust model. Which is not to say that you couldn't create a trust model, e.g., by signing key-data responses (and whatever other information, such as validity periods, you would like to have in your trust model). You could even establish a hierarchy of signed responses. If you go whole-hog, you could re-invent the present PEM certificate hierarchy. >I summary: If my application doesn't implement keyid and is still >considered MIME/PEM compliant, I will use the public key and be >merrily on my way. If it is required, I propose using the checksum >which is non arbitrary and does not need a seperate mechanism for >keeping track of it. It is perfectly OK for you to use the public key for the keyids that you generate yourself. It is also perfectly OK for you to use the checksum to generate keyids. Your point is that you can generate the keyid from the public key each time it is needed rather than store it. So this works fine when you are generating the header fields. But it only works when interpreting received headers if the checksum is mandated for everyone as the keyid generation process. This may not be palatable for everyone (note the requirement on PGP keyids that they be either 6 or 8 characters long; a requirement chosen so as to match the present PGP spec). Problems with the keyid generation aside, you will always have to deal with arbitrary values -- the email name, arbitrary string, and PGP name forms are all arbitrary. As Mark pointed out, you will still have to index by, store and keep track of these arbitrary values. I do not understand why an arbitrary value for the keyid is more of a problem. Incidentally, it is perhaps interesting to some to note that if someone sends you a message with a PGP identifier (containing a keyid chosen for the purpose of hiding the public key) in it, there is nothing in the present spec to prevent you from responding with a PK identifier and thus exposing the public key to the gaze of all and sundry. Jim Galvin should be back later this week and may chime in on his own. --Sandy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11512; 16 Aug 94 16:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11508; 16 Aug 94 16:44 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa15674; 16 Aug 94 16:44 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa25596; Tue Aug 16 16:34:29 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa16470; 16 Aug 94 16:26 EDT Received: from sol.tis.com by magellan.TIS.COM id aa16466; 16 Aug 94 16:24 EDT Message-Id: <9408162025.AA25472@relay.tis.com> Received: from labs-n.bbn.com(128.89.0.100) by relay via smap (V1.3) id sma025357; Tue Aug 16 16:24:10 1994 To: Jeff Thompson Cc: pem-dev@tis.com Subject: Re: Public key checksum as keyid In-Reply-To: Your message of Tue, 09 Aug 94 20:38:58 -0700. <199408100338.UAA25919@netcom7.netcom.com> Date: Tue, 16 Aug 94 16:11:16 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent Jeff, I've read the exchanges generated by your question about how one indexes a database via keyid for various name forms as propose din the MIME-PEM draft. The response was interesting in part because it discussed various groups that argued about the relative merits of different approaches, yet I don't recall seeing any of that discussion on PEM-DEV. Nonetheless, the points you raised were good ones and I do think that a more open discussion of key identifiers is appropriate. I agree with the observation that if there is a traffic analsyis motivation behind some aspects of this design, then this should become an explicit requirement for MIME-PEM, even though it was explicitly not a requirement for PEM in any of the previous RFCs. Also, I concurr with the observation that not placing public keys in messages headers, to avoid possible (cryptographic) weaknesses is a bad idea, as it suggests use of algorithms that are probably not suitable in the first place. A better rationale for the complex set of key id options now in the draft might be an argument about the size of key ids in terms of header size. However, that argument has not been put forth explciitly. Also, the PEM WG notes point out that the requirements for originator and recipient key ids are different, and that might argue against adopting a uniform approach to selecting such ids, across the various "name forms" cited in the I-D, especially since the syntactic uniformity exists primarily at the top level and then diverges for various specific name forms. Finally, the question of compliance is an appropriate one. With the greater diversity of ID options present in this I-D (vs. 1421) it is natural to ask whether a compliant implementation must support all of these forms, and thus have database searching capabilities appropriate for each, or if compliance is achieved by supporting any one form, or is there a default form? Different answers have implications for implementation complexity and size, and for interoperability. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13410; 19 Aug 94 19:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13406; 19 Aug 94 19:24 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa22363; 19 Aug 94 19:24 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma022542; Fri Aug 19 19:13:04 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa04390; 19 Aug 94 19:03 EDT Received: from sol.tis.com by magellan.TIS.COM id aa04386; 19 Aug 94 19:01 EDT Received: from x400gate.bnr.ca(192.58.194.73) by relay via smap (V1.3) id sma022452; Fri Aug 19 19:02:35 1994 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 19 Aug 1994 19:01:47 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 19 Aug 1994 19:00:55 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 19 Aug 1994 19:01:00 -0400 Date: Fri, 19 Aug 1994 23:00:55 +0000 X400-Originator: /dd.id=1618054/g=warwick/i=ws/s=ford/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.993:19.07.94.23.00.54] X400-Content-Type: P2-1984 (2) Content-Identifier: X.509 Certifi... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "warwick (w.s.) ford" X-Orig-Sender: "warwick (w.s.) ford" Message-Id: <"7046 Fri Aug 19 19:01:19 1994"@bnr.ca> To: pem-dev@tis.com, osf-sec-wg@apollo.hp.com Subject: X.509 Certificate Extensibility Field Major progress was made at the July meeting of ISO/IEC JTC1/SC21 on the project to extend the X.509 certificate. The meeting issued a defect report on the 1993 standard with a proposed resolution (reproduced below) to add an extension field similar to that proposed for ANSI X9.30-3. Unless major objections are received in the defect ballot, or from the implementor workshops (to which liaisons have been sent) then this extension can become formally adopted at the December ISO Directories group meeting in Phoenix. In addition, a Working Draft for specific ISO standard extensions, which will follow the usual ISO progression path, was produced (I can supply this on request). The proposed extensions include: - key identifier - key usage - secondary public key - policies - authority constraints Other extensions can be developed by non-ISO groups (e.g., PEM) if desired. Extensions to CRLs are also proposed. ---------------------------------- PROPOSED RESOLUTION Add an extensions field to the certificate as follows: Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, -- CA's name validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, extensions [3] Extensions OPTIONAL } } Extensions ::= SET OF Extension Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical EXTENSION.&critical ({ExtensionSet} {@extnId}) } extnValue EMBEDDED PDV -- Contains a -- canonical encoding of a value of type &ExtnType for the -- extension object identified by extnId -- -- Definition of the following information object set is deferred, perhaps to -- standardized profiles or to protocol implementation conformance statements. -- The set is required to specify a table constraint on the critical component of -- Extension. -- ExtensionSet EXTENSION ::= { ... | ... } The extensions field allows addition of new fields to the structure without modification to the ASN.1 definition. An extension consists of a unique identifier (an object ID), the data type of the extension (some ASN.1 type), and a criticality flag. If the criticality flag is FALSE, an implementation should ignore unrecognized extensions. if the criticality flag is TRUE, unrecognized extensions shall cause the structure to be considered invalid, i.e., in a certificate, an unrecognized critical extension would cause validation of a signature using that certificate to fail. The following object class is used to define specific extensions: EXTENSION ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &critical BOOLEAN DEFAULT FALSE, &ExtnType } WITH SYNTAX { SYNTAX &ExtnType [CRITICAL &critical] IDENTIFIED BY &id } In Certificate Revocation Lists, the same extension field can be added, in two places, as follows: CertificateList ::= SIGNED { SEQUENCE { signature AlgorithmIdentifier, issuer Name, thisUpdate UTCTime, nextUpdate UTCTime OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate UTCTime, crlEntryExtensions Extensions OPTIONAL } OPTIONAL, crlExtensions [0] Extensions OPTIONAL }}   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04585; 23 Aug 94 12:51 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04581; 23 Aug 94 12:51 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa10761; 23 Aug 94 12:51 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma017777; Tue Aug 23 12:18:15 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa12229; 23 Aug 94 12:10 EDT Received: from sol.tis.com by magellan.TIS.COM id aa12212; 23 Aug 94 11:59 EDT Received: from leszpt.tele.pw.edu.pl(148.81.65.34) by relay via smap (V1.3) id sma017190; Tue Aug 23 11:24:45 1994 Received: by leszpt.tele.pw.edu.pl (4.1/SMI-4.1-JS-1.14a) id AA05180; Tue, 23 Aug 94 17:25:59 +0200 Date: Tue, 23 Aug 94 17:25:59 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Karol Gorski Message-Id: <9408231525.AA05180@leszpt.tele.pw.edu.pl> To: pem-dev@tis.com Subject: IPRA and other questions Hello, I've been listening to this group for some time and I've noticed several postings with requests for information about the status/existence of the IPRA and the PCA's but I've never seen a reply to these questions. I think it would be a good idea if somebody could summarise the current situation regarding these institutions: ie. whether they exist, how to get in touch with them and what sort of policies they have. I'm a member of a team developing a PEM application here in Poland. It will go into beta testing soon and we shall be working on setting up our own CA to cover the academic network. Therefore I would also be interested in hearing about about any experiences from people who have already done this (set up CA's, that is). Also, it would be interesting to know how widespread is the deployment of PEM. I know of projects in the UK, in Japan and of implementations in Sweden, France and Germany - anywhere else ? If I receive replies by email I'll try to summarise them. Thanks in advance, Karol Gorski Institute of Telecommunications Warsaw University of Technology Warsaw, Poland email: karol@tele.pw.edu.pl   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05164; 23 Aug 94 13:45 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05159; 23 Aug 94 13:45 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa12373; 23 Aug 94 13:45 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma018677; Tue Aug 23 13:20:38 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa12383; 23 Aug 94 13:17 EDT Received: from sol.tis.com by magellan.TIS.COM id aa12379; 23 Aug 94 13:15 EDT Received: from netcom13.netcom.com(192.100.81.125) by relay via smap (V1.3) id sma018600; Tue Aug 23 13:15:45 1994 Received: by netcom13.netcom.com (8.6.8.1/Netcom) id KAA19173; Tue, 23 Aug 1994 10:15:56 -0700 Date: Tue, 23 Aug 1994 10:15:56 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeff Thompson Message-Id: <199408231715.KAA19173@netcom13.netcom.com> To: kent@bbn.com Cc: pem-dev@tis.com In-Reply-To: message from Steve Kent on Tue, 16 Aug 94 16:11:16 -0400 Subject: Re: Public key checksum as keyid > Jeff, > > I've read the exchanges generated by your question about how > one indexes a database via keyid for various name forms as propose din > the MIME-PEM draft. The response was interesting in part because it > discussed various groups that argued about the relative merits of > different approaches, yet I don't recall seeing any of that discussion > on PEM-DEV. Nonetheless, the points you raised were good ones and I > do think that a more open discussion of key identifiers is > appropriate. I agree with the observation that if there is a traffic > analsyis motivation behind some aspects of this design, then this > should become an explicit requirement for MIME-PEM, even though it was > explicitly not a requirement for PEM in any of the previous RFCs. > Also, I concurr with the observation that not placing public keys in > messages headers, to avoid possible (cryptographic) weaknesses is a > bad idea, as it suggests use of algorithms that are probably not > suitable in the first place. Thanks for the comments. I waited a couple of days for other people to respond, but I wonder why there doesn't seem to be the interest. I'd be interested in comments from other people who are thinking towards trying to implement this stuff. > A better rationale for the complex set of key id options now > in the draft might be an argument about the size of key ids in terms > of header size. However, that argument has not been put forth > explciitly. I know that in a least one conversation with the TIS folks, header size was explicitly stated as not a factor in choosing the right approach. Barring comments to the contrary, let's assume this is the case. > Also, the PEM WG notes point out that the requirements > for originator and recipient key ids are different, and that might > argue against adopting a uniform approach to selecting such ids, > across the various "name forms" cited in the I-D, especially since the > syntactic uniformity exists primarily at the top level and then > diverges for various specific name forms. I think allowing different originator and recipient forms is reasonable and consistent with how the cryptography is actually utilized. > Finally, the question of compliance is an appropriate one. > With the greater diversity of ID options present in this I-D > (vs. 1421) it is natural to ask whether a compliant implementation > must support all of these forms, and thus have database searching > capabilities appropriate for each, or if compliance is achieved by > supporting any one form, or is there a default form? Different > answers have implications for implementation complexity and size, and > for interoperability. If the (beautiful) use of an MD5 digest was rejected simply because the SHA folks didn't want MD5 in their application, what is going to happen when more stringent people dicover they have to support PGP identifiers? What are they going to tell their lawyers? Should it only be "post PGP 2.6"? Has anyone explicitly addressed this issue? Also Steve (Kent), I wonder what you think about Sandy Murphy's comments on the TIS database implementation: > We have eliminated the certificate orientation for the database as > well as the hashing and lookups. We are making the public key itself > the fundamental orientation of the database. We are also going to a > flat ascii file with no hierarchy. A while back, I suggested making the public key the fundamental orientation and you pointed out that this is not a good idea since such a database cannot be distributed. Based on TIS's approach, it seems that a distributed database is not being kept open as a design goal. I wonder what your view is on this, Steve? - Jeff   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06857; 23 Aug 94 15:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06852; 23 Aug 94 15:39 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa15548; 23 Aug 94 15:39 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma020462; Tue Aug 23 15:22:12 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa16918; 23 Aug 94 15:03 EDT Received: from sol.tis.com by magellan.TIS.COM id aa16891; 23 Aug 94 14:53 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma019926; Tue Aug 23 14:53:57 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA16528; Tue, 23 Aug 94 14:52:39 EDT Message-Id: <9408231852.AA16528@tis.com> Reply-To: James M Galvin To: "Housley, Russ" Cc: sandy@tis.com, crocker@tis.com, ned@innosoft.com, pem-dev@tis.com Subject: Re: Comment on draft-ietf-pem-signenc-01.txt In-Reply-To: "Housley, Russ"'s message of Tue, 02 Aug 1994 09:29:45. <9407027758.AA775844985@uu0892.spyrus.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa0" Date: Tue, 23 Aug 1994 14:52:43 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10070.777667936.2@tis.com> Russ, You made some comments which stirred some discussion. I won't comment on the discussion except to use your note to confirm the outcome. I assume that a MIME message body can be both signed and encrypted by applying both multipart/signed and multipart/encrypted. First, I think that this should be stated explicitly. It is interesting that the words you chose to describe the desired feature are not explicitly present. However, from a MIME viewpoint, what you desire is present insofar as each of the definitions specifies that the content type is applied to an arbitrary body part, i.e., there are no restrictions whatsoever on what can be signed or encrypted. If your suggestion is to add an example demonstrating that both may be applied to an arbitrary body part, we can do that. I should point out that previous versions of the PEM-MIME spec (as opposed to the Security Multiparts spec under discussion) included many examples of how the body parts could be combined. They were not included in Version 6 of that document because we had not completed the implementation, yet, and so could not generate real examples. Second, the order of the encapsulation is very important. In general, the didital signature should be applied before encryption. If the message is signed before it is encrypted, then the signed MIME message body can be forwarded to another recipient. However, if the the message is encrypted before it is signed, then forwarding signed MIME message body to another recipient is not sufficient for that user to process the message; the user should not have the keys to decrypt the signed ciphertext. While there might be some esoteric cases where the ciphertext MIME message body should be signed, I do ot believe that this is the normal case. I suggest that a section be added to the ID which details this relationship. We welcome your opinion Russ, however, we've also heard alternate opinions. Peter Williams detailed one example in the discussion which followed. Another example used in the commercial community is the desire to be able to send a note to both a person and the person's secretary. In this way, a secretary could be alerted to the urgency of a message although the secretary would not be able to process the message on behalf of the person. In the specification, we'll add a few sentences about how they might be combined but we'll leave the semantics of the combinations for those applications that use them. Jim ------- =_aaaaaaaaaa0 Content-Type: application/signature Content-ID: <10070.777667936.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,Rx+N5NEoFYwBsOQlKPAUanoUJPLrIrFKB9JU1KpX90+cut8podTM= 6GArkVL7tuvkeuDXVBoVces8Hqft7DEdnDsFxM8EkzW7vBSS9qWiH7T75I3Srw8sS7LKeO9Aee= r2 ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06938; 23 Aug 94 15:44 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06934; 23 Aug 94 15:44 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa15673; 23 Aug 94 15:44 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa20678; Tue Aug 23 15:32:16 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa00143; 23 Aug 94 15:23 EDT Received: from sol.tis.com by magellan.TIS.COM id aa16990; 23 Aug 94 15:14 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma020341; Tue Aug 23 15:16:03 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA20887; Tue, 23 Aug 94 15:14:47 EDT Message-Id: <9408231914.AA20887@tis.com> Reply-To: James M Galvin To: Jeff Thompson Cc: pem-dev@tis.com Subject: Re: PEM and MIME documents In-Reply-To: 's message of Thu, 04 Aug 1994 17:58:42 PDT. <199408050058.RAA19985@netcom14.netcom.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa0" Date: Tue, 23 Aug 1994 15:14:51 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10164.777669257.2@tis.com> > According to the current PEM/MIME what is the > recommended interaction between a user and a PCA for > getting the latest CRL? In RFC 1424, I would compose a > CRL-RETRIEVAL-REQUEST with the Issuer: field set to the > issuer's name. But the for the > application/key-request has no "DN only" form like this. > How would I request the CRL for the TIS PCA, for > example? > What you would do is send an application/key-request message > with the Issuer field only to set to an appropriate > value. For example, > > Content-Type: application/key-request > > Issuer: DN, , > > An obvious question to ask is, "what do I set to, > since it must be non-null?" > > The answer is that you use the key identifier for the public > key of the issuer identified by the distinguished name > specified in the ISSUER field that signed the CRL you wish to > retrieve. Boy is that a mouthful. Let met ask this way: Suppose I receive a PEM/MIME signed message from someone and they also include an application/key-data with a . (And suppose the sender has not included the optional fields.) Where do I find the for the issuers to request the CRLs ? It is not in the . Am I missing an interchange that has to happen somewhere? You are exactly right, there is an interchange that must occur somewhere. The missing interchange is the one that binds the name form and key id to a public key/private key pair. You are correct the specification does not allow for the explicit inclusion of this binding in the certificate or crl chain. However, I would expect a server responding to an application/key-request message to want to return all relevant information to a client. Thus, I would expect a server to return two application/key-data body parts to the client, one with the desired chain and one (or more) with the necessary bindings. If you want to suggest that this is "ugly" and that we should have explicitly included all relevant information at all times, my response is I hear you. However, a principal objective was to provide building blocks that can be utilized in straightforward ways to realize all the currently visible features and hopefully features we haven't thought of yet. In other words, what we propose is a design choice based on our experience building PEM and MIME systems. We're not claiming it's perfect, but in the spirit of "rough consensus and running code", it works. Jim ------- =_aaaaaaaaaa0 Content-Type: application/signature Content-ID: <10164.777669257.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,1uJgo9XPfxMyZ2jNPJ/1GT6aEA6K/LG93W016ROGNNJbx9+WbG5C= JsqAvEqcSwwKv0S9SoXUow7ruLx7idKkm5SsqhEalV4fLqQj84wutHB8mYkZQW4FtWH7BOya4b= mj ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07683; 23 Aug 94 16:16 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07679; 23 Aug 94 16:16 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa16371; 23 Aug 94 16:16 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma021250; Tue Aug 23 16:03:00 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa01647; 23 Aug 94 15:59 EDT Received: from sol.tis.com by magellan.TIS.COM id aa01643; 23 Aug 94 15:57 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma021153; Tue Aug 23 15:58:01 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA27089; Tue, 23 Aug 94 15:56:44 EDT Message-Id: <9408231956.AA27089@tis.com> Reply-To: James M Galvin To: Jeff Thompson Cc: pem-dev@tis.com Subject: Re: Public key checksum as keyid In-Reply-To: Jeff Thompson's message of Sat, 06 Aug 1994 12:04:14 PDT. <199408061904.MAA01308@netcom13.netcom.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa0" Date: Tue, 23 Aug 1994 15:56:48 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10344.777671795.2@tis.com> It was suggested that I could use one of the two forms that don't require a , which are and . But since the TIS PCA has no issuer, I can't use . This will be the same problem for any entity at the "top" of a chain. I bring up this example to highlight the implementation difficulties of keeping track of an arbitrary keyid. I would argue that the "top" is always a special case, regardless of the mechanism to handle it. As Mark Feldman pointed out, we handle it by identifying "tops" with self-signed certificates. Interestingly, doing so makes most of the special case processing go away. I would also disagree with your assertion of the implementation difficulties of keeping track of an arbitrary keyid. The database mechanism we're using now uses the public key as the unique index element for each "user record", although each user record may be looked up via any data in the record. One of the data values in the record is the "identifiers", which are the name form/key identifier pairs. More details on request. Nonetheless, we do need a way to distinguish among the public keys that an entity may use. The previous draft, draft-ietf-pem-mime-05.txt, used fields like this: ::= "EN" "," "," "," ::= "STR" "," "," "," ::= "DN" "," "," "," This is basically what we have in the current draft except a public key hash was used instead of the present keyid. It had the advantage that the key identifier was not arbitrary and could be derived directly from the public key. There was no need for a database to seperately store the keyid or for a user to have to convey it. However, this scheme was abandoned because not all applications would be willing to implement the hash algorithm that a sender might use such as MD5 or SHA. Your last statement is false. The reasons for moving away from hashing the public key was because there was no motivation for the additional complexity. First, applying the hash meant you had to indicate which hash algorithm is to be used. This suggests there will be more than one (perhaps not initially but I can imagine at least SHA and MD5 wanting to exist). As soon as there's more than one you have to remember which one is preferred. This is tantamount to remembering the key identifier in the first place. Second, there are communities using other mechanisms inconsistent with hashing anything. In particular, PGP simply uses arbitrary hex values assigned by users. We believed the best solution was to specify the property required of the key identifier (unique per public key per user) and specify a syntax that would allow implementations to use what is most convenient for them. Jim ------- =_aaaaaaaaaa0 Content-Type: application/signature Content-ID: <10344.777671795.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,tkkIeAk2faETPHnS+CROZnYLoGTWhAq7H7O/+D1Ppf67PR0pIRUm= YRYhPtJz/8JDHGwKuyX+6r6n3TZP/iGtJAhjPUEDEaoUw0b0VVgURioqunX9pENP1iUlDTyHMV= 0z ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07997; 23 Aug 94 16:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07993; 23 Aug 94 16:38 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa16824; 23 Aug 94 16:38 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id smaa21675; Tue Aug 23 16:23:54 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa01968; 23 Aug 94 16:21 EDT Received: from sol.tis.com by magellan.TIS.COM id aa01964; 23 Aug 94 16:19 EDT Received: from sol.tis.com(192.33.112.100) by relay via smap (V1.3) id sma021610; Tue Aug 23 16:20:43 1994 Received: from antares.tis.com by tis.com (4.1/SUN-5.64) id AA29106; Tue, 23 Aug 94 16:19:27 EDT Message-Id: <9408232019.AA29106@tis.com> Reply-To: James M Galvin To: Jeff Thompson Cc: kent@bbn.com, pem-dev@tis.com Subject: Re: Public key checksum as keyid In-Reply-To: Jeff Thompson's message of Tue, 23 Aug 1994 10:15:56 PDT. <199408231715.KAA19173@netcom13.netcom.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; boundary="----- =_aaaaaaaaaa0" Date: Tue, 23 Aug 1994 16:19:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10386.777673159.2@tis.com> I know that in a least one conversation with the TIS folks, header size was explicitly stated as not a factor in choosing the right approach. Barring comments to the contrary, let's assume this is the case. This is true. MIME handles all these issues. > Also, the PEM WG notes point out that the requirements for > originator and recipient key ids are different, and that might > argue against adopting a uniform approach to selecting such > ids, across the various "name forms" cited in the I-D, > especially since the syntactic uniformity exists primarily at > the top level and then diverges for various specific name > forms. I think allowing different originator and recipient forms is reasonable and consistent with how the cryptography is actually utilized. I have yet to be convinced there is any significant advantage to this approach. A user has a public/private pair. As to whether the public component or the private component is employed is easily determined by context, regardless of whether I'm an originator or a recipient. Although it might be useful (although I'd like a specific example of how) to indicate in the syntax what is already known by context, I fail to see the benefit of the additional complexity in an implementation. I would appreciate if someone would enlighten me. Also Steve (Kent), I wonder what you think about Sandy Murphy's comments on the TIS database implementation: > We have eliminated the certificate orientation for the > database as well as the hashing and lookups. We are making > the public key itself the fundamental orientation of the > database. We are also going to a flat ascii file with no > hierarchy. A while back, I suggested making the public key the fundamental orientation and you pointed out that this is not a good idea since such a database cannot be distributed. Based on TIS's approach, it seems that a distributed database is not being kept open as a design goal. I wonder what your view is on this, Steve? I, too, am interested in Steve's comments as I do not recall them. However, even if it's true that a database oriented according to the public key can not be distributed, I fail to see where this is a issue. The database being discussed here is a local database used by local application programs to support the PEM protocol. It is one of several databases that might be employed by local application programs that need the public/private keys of originators/recipients. As you might expect, the public key is not the only index into the database. It is simply the element required to be unique for each "user" recorded in the database. I would assert, in fact, that of all the elements that must be in the database for each user, it is the one most likely (required, even) to be unique and, thus, no other element is suitable for orienting the database. Having said that, let me also say I wouldn't implement a distributed databased keyed according to a public key, principally because there are other elements that lend themselves more naturally (from a human perspective) to hierarchies of distributed databases, in particular distinguished names and email addresses. Jim ------- =_aaaaaaaaaa0 Content-Type: application/signature Content-ID: <10386.777673159.1@tis.com> Content-Transfer-Encoding: quoted-printable Version: 5 Originator-ID: IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1= c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02 MIC-Info: RSA-MD5,RSA,wmdxaST6QXeXZ9zGBW07lxclvfE3SzDu0jMVFcNTogb7/X19S7Hz= x5OLPNhr1dhoXv7OaZ3/cRw5zXgokyaVTCHNE7qIukzEEg+9XEnY8eJ1DzU+z6cxgt0vP33snE= /G ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10561; 29 Aug 94 20:31 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10557; 29 Aug 94 20:31 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa08427; 29 Aug 94 20:30 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma011268; Mon Aug 29 20:14:28 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa08594; 29 Aug 94 20:06 EDT Received: from sol.tis.com by magellan.TIS.COM id aa08590; 29 Aug 94 20:02 EDT Received: from x400gate.bnr.ca(192.58.194.73) by relay via smap (V1.3) id sma011113; Mon Aug 29 20:03:16 1994 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 29 Aug 1994 20:02:43 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 29 Aug 1994 20:02:07 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 29 Aug 1994 19:57:00 -0400 Date: Mon, 29 Aug 1994 19:57:00 -0400 X400-Originator: /dd.id=1618054/g=warwick/i=ws/s=ford/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.811:30.07.94.00.02.07] X400-Content-Type: P2-1984 (2) Content-Identifier: X.509 Certifi... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "warwick (w.s.) ford" X-Orig-Sender: "warwick (w.s.) ford" Message-Id: <"19839 Mon Aug 29 20:02:23 1994"@bnr.ca> To: pem-dev@tis.com, osf-sec-wg@apollo.hp.com Subject: X.509 Certificate Extension Proposal X-Attachments: "X.509-WD-28Jul4-txt" (type: text) Here is text of the Working Draft of proposed X.509 certificate extensions in ISO. Warwick Ford ----------------------------- ~7 Certificate Definitions Source: ISO/IEC JTC1/SC21/WG4, Southampton 1. Scope This project is developing extensions to the definitions of certificates and certificate revocation lists (CRLs) in ISO/IEC 9594-8. These extensions are in the following areas: a) extensions to certificates to support indicators of key usage and key identifier; b) extensions to certificates to support certification of secondary public keys used for different purposes than the primary public key; c) extensions to certificates to support policy identifiers and constraints, with the latter being applicable to CA-certificates, i.e., certificates for CAs issued by other CAs; d) extensions to CRLs to support the capability to temporarily suspend a certificate, and subsequently either revoke or reinstate it; e) extensions to CRLs to better support their use for nonrepudiation purposes; f) optional CRL formats to provide for breaking the revocation information from one CA into multiple parts for operational purposes. This Working Draft contains technical proposals for items a) through d) in clauses 5 through 8, respectively, and discussion and a call for comments on items e) and f) in clause 9. This Working Draft assumes that a certificate extension field, which provides for indicating criticality/noncriticality of each extension, has already been added to the certificate and CRL formats. This Working Draft defines a set of extensions to be used in conjunction with that field. 2. Normative References [no changes] 3. Definitions CA-certificate A certificate for one CA issued by another CA 4. Abbreviations CA Certification Authority PCMCIA Personal Computer Memory Card International Association PEM Privacy Enhanced Mail TCB Trusted Computing Base 5. Key Usage and Key Identifiers 5.1 Requirements The following requirements regarding key usage and key identifiers need to be accommodated: a) It should be possible to securely associate a public key with a particular usage, e.g., digital signature, encryption key transport, encryption key agreement. Correct usage needs to be checkable by a public-key user, i.e., certificate user. b) When a CA issues a certificate for another CA, the issuing CA may wish to constrain certificates issued by the subject CA (or subsequently chained certificates) to ultimately certifying user public keys for limited usage purposes. (See also clause 7.) c) It should be possible to positively identify different public keys for the same user used at different points in time. Such identification needs to be included in a public key certificate. 5.2 Certificate Extension Fields One certificate extension field, called the KeyIdAndUsage field is defined. It comprises the following two optional subfields: a) KeyUsage: This subfield indicates the intended use of the public key being certified. It is applicable to both CA-certificates and end-user certificates. b) KeyIdentifier: This subfield enables distinct keys used by the same subject to be differentiated (e.g., as key updating occurs). It is applicable to both CA- certificates and end-user certificates. The following ASN.1 type is proposed for use in this extension field: KeyIdAndUsage ::= SEQUENCE { keyUsage KeyUsage OPTIONAL, keyIdentifier KeyIdentifier OPTIONAL } KeyUsage ::= CHOICE { userKeyUsage UserKeyUsage, cAKeyUsage CAKeyUsage } UserKeyUsage ::= BIT STRING { userAuthentication (0), -- for digital signatures for -- authentication purposes keyEncryption (1), -- for encrypting keys -- for transfer dataEncryption (2), -- for encrypting user data keyAgreement (3) -- for key agreement exchange nonRepudShortTerm (4) -- for digital signature -- for short-term nonrepudiation nonRepudLongTerm (5) } -- for digital signature -- for long-term nonrepudiation CAKeyUsage ::= BIT STRING { keyCertSign (0), -- for a CA to sign public key -- certificates offLineCRLSign (1), -- for a CA to sign an off-line -- CRL onLineCRLSign (2), -- for a CA to sign an on-line -- CRL transactionSign (3) } -- for a CA to sign on-line -- administration transactions KeyIdentifier ::= BIT STRING This extension is noncritical. The KeyUsage subfield serves to distinguish a CA-certificate from an end-user certificate. The cAKeyUsage option must be used if the subject is permitted to act as a CA. UserKeyUsage values may be used to control key usage in end systems and/or to distinguish between multiple certificates for the same subject with keys intended for different purposes. 6. Secondary Public Keys 6.1 Requirements It should be possible to convey in a certificate more than one public key for different algorithms and/or different key usage purposes. Example: One certificate for one user can convey a key for a key establishment algorithm as well as a distinct key for a digital signature algorithm. 6.2 Certificate Extension Fields The certificate extension field, called SecondaryPublicKeyInfo is defined. This field indicates the intended use of the public key being certified. It is applicable to both CA-certificates and end-user certificates. The following ASN.1 type is defined for use in this field: SecondaryPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, keyUsage KeyUsage, keyIdentifier KeyIdentifier, secondaryPublicKey BIT STRING } This extension is noncritical. 7. Policy Identifiers and Constraints A public-key user needs to obtain and validate a certificate containing the required public key. If the public-key user does not already hold an assured copy of the public key of the certification authority that signed the certificate, then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates may be needed, comprising a certificate of the public-key owner signed by one certification authority, and zero or more additional certificates of certification authorities signed by other certification authorities. Chains are required because a public-key user is only initialized with a limited number (often one) of assured certification authority public keys. In general, processing of a certificate chain needs to consider the trust associated with each certificate. If one homogeneous security policy applies to all certificates this is not an issue. However, when multiple security policies are involved (e.g., when policies vary in different financial institutions or when interoperation with external organizations occurs) certificate chain processing requires additional information to be made available, either from the certificates themselves or from local sources. This standard specifies a means for conveying requisite information within the certificates themselves. The development of this Standard takes into account the requirements described below. 7.1 General Chain-Processing Requirements CA-certificates are used in certificate chain processing, which is a high-assurance function required in all public- key user systems, including digital signature verification systems and systems which perform public-key-based encryption. Such functions should be suitable for implementation in a Trusted Computing Base (TCB); furthermore, they should be suitable for implementation in hardware cryptographic modules such as cryptographic PCMCIA cards. The following requirements regarding certificate chain processing need to be accommodated: a) Certificate chain processing needs to be automatable and self-contained. This is necessary to permit trusted hardware or software modules to be implemented which perform the certificate chain processing functions. b) It should not be necessary for certificate chain processing to depend upon real-time interactions with the local user nor upon the use of trusted local databases of policy-description information. (Some trusted local information - an initial public key, at least - is needed for certificate chain processing but the amount of such information should be minimized.) c) Maximal policy freedom should be permitted. Any security domain should be able to stipulate which CAs in other domains it trusts and for which purposes. Chaining through multiple policy domains should be supported. d) Complete flexibility in trust models is required. A strict hierarchical model which is adequate for a single government is not adequate when considering the needs of governments internationally nor when considering the needs of non-government enterprises. e) Key-pair updating, on a regular or exceptional- condition basis, should not be precluded (or made unduly difficult) for any CA. f) Flexibility should be possible in selection of the first trusted CA in a chain processed by any public-key user system. In particular, it should be possible to require that the chain start in the local security domain of the public-key user system. g) Naming should not be artificially constrained, i.e., X.500 name structures considered natural for organizations or geographical areas should not need adjustment in order to accommodate certification authority requirements. h) Any extended system introduced should be backward- compatible with the unconstrained X.509 system (as specified in 1988 and 1993 versions of ISO/IEC 9594-8 or X.509) and with the Internet Privacy Enhanced Mail (PEM) system specified in RFC 1422. 7.2 Policy Requirements The following requirements relate to policies: a) Certificate chains need to be able to span multiple security domains. b) Within a security domain, multiple policies may be recognized. c) Between security domains, relationships may exist to allow two domains to trust each other with respect to a particular policy or with respect to different, but compatible, policies. d) One domain may not be prepared to fully trust lower- level CAs in another domain; this leads to a requirement for constraints on CA behaviour that can be automatically enforceable. 7.3 Concepts To satisfy the above requirements, two concepts are introduced: identified policies and CA constraints. See Annex A for examples of how these concepts may be used in practice. 7.3.1 Identified Policies Identified policies involve the assignment of identifiers to collections of policy statements which are not, in general, specifiable in terms recognizable by automated certificate chain processing systems. For example, an identifiable policy may imply particular procedures used in authenticating certified entities, assurance levels of equipment employed, and/or liability assumed by the certifying party. An identified policy may imply rules which can be automatably verified by particular applications. For example, different identified policies may apply to financial transactions in the dollar ranges of $1-$9,999, $10,000 to $1,000,000, and above $1,000,000; use of the correct policy identifier can be checked by the financial application (which has knowledge of both the transaction value and the policy semantics) but cannot be checked by the base certificate-chain verification logic. Each identified policy is assigned a globally-unique ASN.1 object identifier. There may be multiple policies defined and used within a single domain and one policy may be used across multiple domains, if suitable agreements exist. When cross-certifying from one domain to another, it is sometimes acceptable (either unilaterally or mutually) to recognize an equivalence mapping from one identified policy to another. For example, the U.S. government domain may have a policy called "Canadian Trade" and the Canadian government may have a policy called "U.S. Trade"; while the two policies are distinctly identified and defined, there may be an agreement between the two governments to accept certificate chains extending cross-border within the rules implied by these policies for relevant purposes. Policy mapping implies significant administrative overheads and the involvement of suitably diligent and authorized personnel in related decision-making. In general, it is preferable to agree upon more global use of common policies than it is to apply policy mapping. For example, it would be preferable for the U.S., Canada, and Mexico to agree upon a common policy for "North American Trade". 7.3.2 CA Constraints CA constraints are an "insurance" provision which enables a chain-verifying system to check that a CA in the chain is not violating rules stipulated by more trusted CAs, i.e., CAs closer to the chain start. Constraints applied to a CA may relate to the subject namespace, to the key-usage purposes, and to the algorithms for which that CA may issue certificates. The most important use of CA constraints will be in restricting the name space for which a CA can certify. In this respect, CA constraints fulfill a similar function to the PEM name subordination rule, but provide for much greater flexibility in naming conventions. 7.4 Certificate Extension Fields This standard defines a set of fields for inclusion in CA- certificates for the purpose of facilitating certificate chain processing in multiple-policy environments. The contents of these fields allow a CA to specify policy- dependent constraints on the permitted characteristics of certificates issued by the subject of the CA-certificate and of subsequent certificates in a certificate chain. This approach does not require certificate chain processing functions to have any knowledge of specific policies. (Certificate-issuing systems do require such knowledge.) The following certificate extension fields are defined: a) Policies Field: This field lists identified policies that the certificate is expressly recognized as supporting (dependent upon constraints, the certificate may or may not be usable with other policies as well). This field is applicable to both CA-certificates and end-user certificates. b) AuthorityConstraints Field: This field is applicable to CA- certificates only. It specifies a set of constraints to apply with respect to certificates issued by the CA that is the subject of the immediate certificate. 7.4.1 Policies Field This extension field lists local-domain policies that the certificate is expressly recognized as supporting (dependent upon constraints, the certificate may or may not be usable with other policies as well). This field is applicable to both CA-certificates and end-user certificates. The following ASN.1 type is proposed for use in this field: Policies ::= SET OF PolicyID PolicyID ::= OBJECT IDENTIFIER -- policyIDs are registered by community- interest -- groups or private organizations This extension is noncritical. 7.4.2 AuthorityConstraints Field This extension field is applicable to CA-certificates only. It specifies a set of constraints to apply with respect to certificates issued by the CA that is the subject of the immediate certificate and/or constraints to apply throughout the subsequent chain. The following ASN.1 type is proposed for use in this extension field: AuthorityConstraints ::= SET OF SEQUENCE { policyID PolicyID OPTIONAL, -- If policyID is omitted, constraintSet -- applies to any policy constraintSet ConstraintSet } ConstraintSet ::= SEQUENCE { certNameConstraint NameConstraint OPTIONAL, certAlgorithmConstraint AlgorithmConstraint OPTIONAL, certExplicitPolicy ExplicitPolicy DEFAULT notRequired, chainNameConstraint NameConstraint OPTIONAL, chainAlgorithmConstraint AlgorithmConstraint OPTIONAL, chainKeyUsageConstraint KeyUsage OPTIONAL, chainNameSubordConstraint NameSubordConstraint DEFAULT noConstraint, chainLenConstraint ChainLenConstraint OPTIONAL, nextPolicy NextPolicy OPTIONAL, nextCertConstraints NextCertConstraints OPTIONAL } NameConstraint ::= SET OF SubtreeClassSpecification -- SubtreeClassSpecification imported from -- BasicAccessControl module in X.501 -- AlgorithmConstraint ::= SET OF AlgorithmIdentifier -- AlgorithmIdentifier imported from -- AuthenticationFramework module in X.509 -- ExplicitPolicy ::= ENUMERATED { required (0), -- Active policy must explicitly -- appear in policies field notRequired (1) } -- Active policy need not explicitly -- appear in policies field NameSubordConstraint ::= ENUMERATED { noConstraint (0), subordinateToCA (1), subordinateToCAsSuperior (2) } ChainLenConstraint ::= INTEGER NextPolicy ::= PolicyID NextCertConstraints ::= ConstraintSet This extension is critical. Note the convention that fields beginning "cert..", e.g., certAlgorithmConstraint, indicate a constraint applying to immediate certificates only, i.e., certificates issued by the subject of the current certificate. Fields beginning "chain..", e.g., chainAlgorithmConstraint indicate a constraint applying to the chain, and all certificates therein, starting with any certificate issued by the subject of the immediate certificate. The various immediate certificate constraint fields are interpreted as follows: certNameConstraint: If this constraint is present, certificates issued by the subject of this certificate must be constrained to subjects within one of the specified subtrees. Unless the SubtreeClassSpecification contains a chop specification, a subtree is considered to extend to the leaves of the DIT. certAlgorithmConstraint: If this constraint is present, certificates issued by the subject of this certificate will only be considered valid if signed using one of the identified algorithms and the corresponding identified parameters. certExplicitPolicy: If the value "required" is specified, the active policy must explicitly appear in the Policies field of certificates issued by the subject of this certificate. If the value notRequired is specified, or if the field is omitted, then the active policy need not explicitly appear in the Policies field. The various chain-related constraint fields are interpreted as follows: chainNameConstraint: If this constraint is present, certificates issued by the subject of this certificate plus all subsequent certificates in the chain must be constrained to subjects within one of the specified subtrees. Unless the SubtreeClassSpecification contains a chop specification, a subtree is considered to extend to the leaves of the DIT. chainAlgorithmConstraint: If this constraint is present, all certificates in the chain starting from a certificate issued by the subject of this certificate will only be considered valid if signed using one of the identified algorithms and the corresponding identified parameters. chainKeyUsageConstraint: If this constraint is present, the user key certified at the end of this certificate chain can be considered valid only for the identified key usages. chainNameSubordConstraint: If the value subordinateToCA is specified then, in all certificates in the chain starting from a certificate issued by the subject of this certificate, the subject name must be subordinate to the issuer name of the same certificate. If the value subordinateToCAsSuperior is specified then, in all certificates in the chain starting from a certificate issued by the subject of this certificate, the subject name must be subordinate to the name of the immediate superior DIT node of the issuer of the same certificate. chainLenConstraint: If this constraint is present, this constraint gives the maximum number of CA- certificates that may follow this certificate in a certificate chain. Value 0 indicates that the subject of this certificate may issue certificates only to end- users and not to further CAs. If no chainLenConstraint appears in any certificate of a chain, there is no limit to the allowed length of the chain. nextPolicy: If this field is present, it gives a new active policy to be used in processing the certificate issued by the subject of this certificate and in any subsequent certificates until a new nextPolicy is specified. nextCertConstraint: If this constraint is present, it specifies a set of constraints to apply to any certificate issued by the subject of this certificate. Note that this constraint can be used recursively, allowing a CA to constrain the conditions applying to any point further along a certificate chain. When the use of nextCertConstraint results in multiple constraints of the same type applying to a certificate, the constraints combine such that the aggregate constraint can become more restrictive but never less restrictive than any individual constraint. 7.5 Certificate Chain Processing Procedure The KeyUsage and AuthorityConstraints fields are designed for use in an automated self-contained implementation of certification chain processing logic. No local user interaction is necessary and no accesses to trusted local databases are required. The inputs to the chain processing procedure are: y a certificate chain; y a trusted public key value, or an identifier of such a key (if the key is stored internally to the chain processing module), for use in verifying the first certificate in the chain; y an initial active policy identifier; y an initial explicit-policy indicator, which indicates whether or not the active policy needs to explicitly appear in the Policies field of the first certificate; and y a key usage indicator taking one or more of the values userSignature, keyEncryption, dataEncryption, and keyAgreement. The output of the procedure is an indication of either success or failure of chain validation. If failure, a diagnostic code indicating the reason for failure is returned. In outline, the procedure operates as follows. The active policy is set to that specified by the initial active policy identifier and the explicit-policy indicator is stored. Each certificate is then processed in turn, starting with that signed using the input trusted public key. The last certificate is processed as an end-user certificate; all other certificates (if any) are processed as CA- certificates. Actions performed in processing a CA certificate include: a) Check that the signature verifies and dates are valid. b) Check that the KeyUsage field permits CA signature. c) If explicit-policy indicators so require, check that the active policy appears in the Policies field. d) Check that any stored chain constraint is not violated. e) Check that other stored constraints from earlier certificates in the chain that are to apply specifically to this certificate are not violated. f) Examine the AuthorityConstraints field and process all constraint sets applying to the active policy. Apply g) thru j) as appropriate. g) Store any chain constraint values for use in processing of the remainder of the chain. Multiple such constraints encountered throughout chain processing combine such that the aggregate constraint can become more restrictive but never less restrictive. h) Store any certNameConstraint, certAlgorithmConstraint or certExplicitPolicy details for use in processing the next certificate. i) If there is a nextPolicy field, set the active policy to that identified. j) If there is a nextCertConstraint field, store all details for use in processing the next certificate. Actions performed in processing an end-user certificate include: a) Check that the signature verifies and dates are valid. b) Check that the KeyUsage field is consistent with the input key usage indicator and any chainKeyUsageConstraint stored during chain processing. c) If the explicit-policy indicator so requires, check that the active policy appears in the Policies field. Note that the above outline omits certificate revocation list processing, which can be considered an additional set of checks which have to be applied to each certificate to ensure their validity. It is possible to specify an extended version of the above chain processing procedure which results in default behaviour identical to the rules of Internet PEM as defined in RFC 1422. In this extended version, additional inputs to the procedure are a list of one or more Policy Certification Authority (PCA) names and an indicator of the position in the chain where the PCA is expected. At the nominated PCA position, the CA name is compared against this list. If a recognized PCA name is found then a constraint of SubordinateToCA is implicitly assumed for the remainder of the chain and processing continues. If no valid PCA name is found, and if the chain cannot be validated on the basis of identified policies, then the chain is considered invalid. 8. CRL Reason and Suspend Extensions 8.1 Requirements The following requirements for extending the CRL format need to be accommodated: a) It should be possible to convey in a CRL an indication of the reason for revocation. b) There is a requirement to be able to temporarily suspend validity of a certificate and subsequently either revoke or reinstate it. NOTE - These requirements have been recognized by the ANSI committee developing the ANSI X9.30-3 standard on certificate management, and the CRL format in that standard has been extended accordingly. It is a goal of this project to achieve aligned formats for ANSI X9.30-3 and ISO/IEC 9594- 8 CRLs. 8.2 CRL Extension Fields One CRL entry extension field, called the CRLReasonAndHold extension, is defined. The following ASN.1 type is proposed for use in this field: CRLReasonAndHold ::= SEQUENCE { reasonCode CRLReason DEFAULT other, expirationDate UTCTime OPTIONAL, -- present if reasonCode is certHold instructionCode HoldInstruction DEFAULT id-none } CRLReason ::= ENUMERATED { other (0), keyCompromise (1), caCompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), certHoldRelease (7), ... } HoldInstruction ::= OBJECT IDENTIFIER This extension is noncritical. The reason code may be used by applications to decide, based on local policy, how to react to posted revocations. The hold option allows a certificate to be placed in a suspended state. It may later be reinstated by posting a certHoldRelease entry on a CRL (for one issue cycle only) then removing the entry from the next CRL issue, thereby returning the certificate to its original (valid) state. 9. Issues - Other Extensions Potential requirements have also been raised for: a) extensions to CRLs to better support their use for nonrepudiation purposes; b) optional CRL formats to provide for breaking the revocation information from one CA into multiple parts for operational purposes. National Body comment is invited on the need for extensions in these areas, and technical proposals are solicited. Further discussion of these topics follows. 9.1 Non-repudiation Extensions A revocation certificate contains, for each revoked certificate, the date when revocation occurred. This date is insufficient to solve some disputes because, assuming the worst, all signatures issued during the validity period of the certificate have to be considered invalid. However, in a commercial environment, it may be important for a user that a signed document is recognized as valid even in the case where the key used to sign the message has been lost. The presence of another date within the user certificate can assist in solving this problem - the date when the user was still sure that his key was not compromised. All signatures issued by the user before this date will be recognized by the user as valid. The presence of this optional date within a CRL entry might be made mandatory when the key of the certificate is used for a non-repudiation service. Non-repudiation aside, this date might be useful for other purposes. For example, suppose a buyer sends a signed order to a supplier on date x. The supplier is working for a considerable period on filling the order then receives a revocation notice for the buyer's certificate. If the supplier knows that the revocation does not apply to the original order date (date x), then his reaction will be different than if it possibly did apply to that date. (For example, the supplier may decide differently on whether or not to continue processing the order.) 9.2 CRL Partitioning The CRL from one CA can become extremely large and, for reasons of operational practicality and efficiency, it may be highly desirable to be able to distribute CRL information in smaller pieces than the complete CRL. Three possible ways of segmenting CRLs for distribution purposes have been proposed, each of which is useful in different operational environments: a) Segment a CRL into different serial number ranges. Then, if a certificate user needs to check if the certificate with serial number n has been revoked, he need only obtain, validate, and check the CRL segment covering that serial number. In some operational environments this may greatly improve efficiency over having to obtain, validate, and check the complete CRL. As an alternative to pure number-range matching, other matching rules might be considered. b) Distribute CRL information in the form of delta files, i.e., each (signed) delta file contains the new CRL entries since the preceding distribution. This mode of operation is efficient for environments in which CRL information is maintained in trusted storage at the certificate-using system. c) Segment a CRL into separate signed parts on the basis of revocation reason. For example, there may be separate CRL parts for compromise revocations, for routine (e.g., job change, name change, or address change) revocations, and for "suspend" revocations. This may make the CRL processing task much more efficient for certain applications. The extensions project can potentially provide specifications supporting any, or all, of the above partitioning options. Appendix A: Examples of Use of Identified Policies and CA Constraints (This Appendix is included for information only and is not a part of this Standard.) A.1 Example 1: Use of Name and Algorithm Constraints Suppose the U.S. Government is prepared to cross-certify the Canadian government with respect to the U.S. policy "US/Can- Trade", conditional upon: a) only entities with names under country=Canada may be certified in chains via a Canadian government CA; b) all certificates must be signed with the algorithm "Digital-Signature-Algorithm". The U.S. government root CA could issue a certificate for a Canadian government CA with the following AuthorityConstraints field: AuthorityConstraints = PolicyId = "US/Can-Trade" ConstraintSet = { ChainNameConstraint = {subtree under country=Canada}, ChainAlgorithmConstraint = "Digital-Signature-Algorithm" } A.2 Example 2: Cross-Certification with Compatible Policies Suppose the following cross-certification scenario is required between the Canadian and U.S. governments: a) a Canadian government CA wishes to certify use of US government signatures with respect to a Canadian policy called "Can/US-Trade"; b) the U.S. government has a fully-compatible policy called "US/Can-Trade", which operates only within the domain of CAs of "US-Dept-of-Commerce"; c) the Canadian government wants to apply safeguards that require the first U.S. CA to explicitly declare its support for the "US/Can-Trade" policy and that prohibit any subsequent cross-certifying outside the "US-Dept-of- Commerce" naming domain. The Canadian government root CA could issue a certificate for a "US-Dept-of-Commerce" CA with the following AuthorityConstraints field: AuthorityConstraints = PolicyId = "Can/US-Trade" ConstraintSet ={ ChainNameConstraint = "US-Dept-of-Commerce", CertExplicitPolicy = required, NextPolicy = "US/Can-Trade" } A.3 Example 3: Use of NextCertConstraints Option Consider the scenario of Example 2 but, to minimize administrative complexity, the Canadian government does not directly certify the "US-Dept-of-Commerce" CA. The two governments only maintain cross-certificates between their respective root CAs, which are trusted for all government business but do not necessarily recognize all identifiable policies. The Canadian government root CA could issue a certificate for the US government root CA with the following AuthorityConstraints field: AuthorityConstraints = PolicyId = "Can/US-Trade" ConstraintSet = { ChainNameConstraint = {subtree under "US-Dept-of-Commerce"}, CertExplicitPolicy = notRequired, NextPolicy = "US/Can-Trade", NextCertConstraints = { CertExplicitPolicy = required } } A.4 Example 4: Cross-Certification into RFC1422 Structure Suppose a commercial organization, ABC Corp., wants to cross- certify into the RFC1422 infrastructure, recognizing either of the PCAs "PQR Commercial PCA" and "XYZ Commercial PCA" as being consistent with the local policy "ABC Commercial Protection". Two possible approaches follow. Firstly, the ABC Corp. CA could issue certificates for each of the PCAs. The certificate for the "PQR Commercial PCA" CA, for example, would have the following AuthorityConstraints field: AuthorityConstraints = PolicyId = "ABC Commercial Protection" ConstraintSet = { ChainNameSubordConstraint = subordinateToCA } Alternatively, if the ABC Corp. preferred to certify the PEM IPRA's public key, it could issue a certificate for the IPRA with the following AuthorityConstraints field: AuthorityConstraints = PolicyId = "ABC Commercial Protection" ConstraintSet = { CertNameConstraint = {either of the precise names "PQR Commercial PCA" or "XYZ Commercial PCA"}, NextCertConstraints = { ChainNameSubordConstraint = subordinateToCA } } u  F| V~~z - P  E  S  B  k   < g # _ 9 f g  -   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11918; 30 Aug 94 19:48 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11914; 30 Aug 94 19:48 EDT Received: from relay.tis.com by CNRI.Reston.VA.US id aa18821; 30 Aug 94 19:48 EDT Received: from magellan.tis.com(199.171.39.124) by relay via smap (V1.3) id sma029165; Tue Aug 30 19:36:00 1994 Received: from magellan.tis.com by magellan.TIS.COM id aa11464; 30 Aug 94 19:33 EDT Received: from sol.tis.com by magellan.TIS.COM id aa11435; 30 Aug 94 19:07 EDT Received: from x400gate.bnr.ca(192.58.194.73) by relay via smap (V1.3) id sma028730; Tue Aug 30 19:08:35 1994 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 30 Aug 1994 18:16:09 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 30 Aug 1994 18:15:58 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 30 Aug 1994 18:16:00 -0400 Date: Tue, 30 Aug 1994 22:15:58 +0000 X400-Originator: /dd.id=1618054/g=warwick/i=ws/s=ford/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.352:30.07.94.22.15.58] X400-Content-Type: P2-1984 (2) Content-Identifier: fw:Re: X.509 ... Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "warwick (w.s.) ford" X-Orig-Sender: "warwick (w.s.) ford" Message-Id: <"29353 Tue Aug 30 18:16:00 1994"@bnr.ca> To: pem-dev@tis.com, osf-sec-wg@apollo.hp.com Subject: fw:Re: X.509 Certificate Extension Proposal Thanks for pointing this out. My mail environment has appended some junk to the message. Please ignore the several characters following the last curly bracket. I shall not repost. Warwick ---forwarded-message----> from: balenson@tis.com (BNR400) subject: Re: X.509 Certificate Extension Proposal > Here is text of the Working Draft of proposed X.509 certificate > extensions in ISO. > > Warwick Ford Warwick- The end of your text appears to have been garbled, at least as it appears on PEM-DEV. You might want to check it out, and possibly repost. Thanks, -DB David M. Balenson Trusted Information Systems, 3060 Washington Rd., Glenwood, MD 21738 USA balenson@tis.com; tel 301.854.6889; fax 301.854.5363