Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16984; 2 Feb 93 17:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16977; 2 Feb 93 17:09 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24582; 2 Feb 93 17:09 EST Received: by TIS.COM (4.1/SUN-5.64) id AA16134; Tue, 2 Feb 93 17:09:32 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA16105; Tue, 2 Feb 93 17:09:30 EST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA22792; Tue, 2 Feb 1993 17:08:55 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA15602; Tue, 2 Feb 93 17:08:48 EST Message-Id: <9302022208.AA15602@smiley.mitre.org.sit> Date: Tue, 2 Feb 1993 17:10:17 -0500 To: Mark Crispin Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" X-Sender: shirey@smiley.mitre.org Subject: Re: Protocol Action: Privacy Enhanced Mail to Proposed Standard Cc: "Vinton G. Cerf" , pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com Your message was iteresting. I am curious why PEM is totally useless to you. Don't you send any plain ascii mail messages? Please explain, but spare the flame.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18368; 2 Feb 93 17:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18361; 2 Feb 93 17:50 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa26291; 2 Feb 93 17:50 EST Received: by TIS.COM (4.1/SUN-5.64) id AA18436; Tue, 2 Feb 93 17:50:02 EST Received: from Tomobiki-Cho.CAC.Washington.EDU by TIS.COM (4.1/SUN-5.64) id AA18430; Tue, 2 Feb 93 17:49:58 EST Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA02113; Tue, 2 Feb 93 14:49:27 -0800 Date: Tue, 2 Feb 1993 14:11:50 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Crispin Subject: Re: Protocol Action: Privacy Enhanced Mail to Proposed Standard To: "Robert W. Shirey" Cc: "Vinton G. Cerf" , pem-dev@tis.com In-Reply-To: <9302022208.AA15602@smiley.mitre.org.sit> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orig-Sender: pem-dev-relay@tis.com On Tue, 2 Feb 1993 17:10:17 -0500, Robert W. Shirey wrote: > Your message was iteresting. I am curious why PEM is totally useless to > you. Don't you send any plain ascii mail messages? Please explain, but > spare the flame. Yes, I send plain ASCII messages, but I am also committed to MIME and *all* my outgoing messages are in MIME format. The great majority of them are, of course, single-segment messages of type TEXT/PLAIN (not all are in US-ASCII charset though). So, interaction with MIME is a requirement for me. I can't have two parallel efforts, one supporting PEM, the other MIME. One or the other has to give way. For a number of reasons, MIME won. Also, there seems to be some indifference on the part of PEM to distributed processing of mail. The suggestions I've heard for MIMEifying PEM tend to be of the form of putting a PEM wrapper over a MIME message. This, to me, seems to be backwards. I see a message as a collection of objects, each of which may have its own authentication/privacy status, bundled together under the auspices of MIME. If any message-wide authentication/privacy is done, it should be of the MIME bundle and not of the data within the bundles. Let me explain the reason why. Suppose you are using a remote server e-mail architecture; I'm thinking especially of IMAP but these arguments are equally valid for DMSP, NNTP, and to a lesser extent POP. In the brave new world of MIME you can have relatively large messages with many attachments; additionally, some of the attachments may be external to the message. MIME is a lot of great things, but one thing it isn't is easy to parse on machines with limited resources such as PC's. I have written MIME parsing code for a PC, but it is quite slow compared to the parsing code that can run on a Unix machine with adequate memory. Here's what ties these two strings together: suppose the remote server took on part of the overhead. Specifically, suppose it parsed the MIME structure so that the client already had a parse tree of the message, without actually having received any part of the message itself. Now, add to this supposition a capability retrieve specific MIME segments of the message, using the parse tree as guidance, without necessarily having to retrieve any other part of the message. The attractiveness of this for small machines such as PC's or Mac's is obvious. Less obvious, but still important, is the attractiveness of this for machines which sit behind relatively low bandwidth links (e.g. V.32b/V42b SLIP links). This isn't just pie-in-the-sky dreaming. It's existing, deployed technology. The indifference of the present form of PEM to MIME takes a serious toll here. If a MIMEgram must be encapsulated within PEM in its entirety, a distributed system engineer is faced with the choice of doing the de-PEM step in the server -- thus subjecting the plaintext to interception or alteration -- or of downloading the whole thing to the client and forcing it to do both the de-PEM and de-MIME steps. Note that we've established that de-MIMEing may be unacceptably expensive for a small machine; yet now we're adding an extra burden. I'm afraid that until there is some better attention on the part of PEM to MIME -- and to the needs of distributed architecture -- PEM isn't going to be useful in my community. PEM would have been great back in 1989. The problem is, PEM has been delayed for a long time and the e-mail community has moved beyond the infrastructure that PEM covers. I understand and sympathize greatly with the desire to get any version of PEM out rather than have it drag on forever. PEM has suffered enough with charges of being vapor (albeit from sources we can ignore). However, I don't see how this version helps. As an implementor, I see this version of PEM as being offered in direct competition to MIME, to the detriment of both. Yet I'm sympathetic to both. If I contrive to acquire this viewpoint, it does not take a PhD in psychology to envision what other, less sympathetic, implementors will think. If a ``MIME vs PEM'' fight develops, I would have to lobby on behalf of MIME and against PEM as a matter of self-preservation. Please consider the strong negative impact that a non-MIME version of PEM may have on the e-mail community in general, and on the large and growing MIME community in particular. MIME has become a fundamental part of e-mail for this community; it is not ``just'' a multi-media mail format. What I would like to see is a fully integrated PEM as a layer on top of MIME. Although ``MESSAGE/PEM'' as a content type is an attractive kludge, it does not deal with the distributed processing problem I've outlined above. I would like to continue to distribute processing as before, but without compromising any PEM integrity or putting a burdensome processing load on clients that are inadequate to the task. That is, I would like to see PEM encoding of a MIME structure tree. This requires quite a bit more intelligence in PEM than merely treating a message as plain ASCII. These are not new viewpoints; I've stated them before. The more time passes, the more alarmed I'm becoming at the prospect that we're seeing PEM become a solution for the previous decade's problems. Please consider these points. I hope it wasn't too inflammatory. Regards, Mark Crispin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19730; 2 Feb 93 19:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19723; 2 Feb 93 19:03 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa27955; 2 Feb 93 19:03 EST Received: by TIS.COM (4.1/SUN-5.64) id AA21393; Tue, 2 Feb 93 19:03:20 EST Received: from HAPPY.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA21387; Tue, 2 Feb 93 19:03:18 EST Message-Id: <9302030003.AA21387@TIS.COM> To: Mark Crispin Cc: "Robert W. Shirey" , "Vinton G. Cerf" , pem-dev@tis.com Subject: Re: Protocol Action: Privacy Enhanced Mail to Proposed Standard In-Reply-To: Your message of Tue, 02 Feb 93 14:11:50 -0800. Date: Tue, 02 Feb 93 19:03:13 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker X-Orig-Sender: pem-dev-relay@tis.com Mark, Let me chime in here. You and I have had at least a portion of this discussion. I found the discussion useful before. I believe it had the right effect, although perhaps not everything you would wish. Let me respond to some of the points you make. >> Yes, I send plain ASCII messages, but I am also committed to MIME >> and *all* my outgoing messages are in MIME format. The great >> majority of them are, of course, single-segment messages of type >> TEXT/PLAIN (not all are in US-ASCII charset though). >> >> So, interaction with MIME is a requirement for me. I can't have >> two parallel efforts, one supporting PEM, the other MIME. One or >> the other has to give way. For a number of reasons, MIME won. >> >> Also, there seems to be some indifference on the part of PEM to >> distributed processing of mail. The suggestions I've heard for >> MIMEifying PEM tend to be of the form of putting a PEM wrapper over >> a MIME message. This, to me, seems to be backwards. I see a >> message as a collection of objects, each of which may have its own >> authentication/privacy status, bundled together under the auspices >> of MIME. If any message-wide authentication/privacy is done, it >> should be of the MIME bundle and not of the data within the >> bundles. As you're probably aware, Ned Freed, Marshall Rose and I have a draft specification for the integration of PEM with MIME. Let me call this MIME-with-PEM for purposes of discussion. MIME-with-PEM permits authentication and/or encryption at all levels of a message. This is a necessary capability. In the case of a compound message, i.e. a message with multiple parts, it will be the *sender* who chooses whether to apply authentication and/or encryption to some or all of the parts and/or to the entire message. In some cases, this will mean that the user will receive a message in which authentication and/or encryption is applied to the entire message. There really isn't any easy way around this effect. There is a legitimate and useful interpretation for every possible combination. For particular scenarios, it may be desirable to steer the users toward signing individual body parts instead of an overall message, but that cannot be a rule that's imposed on the entire design. Having said all that, there is one important design goal that we have adopted within the MIME-with-PEM specification. In the case of authentication, we want the interior structure of the message to be visible and parseable even if the authenticity and integrity are not checked. That is, if someone sends you a compound message which is signed on the outside, you will be able to read the components without checking the signature of the entire message. Of course, this means there's a security vulnerability, but transparency seems worth the risk. The same idea does not -- and should not -- apply to encrypted messages. If I send you an encrypted message, you'll have to decrypt it before you can see any portion of the interior. >> >> Let me explain the reason why. Suppose you are using a remote >> server e-mail architecture; I'm thinking especially of IMAP but >> these arguments are equally valid for DMSP, NNTP, and to a lesser >> extent POP. In the brave new world of MIME you can have relatively >> large messages with many attachments; additionally, some of the >> attachments may be external to the message. >> >> MIME is a lot of great things, but one thing it isn't is easy to >> parse on machines with limited resources such as PC's. I have >> written MIME parsing code for a PC, but it is quite slow compared >> to the parsing code that can run on a Unix machine with adequate >> memory. >> >> Here's what ties these two strings together: suppose the remote >> server took on part of the overhead. Specifically, suppose it >> parsed the MIME structure so that the client already had a parse >> tree of the message, without actually having received any part of >> the message itself. Now, add to this supposition a capability >> retrieve specific MIME segments of the message, using the parse >> tree as guidance, without necessarily having to retrieve any other >> part of the message. >> >> The attractiveness of this for small machines such as PC's or Mac's >> is obvious. Less obvious, but still important, is the >> attractiveness of this for machines which sit behind relatively low >> bandwidth links (e.g. V.32b/V42b SLIP links). This isn't just >> pie-in-the-sky dreaming. It's existing, deployed technology. >> >> The indifference of the present form of PEM to MIME takes a serious >> toll here. If a MIMEgram must be encapsulated within PEM in its >> entirety, a distributed system engineer is faced with the choice of >> doing the de-PEM step in the server -- thus subjecting the >> plaintext to interception or alteration -- or of downloading the >> whole thing to the client and forcing it to do both the de-PEM and >> de-MIME steps. Note that we've established that de-MIMEing may be >> unacceptably expensive for a small machine; yet now we're adding an >> extra burden. As noted above, nothing forces the sender to encapsulate the entire message, but nothing prevents the sender from doing so. If the sender does encapsulate the entire message -- and particularly if the sender encrypts the entire message -- then the entire message has to be processed to undo the enchancements. In your model, one possibility is to have the server be trusted with the user's private key. It can then handle any verification or encryption. If you don't want to trust the server with the private key -- which is probably the safest idea -- then you really don't have much choice. This is not a question of hostility toward the client-server model; this is a fundamental limitation in the client-server model with the assumption that the server is untrusted. >> >> I'm afraid that until there is some better attention on the part of >> PEM to MIME -- and to the needs of distributed architecture -- PEM >> isn't going to be useful in my community. PEM would have been >> great back in 1989. The problem is, PEM has been delayed for a >> long time and the e-mail community has moved beyond the >> infrastructure that PEM covers. >> >> I understand and sympathize greatly with the desire to get any >> version of PEM out rather than have it drag on forever. PEM has >> suffered enough with charges of being vapor (albeit from sources we >> can ignore). However, I don't see how this version helps. >> >> As an implementor, I see this version of PEM as being offered in >> direct competition to MIME, to the detriment of both. Yet I'm >> sympathetic to both. If I contrive to acquire this viewpoint, it >> does not take a PhD in psychology to envision what other, less >> sympathetic, implementors will think. If a ``MIME vs PEM'' fight >> develops, I would have to lobby on behalf of MIME and against PEM >> as a matter of self-preservation. There really isn't a MIME vs PEM fight in progress. Integration of PEM with MIME is an extremely high priority activity. It's the central effort within the PEM WG, and it's high on our implementation agenda. >> >> Please consider the strong negative impact that a non-MIME version >> of PEM may have on the e-mail community in general, and on the >> large and growing MIME community in particular. MIME has become a >> fundamental part of e-mail for this community; it is not ``just'' a >> multi-media mail format. I think you're proposing that anything, PEM or anything else, that isn't embedded in MIME is harmful. I think that goes too far. MIME is a very good thing, and I believe it is succeeding nicely. It doesn't need to be aided by holding back other efforts. In order for MIME to completely dominate the e-mail ecology, it just has to be better than everything else and occupy its niche for the right length of time. >> What I would like to see is a fully integrated PEM as a layer on >> top of MIME. Although ``MESSAGE/PEM'' as a content type is an >> attractive kludge, it does not deal with the distributed processing >> problem I've outlined above. I would like to continue to >> distribute processing as before, but without compromising any PEM >> integrity or putting a burdensome processing load on clients that >> are inadequate to the task. That is, I would like to see PEM >> encoding of a MIME structure tree. This requires quite a bit more >> intelligence in PEM than merely treating a message as plain ASCII. Hmm... I'm not sure I understand this proposal. I suspect I disagree, but I'm certainly willing to listen. How about fleshing this out in the style of the current I-D so we can see the specific alternative you have in mind? >> >> These are not new viewpoints; I've stated them before. The more >> time passes, the more alarmed I'm becoming at the prospect that >> we're seeing PEM become a solution for the previous decade's >> problems. Please consider these points. I hope it wasn't too >> inflammatory. Actually, you're assuming PEM solves problems in a neat and clean way. Spend some time looking at the export issues and at the U.S. Government's insistence on alternate algorithms and you may find the MIME integration issue is small potatoes. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11892; 9 Feb 93 20:46 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11885; 9 Feb 93 20:46 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa29042; 9 Feb 93 20:46 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06744; Tue, 9 Feb 93 20:46:34 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06737; Tue, 9 Feb 93 20:46:33 EST Message-Id: <9302100146.AA06737@TIS.COM> Reply-To: James M Galvin To: pem-dev@tis.com Subject: ["Joyce K. Reynolds": RFC1421 on Privacy Enhancement for Electronic Mail] Date: Tue, 09 Feb 93 20:46:25 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,UYBpHzD3lP5l8Wi2DzdTRPWoag3lQ7NrqmF0U+cfykK VCKx5jxPRR9CaWaddI5QobfpA4hsIVA12ZpsPzmyo9g== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info@tis.com". - ------- Forwarded Message Message-ID: <199302092257.AA29999@zephyr.isi.edu> Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey@isi.edu Date: Tue, 09 Feb 93 14:56:08 PST Subject: RFC1421 on Privacy Enhancement for Electronic Mail - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1421: Title: Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures Author: J. Linn Mailbox: 104-8456@mcimail.com Pages: 42 Characters: 103,894 Obsoletes: RFC 1113 This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This document is the outgrowth of a series of meetings of the Privacy and Security Research Group (PSRG) of the Internet Research Task Force (IRTF) and the PEM Working Group of the Internet Engineering Task Force (IETF). The author would like to thank the members of the PSRG and the IETF PEM WG, as well as all participants in discussions on the "pem-dev@tis.com" mailing list, for their contributions to this document. This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND rfc1421.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1421.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11905; 9 Feb 93 20:46 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11898; 9 Feb 93 20:46 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa29052; 9 Feb 93 20:46 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06782; Tue, 9 Feb 93 20:47:06 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06769; Tue, 9 Feb 93 20:47:04 EST Message-Id: <9302100147.AA06769@TIS.COM> Reply-To: James M Galvin To: pem-dev@tis.com Subject: ["Joyce K. Reynolds": RFC1422 on Certificate-Based Key Management] Date: Tue, 09 Feb 93 20:46:59 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,SdwD9j3bEJftgUxTr4Oxa2StKH4giFOjvS5ey4B578J pEMgQYtXDXhzX4eNKmV23FducCqWXBaOHL2zvK7jK5A== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info@tis.com". - ------- Forwarded Message Message-ID: <199302092258.AA00113@zephyr.isi.edu> Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey@isi.edu Date: Tue, 09 Feb 93 14:56:39 PST Subject: RFC1422 on Certificate-Based Key Management - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1422: Title: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management Author: S. Kent Mailbox: kent@BBN.COM Pages: 32 Characters: 86,085 Obsoletes: RFC 1114 This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This memo is the outgrowth of a series of meetings of the Privacy and Security Research Group of the Internet Research Task Force (IRTF) and the Privacy-Enhanced Electronic Mail Working Group of the Internet Engineering Task Force (IETF). The author would like to thank the members of the PSRG and the PEM WG for their comments and contributions at the meetings which led to the preparation of this document. The author also would like to thank contributors to the PEM-DEV mailing list ("pem-dev@tis.com") who have provided valuable input which is reflected in this memo. This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND rfc1422.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1422.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11919; 9 Feb 93 20:46 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11912; 9 Feb 93 20:46 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa29068; 9 Feb 93 20:47 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06817; Tue, 9 Feb 93 20:47:37 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06809; Tue, 9 Feb 93 20:47:35 EST Message-Id: <9302100147.AA06809@TIS.COM> Reply-To: James M Galvin To: pem-dev@tis.com Subject: ["Joyce K. Reynolds": RFC1423 on PEM: Algorithms, Modes and Identifiers] Date: Tue, 09 Feb 93 20:47:29 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,SZBZEw1TKP4Mj68wVUb3t1uGaXKAhRfRScqDkULDMuG WRwco4HpFmpJxuBUzPLhysLhi0Rn6D9yG+YxFnZE4bA== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info@tis.com". - ------- Forwarded Message Message-ID: <199302092258.AA00118@zephyr.isi.edu> Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey@isi.edu Date: Tue, 09 Feb 93 14:56:45 PST Subject: RFC1423 on PEM: Algorithms, Modes and Identifiers - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1423: Title: Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers Author: D. Balenson Mailbox: balenson@tis.com Pages: 14 Characters: 33,277 Obsoletes: RFC 1115 This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This document is the outgrowth of a series of meetings of the Privacy and Security Research Group (PSRG) of the Internet Research Task Force (IRTF) and the PEM Working Group of the Internet Engineering Task Force (IETF). This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND rfc1423.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1423.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11933; 9 Feb 93 20:47 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11926; 9 Feb 93 20:47 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa29086; 9 Feb 93 20:47 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06845; Tue, 9 Feb 93 20:47:59 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06837; Tue, 9 Feb 93 20:47:57 EST Message-Id: <9302100147.AA06837@TIS.COM> Reply-To: James M Galvin To: pem-dev@tis.com Subject: ["Joyce K. Reynolds": RFC1424 on Key Certification and Related Services] Date: Tue, 09 Feb 93 20:47:53 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,ev2s1woCBNlMsuccJpIUAAEuV9gQZZs5hbHG3fCPYxb hxSChOjQSJRO3cIf6/GyzyJYhRt7jZDc9VH+YLuPMeg== - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info@tis.com". - ------- Forwarded Message Message-ID: <199302092258.AA00165@zephyr.isi.edu> Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: "Joyce K. Reynolds" To: IETF-Announce:;@IETF.CNRI.Reston.VA.US cc: jkrey@isi.edu Date: Tue, 09 Feb 93 14:56:52 PST Subject: RFC1424 on Key Certification and Related Services - - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1424: Title: Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services Author: B. Kaliski Mailbox: burt@rsa.com Pages: 9 Characters: 17,537 Updates/Obsoletes: none This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM): key certification, certificate- revocation list (CRL) storage, and CRL retrieval. This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. This document is the product of many discussions at RSA Data Security, at Trusted Information Systems, and on the mailing list. This document is the product of the Privacy-Enhanced Electronic Mail Working Group. This is now a Proposed Standard Protocol. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND rfc1424.txt - - --OtherAccess Content-Type: Message/External-body; name="rfc1424.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - - --OtherAccess-- - - --NextPart-- - ------- End of Forwarded Message -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09006; 11 Feb 93 11:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08995; 11 Feb 93 11:48 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa15148; 11 Feb 93 11:49 EST Received: by TIS.COM (4.1/SUN-5.64) id AA00617; Thu, 11 Feb 93 11:49:35 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA00611; Thu, 11 Feb 93 11:49:33 EST Received: by IETF.CNRI.Reston.VA.US id aa07253; 11 Feb 93 10:50 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04303; 11 Feb 93 9:08 EST To: pem-dev@tis.com Subject: Interesting little note in message Date: Thu, 11 Feb 93 09:07:49 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302110908.aa04303@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Hey, how about that note saying finger to get the public key! Vint ------- Forwarded Message Message-Id: <9302110139.AA23011@netcom.netcom.com> Date: Wed, 10 Feb 1993 17:39:21 -0800 To: "Vinton G. Cerf" From: Joichi Ito X-Sender: jito@netcom1.netcom.com Subject: Re: Technology Policy and Information Infrastructure >Dear Internauts and friends, > >I have been invited to testify before the US House Subcommittee on >Technology on the subject of technology policy and information >intrastructure. To prepare my testimony, it would be helpful to >have SHORT (please!) comments, suggestions, "bullets" as input, >so that Internet Society ideas and considerations can be represented >(or, at the least, offer some national and international perspective >on a matter of global importance). > >If you want to send something on this point, please send it ONLY >to: vcerf@cnri.reston.va.us. DO NOT SEND IT TO THE ENTIRE LIST OF >ADDRESSEES (or they will do something terrible to me). > >Many thanks for letting me disturb your busy mailboxes, and thanks >in advance for your ideas. I'm sorry to disturb YOUR inbox, but I am working with the Ministry of Post and Telecom and NTT in technology policy and information infrastructure. I was wondering if it will be possible to get a copy of your testimony so that I may refer to it when addressing the Japanese. Any thoughts you many have about such issues with respect to Japan would also be of great interest. TIA. Joichi Ito - -- true name closest email address: closest fax number: <415-854-5093> current physical location: next physical location: date of next trip: <2/18> - -- finger jito@netcom.com for PGP 2.0 Public Key and RIPEM Public Key - -- ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11601; 11 Feb 93 13:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11594; 11 Feb 93 13:36 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa19163; 11 Feb 93 13:37 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06092; Thu, 11 Feb 93 13:37:44 EST Received: from tsx-11.MIT.EDU by TIS.COM (4.1/SUN-5.64) id AA06083; Thu, 11 Feb 93 13:37:42 EST Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA10483; Thu, 11 Feb 93 13:37:09 EST Date: Thu, 11 Feb 93 13:37:09 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Theodore Ts'o Message-Id: <9302111837.AA10483@tsx-11.MIT.EDU> To: "Vinton G. Cerf" Cc: pem-dev@tis.com In-Reply-To: Vinton G. Cerf's message of Thu, 11 Feb 93 09:07:49 -0500, <9302110908.aa04303@IETF.CNRI.Reston.VA.US> Subject: Re: Interesting little note in message Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 X-Orig-Sender: pem-dev-relay@tis.com Date: Thu, 11 Feb 93 09:07:49 -0500 From: "Vinton G. Cerf" Hey, how about that note saying finger to get the public key! Yes, for PGP and RIPEM keys. :-) Speaking of which, what's the current status of bootstrapping the PEM hierarchy? This list has been relatively quiet for quite some time..... - Ted   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11721; 11 Feb 93 13:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11713; 11 Feb 93 13:41 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa19257; 11 Feb 93 13:41 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06227; Thu, 11 Feb 93 13:41:25 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA06218; Thu, 11 Feb 93 13:41:23 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11612; 11 Feb 93 13:37 EST To: Theodore Ts'o Cc: pem-dev@tis.com Subject: Re: Interesting little note in message In-Reply-To: Your message of "Thu, 11 Feb 93 13:37:09 EST." <9302111837.AA10483@tsx-11.MIT.EDU> Date: Thu, 11 Feb 93 13:37:16 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302111337.aa11612@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Td, now we got the attorneys looking at contracts..urgh. vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04675; 12 Feb 93 9:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04662; 12 Feb 93 9:36 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa02382; 12 Feb 93 9:36 EST Received: by TIS.COM (4.1/SUN-5.64) id AA13100; Fri, 12 Feb 93 09:36:31 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA13094; Fri, 12 Feb 93 09:36:29 EST Message-Id: <9302121436.AA13094@TIS.COM> To: "Vinton G. Cerf" Cc: pem-dev@tis.com Subject: Re: Interesting little note in message In-Reply-To: Your message of Thu, 11 Feb 93 09:07:49 -0500. <9302110908.aa04303@IETF.CNRI.Reston.VA.US> Date: Fri, 12 Feb 93 09:35:44 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Vint, I guess one could take advantage of FINGER as another means of making certificates (vs. just public keys) available. We should keep in mind that many sites do not run FINGER because of security concerns, so this is not a universal means of providing this info, nor does it work in environments where only email traffic is carried, but it might provide another interim directory facility for certificates. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01050; 15 Feb 93 11:30 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01041; 15 Feb 93 11:30 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa02484; 15 Feb 93 11:30 EST Received: by TIS.COM (4.1/SUN-5.64) id AA15813; Mon, 15 Feb 93 11:30:48 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA15807; Mon, 15 Feb 93 11:30:46 EST Message-Id: <9302151630.AA15807@TIS.COM> To: pem-dev@tis.com Cc: vcerf@CNRI.Reston.VA.US, postel@isi.edu, crocker@tis.com Subject: Internet Certificate Issuers Registry (ICIR) Date: Mon, 15 Feb 93 11:30:45 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker X-Orig-Sender: pem-dev-relay@tis.com As noted last week, the PEM specifications have finally attained Proposed Standard status and been published as RFCs 1421 through 1424. This a major milestone and everyone should be congratulated. One detail that has evolved since the documents were submitted for advancement is a change of name for the top level. As agreed, the Internet Society is operating the top level of the hierarchy. ISOC legal counsel recommended against using a name involving the term "policy " on the grounds that it connotes that the ISOC would be setting assurance policies. The new name for the root is Internet Certificate Issuers Registry (ICIR) To emphasize the point made above, this change reflects only a desire to clarify that the role of the ISOC is to register and administer the hierarchy. Policy decisions regarding assurance and business issues are left to the various PCAs. On behalf of everyone involved, I apologize for not getting the revised name into the RFC prior to publication. When the RFCs come up for review for advancement to Draft Stadnard, this and other editorial matters can be fixed. Meanwhile, please adjust your documentation and presentations to reflect this new name. Thanks, Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10262; 19 Feb 93 12:39 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10255; 19 Feb 93 12:39 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24781; 19 Feb 93 12:39 EST Received: by TIS.COM (4.1/SUN-5.64) id AA25461; Fri, 19 Feb 93 12:40:01 EST Received: from darmstadt.gmd.de (erde.darmstadt.gmd.de) by TIS.COM (4.1/SUN-5.64) id AA25444; Fri, 19 Feb 93 12:39:42 EST Received: from libra.darmstadt.gmd.de by darmstadt.gmd.de (4.1/GMDDA-MS2.0) id AA03591; Fri, 19 Feb 93 18:38:55 +0100 Date: Fri, 19 Feb 93 18:38:55 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Wolfgang Schneider Message-Id: <9302191738.AA03591@darmstadt.gmd.de> To: crocker@tis.com Subject: PEM Test Service Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com Steve, GMD (the German National Research Center for Mathematics and Computer Science) has recently finished its own PEM implementation. The first use of this (Unix-based) software will be in a national pilot with German university administrations, and in a European pilot as part of the EC-funded PASSWORD project where we participate together with University College London, INRIA (France), U Cambridge and a number of commercial partners. Later we plan a deployment of PEM to the German R & D community. Since we consider it essential to have full interoperability with US sites in the future, we are interested to find a reference test site for our implementation. Is there any support from TIS for that purpose? I know that messages from TIS to pem-dev sometimes are in PEM format, but this is not sufficient. We would need to receive PEM messages produced by the test site in various formats (including PEM-Encrypted, and including certificates) which can be verified and decrypted by us, and to receive notifications whether the test site was able to verify and decrypt messages generated by us. Once ICIR is being operational, we are interested to join the Internet certification tree. I can imagine that GMD runs a PCA for the German R & D. However, the necessary organizational, technical and other prerequisites to do so ar not clear to me. I will be attending the next IETF in Columbus. I would appreciate if we could find an opportunity to discuss these issues during the meeting. Best regards Wolfgang Schneider   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02385; 20 Feb 93 9:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02378; 20 Feb 93 9:52 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa13437; 20 Feb 93 9:52 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06509; Sat, 20 Feb 93 09:52:57 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA06501; Sat, 20 Feb 93 09:52:55 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02348; 20 Feb 93 9:47 EST To: Wolfgang Schneider Cc: crocker@tis.com, pem-dev@tis.com Subject: Re: PEM Test Service In-Reply-To: Your message of "Fri, 19 Feb 93 18:38:55 +0100." <9302191738.AA03591@darmstadt.gmd.de> Date: Sat, 20 Feb 93 09:47:33 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302200947.aa02348@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Wolfgang, I will look for you at IETF. ISOC is working on the draft agreement it would make with the PCAs it registers. The current proposal is to request an annual payment of $5,000 for registration to cover the costs of operating the registration functions (and CRL database management). I will add you to the list of people to whom the draft should go for comment. Vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03061; 20 Feb 93 11:31 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03054; 20 Feb 93 11:31 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa16799; 20 Feb 93 11:31 EST Received: by TIS.COM (4.1/SUN-5.64) id AA08682; Sat, 20 Feb 93 11:31:25 EST Received: from bells.cs.ucl.ac.uk by TIS.COM (4.1/SUN-5.64) id AA08674; Sat, 20 Feb 93 11:31:22 EST Message-Id: <9302201631.AA08674@TIS.COM> Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 20 Feb 1993 16:30:17 +0000 To: vcerf@CNRI.Reston.VA.US Cc: password@cs.ucl.ac.uk, crocker@tis.com, pem-dev@tis.com Subject: Re: PEM Test Service Date: Sat, 20 Feb 93 16:30:12 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: P.Kirstein@cs.ucl.ac.uk X-Orig-Sender: pem-dev-relay@tis.com Vint, We have largely completed our PEM implementation, and are starting tests first internally, and then with TIS. I would like to establish a PCA. This will certainly act for UK traffic, and may act for other European projects like PASSWORD. Could you inform me on what I must do to become registered. I may have a particular problem. It could be desirable for me to pay my annual costs during March, though it may take a longer period to complete the full Policy documents - since I do not know quite what is involved. Please advise. Both Wolfgang Schneider and I will be at the IETF, and expect to wish to discuss the matter further there with you and Steve. Peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03310; 20 Feb 93 12:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03303; 20 Feb 93 12:28 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa19448; 20 Feb 93 12:28 EST Received: by TIS.COM (4.1/SUN-5.64) id AA09842; Sat, 20 Feb 93 12:28:26 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA09834; Sat, 20 Feb 93 12:28:24 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03294; 20 Feb 93 12:27 EST To: P.Kirstein@cs.ucl.ac.uk Cc: password@cs.ucl.ac.uk, crocker@tis.com, pem-dev@tis.com Subject: Re: PEM Test Service In-Reply-To: Your message of "Sat, 20 Feb 93 16:30:12 GMT." <9302201631.AA08674@TIS.COM> Date: Sat, 20 Feb 93 12:27:39 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302201227.aa03294@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Peter, happy to work with you on this - at IETF. We are feeling our way forward - PCA policies can cover a fairly wide latitude - I think almost any reasonable policy will do as long as it is clearly delineated. The current proposal is to invoice PCAs $5,000 per year to defray the cost of operating the registry and the CRL database. The other matter of Distinguished Name uniqueness (especially for residential certificates) looks more difficult and I hope that somehow the X.500 infrastructure will emerge to assure that all DNs are unique. We can certainly assure that the PCA distinguished names are unique and probably manage a small database of CA DNs manually. (or, preferably, by means of an email-enabled application). Vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04296; 20 Feb 93 15:10 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04289; 20 Feb 93 15:10 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa26360; 20 Feb 93 15:10 EST Received: by TIS.COM (4.1/SUN-5.64) id AA13863; Sat, 20 Feb 93 15:10:38 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA13857; Sat, 20 Feb 93 15:10:36 EST Message-Id: <9302202010.AA13857@TIS.COM> To: Wolfgang Schneider , P.Kirstein@cs.ucl.ac.uk Cc: pem-dev@tis.com, crocker@tis.com, tmail@tis.com Subject: Re: PEM Test Service In-Reply-To: Your message of Fri, 19 Feb 93 18:38:55 +0100. <9302191738.AA03591@darmstadt.gmd.de> Date: Sat, 20 Feb 93 15:10:31 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker X-Orig-Sender: pem-dev-relay@tis.com Wolfgang and Peter, Thanks for your notes. I congratulate you both on your efforts and look forward to interoperability tests. Wolfgang, In answer to your question, yes, we do have a limited amount of time to help test your implementation. We'll be happy to send you various encrypted, mic-clear and mic-only messages. I suspect the test will be mutual :-) With respect to validating each other's certificates, I see three possibilities, all of which are reasonable. 1. We can sign you up under our PCA. For a short period of time, we are operating our PCA free of charge and will be happy to issue a certificate to you with whatever distinguished name is appropriate. Once your organization has a certificate signed by our PCA, you issue certificates under it and automatically be part of the hierarchy. (We are not yet part of the official Internet hierarchy because the Internet Society has not yet set up operation of the hierarchy yet. When it does, we will immediately ask for a certificate signed by it and then put our entire hierarchy into the Internet hierarchy.) One downside of this approach is we will have to sign up each site separately. We'll be happy to do this, but it will mean an extra step for each site in Germany that you want to get signed up. 2. We can cross-certify with you. This is outside the published protocol, but easily accomplished nonetheless. We have structured our software to support a certain style of cross-certification. If you do the same, we can exchange certificates and add them to the list of authoritative "treetops". 3. You can become a full scale PCA and sign up with the ISOC. Peter and Wolfgang, There is a fledgling PCA Council which currently includes RSADSI, TIS, the ISOC and MIT. (MIT is providing name resolution service and CRL software for the PCA operation.) The PCA Council focuses on operational issues involved in coordinating name clashes, clarifying rules for policies, coordination with the ISOC, etc. So far, we've had just one conference call and the emphasis during that call was on the steps necessary to get the ISOC hierarchy up and running. Whenever you're ready, designate a representative and we'll add you to the list. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04557; 20 Feb 93 15:42 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04549; 20 Feb 93 15:42 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa28006; 20 Feb 93 15:42 EST Received: by TIS.COM (4.1/SUN-5.64) id AA14619; Sat, 20 Feb 93 15:42:22 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA14611; Sat, 20 Feb 93 15:42:20 EST Message-Id: <9302202042.AA14611@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Sat, 20 Feb 1993 12:41:14 -0800 To: "Vinton G. Cerf" Cc: P.Kirstein@cs.ucl.ac.uk, password@cs.ucl.ac.uk, crocker@tis.com, pem-dev@tis.com, wahl@atlas.arc.nasa.gov Subject: Re: PEM Test Service In-Reply-To: Your message of "Sat, 20 Feb 1993 12:27:39 EST." <9302201227.aa03294@IETF.CNRI.Reston.VA.US> Date: Sat, 20 Feb 1993 12:41:11 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com >The current proposal is to invoice PCAs $5,000 per year >to defray the cost of operating the registry and the >CRL database. The other matter of Distinguished Name >uniqueness (especially for residential certificates) >looks more difficult and I hope that somehow the >X.500 infrastructure will emerge to assure that all >DNs are unique. We can certainly assure that the PCA >distinguished names are unique and probably manage >a small database of CA DNs manually. (or, preferably, >by means of an email-enabled application). I'll preface this message by saying that I've not been in the thick of the PEM development effort, but with that I aside... I should certainly hope that PEM DNs match those used in the existing X.500 hierarchy. The NADF (in NADF 175 -- see RFC 1417) has done a lot of good work to ensure that organizations have a reasonable way of registering themselves in logical positions in the DIT, while having the capability to list themselves at other locations. Were the PEM DNs to be different than those suggested by the NADF (and used to some extent in the current X.500 pilot), there would yet another layer of mapping and confusion to work through. My X.500 entry (US, NASA, ARC, Peter Yee) already contains an X.509 certificate (produced by OSISEC, UCL's X.509 implementation). I really don't want to see PEM, when it is not backed by X.500, using DNs that are not likely to have a basis in X.500 reality. Assuming that there will be a trend to store certificates in X.500 directories (and this is already happening at a variety of sites), I would not really wish to see the need to re-cast or map PEM DNs to match existing directory structure. For a small investment in effort by PCAs now, the transition to X.500 directory storage of certificates could be quite easy. Comments? Flames? :-) -Peter Yee yee@atlas.arc.nasa.gov   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04639; 20 Feb 93 15:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04632; 20 Feb 93 15:48 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa28427; 20 Feb 93 15:48 EST Received: by TIS.COM (4.1/SUN-5.64) id AA14902; Sat, 20 Feb 93 15:48:19 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA14894; Sat, 20 Feb 93 15:48:18 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04589; 20 Feb 93 15:45 EST To: Peter Yee Cc: P.Kirstein@cs.ucl.ac.uk, password@cs.ucl.ac.uk, crocker@tis.com, pem-dev@tis.com, wahl@atlas.arc.nasa.gov Subject: Re: PEM Test Service In-Reply-To: Your message of "Sat, 20 Feb 93 12:41:11 PST." <9302202042.AA14611@TIS.COM> Date: Sat, 20 Feb 93 15:45:23 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302201545.aa04589@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Peter, I may be naive here, but I assume if someone comes with a valid X.500 DN, it will be OK to use - provided it is also consistent with the constraints of PEM regarding the DNs in certificates signed by CAs - hierarchical org name binding (to oversimplify). Vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06423; 20 Feb 93 23:35 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06416; 20 Feb 93 23:35 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa13819; 20 Feb 93 23:35 EST Received: by TIS.COM (4.1/SUN-5.64) id AA26306; Sat, 20 Feb 93 23:35:15 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA26275; Sat, 20 Feb 93 23:35:13 EST Message-Id: <9302210435.AA26275@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Sat, 20 Feb 1993 20:34:20 -0800 To: "Vinton G. Cerf" Cc: password@cs.ucl.ac.uk, pem-dev@tis.com Subject: Re: PEM Test Service In-Reply-To: Your message of "Sat, 20 Feb 1993 15:45:23 EST." <9302201545.aa04589@IETF.CNRI.Reston.VA.US> Date: Sat, 20 Feb 1993 20:34:10 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com >I may be naive here, but I assume if someone comes with >a valid X.500 DN, it will be OK to use - provided it is >also consistent with the constraints of PEM regarding >the DNs in certificates signed by CAs - hierarchical >org name binding (to oversimplify). Well, yes and no. Yes, a valid DN could be used, and technology wise, there is nothing to stop one from doing so. However, it terms of legally representation, you would probably do well not to choose certain DNs. For example, should you try to register CNRI as US, NY, IBM, a large, blue corporation might be upset. NADF 175 deals with this potential naming problem by having X.500 DNs match the names assigned under the civil naming hierarchy. Since this hierarchy already attempts to provide uniqueness, X.500 uniqueness falls out naturally. In addition, this has the added benefit of reducing the need for legal action to defend the validity of a name. As I mentioned in my previous message, this does not preclude listing of a name in many places in the DIT, but through constructed names (multi-attribute RDNs), uniqueness is preserved. I don't think that PEM constraints on DNs really address this situation. Certainly, the choice of names is not important to PEM (my org could be NASA, National Aeronautics and Space Administration, or even NASA Ames Research Center). However, in terms of what goes in the DIT, I use the name US, National Aeronautics and Space Administration which follows the Congressional act which created NASA. I don't use NASA because it is possibly ambiguous. To use a Stan Kelly-Bootle example, IBM could be Irish Business Machines. -Peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10731; 21 Feb 93 17:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10724; 21 Feb 93 17:04 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa07921; 21 Feb 93 17:04 EST Received: by TIS.COM (4.1/SUN-5.64) id AA22473; Sun, 21 Feb 93 17:04:54 EST Received: from inet-gw-2.pa.dec.com by TIS.COM (4.1/SUN-5.64) id AA22438; Sun, 21 Feb 93 17:02:11 EST Received: by inet-gw-2.pa.dec.com; id AA19268; Sun, 21 Feb 93 14:00:18 -0800 Received: by us1rmc.bb.dec.com; id AA28513; Sun, 21 Feb 93 16:57:48 -0500 Message-Id: <9302212157.AA28513@us1rmc.bb.dec.com> Received: from tpsys.enet; by us1rmc.enet; Sun, 21 Feb 93 16:57:54 EST Date: Sun, 21 Feb 93 16:57:54 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: e-mail is the ethernet of the 90s 21-Feb-1993 1700 To: schneiw@darmstadt.gmd.de, p.kirstein@cs.ucl.ac.uk Cc: crocker@tis.com, pem-dev@tis.com, taylor@tpsys.enet.dec.com Apparently-To: pem-dev@tis.com, crocker@tis.com, schneiw@darmstadt.gmd.de, p.kirstein@cs.ucl.ac.uk Subject: Re: PEM Test Service X-Orig-Sender: pem-dev-relay@tis.com Wolfgang and Peter, I would be happy to send you encrypted, mic-clear and mic-only messages as this would help test my VMS implementation. Please let me know how you wish to proceed. Mike Taylor   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11206; 21 Feb 93 21:05 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11199; 21 Feb 93 21:05 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa14691; 21 Feb 93 21:05 EST Received: by TIS.COM (4.1/SUN-5.64) id AA28247; Sun, 21 Feb 93 21:05:50 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA28241; Sun, 21 Feb 93 21:05:49 EST Message-Id: <9302220205.AA28241@TIS.COM> To: Peter Yee Cc: "Vinton G. Cerf" , P.Kirstein@cs.ucl.ac.uk, password@cs.ucl.ac.uk, pem-dev@tis.com, wahl@atlas.arc.nasa.gov Subject: Re: PEM Test Service In-Reply-To: Your message of Sat, 20 Feb 93 12:41:11 -0800. <9302202042.AA14611@TIS.COM> Date: Sun, 21 Feb 93 21:05:48 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker X-Orig-Sender: pem-dev-relay@tis.com Peter, Speaking for the TIS PCA, we make a reasonable effort to have the DNs conform to the X.500 and NADF rules. We probably don't know eveerything there is to know about these rules, and we have already encountered resistance from some clients who want DNs that clearly fall outside of the NADF guidelines. We'll support and sensible approach that leads to consistency in the use of DNs. With respect to NASA's DN, are you aware of a MITRE study in progress that is looking at, among other things, how U.S. government entities should be assigned DNs? Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18837; 22 Feb 93 12:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18828; 22 Feb 93 12:12 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa07898; 22 Feb 93 12:12 EST Received: by TIS.COM (4.1/SUN-5.64) id AA29281; Mon, 22 Feb 93 12:12:39 EST Received: from gateway.mitre.org by TIS.COM (4.1/SUN-5.64) id AA29275; Mon, 22 Feb 93 12:12:37 EST Received: from cutter.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA01225; Mon, 22 Feb 93 12:11:57 -0500 Date: Mon, 22 Feb 93 12:11:57 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ella P. Gardner" Message-Id: <9302221711.AA01225@gateway.mitre.org> To: password@cs.ucl.ac.uk, pem-dev@tis.com Subject: Directory Names Cc: epg@gateway.mitre.org X-Orig-Sender: pem-dev-relay@tis.com I'd just like to remind folks of the ANSI registration service in the US, which is referenced in the NADF naming Scheme (DF-446, SD-5, January 13, 1993). "An organization is said to have national-standing if it is chartered (created and named) by the US Congress. An example of such an organization might be a national laboratory. There is no other entity which is empowered by government to confer national-standing on organizations. However, ANSI maintains an alphanumeric nameform registration for organizations, and this will be used as the public directory service basis for conferring national-standing on private organizations." For names of US Government agencies, some have suggested that the United States Government Manual be used. Ella Gardner MITRE   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20967; 22 Feb 93 14:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20960; 22 Feb 93 14:37 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa12744; 22 Feb 93 14:37 EST Received: by TIS.COM (4.1/SUN-5.64) id AA14002; Mon, 22 Feb 93 14:37:52 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA13976; Mon, 22 Feb 93 14:37:49 EST Message-Id: <9302221937.AA13976@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Mon, 22 Feb 1993 11:37:13 -0800 To: Stephen D Crocker Cc: password@cs.ucl.ac.uk, pem-dev@tis.com Subject: Re: PEM Test Service In-Reply-To: Your message of "Sun, 21 Feb 1993 21:05:48 EST." <9302220205.AA28241@TIS.COM> Date: Mon, 22 Feb 1993 11:37:06 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com >Speaking for the TIS PCA, we make a reasonable effort to have the DNs >conform to the X.500 and NADF rules. We probably don't know >everything there is to know about these rules, and we have already >encountered resistance from some clients who want DNs that clearly >fall outside of the NADF guidelines. I'd agree that you can't please everyone. My point is simply that if there is any desire to make use of X.500 to support PEM certficates, early harmonization is surely a lot easier than doing things later. >With respect to NASA's DN, are you aware of a MITRE study in progress >that is looking at, among other things, how U.S. government entities >should be assigned DNs? I'm not aware of the MITRE study in particular, although I know there are those who would like to see o=gov under c=US. I'm not a great fan of extra levels of indirection. -Peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23435; 22 Feb 93 17:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23428; 22 Feb 93 17:12 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa18424; 22 Feb 93 17:12 EST Received: by TIS.COM (4.1/SUN-5.64) id AA01191; Mon, 22 Feb 93 17:12:01 EST Received: from bells.cs.ucl.ac.uk by TIS.COM (4.1/SUN-5.64) id AA01184; Mon, 22 Feb 93 17:11:57 EST Message-Id: <9302222211.AA01184@TIS.COM> Received: from auchentoshan.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Feb 1993 22:10:20 +0000 To: pem-dev@tis.com Cc: Christian Huitema , password@cs.ucl.ac.uk Subject: Re: PEM Test Service In-Reply-To: Your message of "Mon, 22 Feb 93 11:57:31 PST." Date: Mon, 22 Feb 93 22:10:18 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Williams X-Orig-Sender: pem-dev-relay@tis.com >From: Peter Yee >Subject: Re: PEM Test Service >Date: Mon, 22 Feb 1993 11:57:31 -0800 >>The less obvious thing is that once you have done this, you don't need X.500. >>More precisely, as you derive the name and its uniqueness from an external >>source, you have a right to use it which is absolutely independant of its >>registration in one or another X.500 DN hierarchy. > >I agree here, although my argument is along the lines, that as long as you >are going to use X.500, you should attempt to make it work well. NADF 175 >(which Marshall Rose tells me is called SD 5 now) does not solve all the >problems that might exist in X.500. It does try to solve some of them, within >the constraints of X.500. > >>Another consequence is that, as X.500 imports the hierarchical structure from >>the "real world", it also imports a drastic constraint on how the X.500 >>infrastructure can be layered -- essentially loosing all possible degrees of >>liberty. To put it shortly, using the same token as "your legal name" and "the >>database key" does not help building the data base. Failure to separate these >>two is probably a fatal flaw that is going to doom the X.500 effort. > >It loses some liberty. X.500 was hierarchical to start with. I don't believe >that X.500 will necessarily die from its less flexible naming scheme, although >I wouldn't say it is the best. > >>Don't misundersand me. I am NOT saying that PEM should not use "legal >>looking" names. Just that the linkage with X.500 will probably have to be cut >>some day. > >If and when there is replacement for X.500 services for PEM, we can talk about >it. In the meantime, let's make use of X.500. I merely wish to head off >problems that occur should DNs be assigned without regard to name clashes (and >in the context of X.500). > -Peter Given PEM services are now to be deployed on a large scale - as we WILL start to do in March, come what may - then it must be on the basis of the accumulated experience of practical naming in the X.500 Directory Services now in operation. The underlying naming policy was debated, proposal-standardized, and founded upon the sense of SD 6 for the USA (Canada and US of Mexico??). Now Stef received a rather stern slap from various members of this WG ; he did predict however back in Boston that this conflict would eventually arise. It did seem that even limiting the debate to the practical naming issues of now, vs yet more theory of naming, the praxis of massive DN registration was being brushed under the carpet by PEM-WG. We ought to encourage him to bring his experience on this back to bear, if my first statement is not consensual.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26856; 23 Feb 93 1:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26849; 23 Feb 93 1:22 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa04038; 23 Feb 93 1:22 EST Received: by TIS.COM (4.1/SUN-5.64) id AA18817; Tue, 23 Feb 93 01:23:03 EST Received: from ics.uci.edu by TIS.COM (4.1/SUN-5.64) id AA18811; Tue, 23 Feb 93 01:23:01 EST Received: from nma.com by q2.ics.uci.edu id aa18210; 22 Feb 93 22:19 PST Received: from localhost by odin.nma.com id aa08984; 22 Feb 93 22:08 PST To: pem-dev@tis.com, password@cs.ucl.ac.uk Subject: Re: PEM Test Service In-Reply-To: Your message of Mon, 22 Feb 1993 22:10:18 +0000. <9302222211.AA01184@TIS.COM> Reply-To: Stef=pem@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Date: Mon, 22 Feb 1993 22:08:04 -0800 Message-Id: <8982.730447684@nma.com> X-Orig-Sender: pem-dev-relay@tis.com Thanks Peter for your encouragement -- See below... Extracted from Peter Williams message <9302222211.AA01184@TIS.COM> : ... }Given PEM services are now to be deployed on a large scale - as we WILL }start to do in March, come what may - then it must be on the basis of the }accumulated experience of practical naming in the X.500 Directory }Services now in operation. The underlying naming policy was debated, }proposal-standardized, and founded upon the sense of SD 6 for the USA }(Canada and US of Mexico??). } }Now Stef received a rather stern slap from various members of this WG; }he did predict however back in Boston that this conflict would }eventually arise. It did seem that even limiting the debate to the }practical naming issues of now, vs yet more theory of naming, the }praxis of massive DN registration was being brushed under the carpet by }PEM-WG. } }We ought to encourage him to bring his experience on this back to bear, }if my first statement is not consensual. So, to continue... I agree entirely with Peter Yee's points about PEM alignment with SD-5. I made this very argument at the PEM WG meeting in Boston, and was told by Robert Shirey ("a rather stern slap") that I should read the PEM documents before I make any comments. He has reminded me of this in public on several occasions, along with others in the PEM WG. My claim is that PEM WG participants should read SD-5 and find a way to align with it, whether I read their bloody documents or not. I entirely fail to see what my reading their documents has to do with a suggestion that they read and align with some document they are ignoring. I can easily tell that they are ignoring SD-5 without reading their bloody documents, and that is what this is all about. As Marshall and I have pointed out, X.500 is primarily designed for "listing" entries, and SD-5 clearly points this out. I think SD-5 states the case very well. People who disagree with SD-5 are ignoring its logic, at their peril. I will agree that on occasion, the X-500 DIT might incidentally do double duty as a listing and registration service (ala DNS), but even then, the right to use any given name must be subject to civil naming authority legalities, as appropriate in each sovereign nation. PEM and friends appear to want to establish a new (different) global name registration system in parallel with the existing national civil naming infrastructures. Legally, this simply cannot be arranged. The courts in every country will eventually resolve any dispute no matter who makes claims to the contrary. SD-5 embodies this principle. Also, this is why I wrote the A=IMX ID to say that the IANA will simply record whatever it is instructed to record by whatever authority controls the use of any given registered name. No challenge periods, et al. So, who owns the problem of resolving this PEM civil/non-civil naming disagreement. Well, neither PEM nor X.500 can subvert the law of the land in any sovereign nation, so X.500 and PEM had best get into alignment with the civil naming authorities, (else PEM and X.500 will kill X.500;-). It cannot be that X.500 will be killed by alignment with the existing Civil Naming Infrastructure. The real truth is: "X.500 cannot successfully operate outside of it." So, PEM and X.500 developers/users own the problem of alignment with the civil naming infrastructure, ala SD-5. (It is certainly not the other way around;-). Enjoy! With this missive, I leave you to choose your lots. Please feel free to ignore me, again, at your peril. (None of my clients are supporting me to help save you, so you are on your own;-). Cheers...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03222; 23 Feb 93 10:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03215; 23 Feb 93 10:02 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa11728; 23 Feb 93 10:02 EST Received: by TIS.COM (4.1/SUN-5.64) id AA03654; Tue, 23 Feb 93 10:02:26 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA03642; Tue, 23 Feb 93 10:02:23 EST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA16831; Tue, 23 Feb 1993 10:01:41 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA04859; Tue, 23 Feb 93 10:01:22 EST Message-Id: <9302231501.AA04859@smiley.mitre.org.sit> Date: Tue, 23 Feb 1993 10:03:57 -0500 To: Einar Stefferud Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" X-Sender: shirey@smiley.mitre.org Subject: Re: PEM Test Service Cc: pem-dev@tis.com, egardner%mdf@mwunix.mitre.org X-Orig-Sender: pem-dev-relay@tis.com (1) I confess my ignorance, Mr. Stefferud, as I am sure others will! Until you informed us all in your last message, I was completely unaware that that "PEM and friends [and I certainly count myself one of those] appear to want to establish a new (different) global name registration system in parallel with the existing national civil naming infrastructures." Honestly, I naively thought that *someone else* (like those North American Forum guys or NIST or somebody) was going eventually going to get around to *registering* names, and that PEM would then *use* those names by incorporating them in X.509 certificates. However, it is not my fault! I was misled by the evil cabal of PEM RFC authors, who concealed their nefarious and disruptive registration plan by not mentioning it in the PEM RFCs. To see that I am blameless, you only have to read the few parts of the RFCS that deal with naming. (To make that reading easy, I have reproduced those parts below.) See there, they never mentioned what they are planning!! Now that you know that most of the PEM WG is innocent, surely you will enlighten us by explaining (in small words, sans rhetoric) just what the heck is going on and where PEM has gone wrong. After that, we will be ready to receive your new Internet-Draft text of the RFC modifications that we need to ratify to put ourselves back on the side of the angels. (2) I am told that in some WGs of the IETF, it has gotten to the point where they are forced to give the following kinds of instruction if they want to get anything done: "If you have been working on implementing or modifying the current draft text, sit in front. If you have read the current draft text *before* the meeting and have constructive comments, sit in the middle and take your turn. If you have not read the draft before coming to this meeting or are just learning what it is all about, sit in back and shut up." Since I am near-sighted, I don't want to sit in back. So, although we really don't deserve it after our Philistine behavior, please provide a copy (or at least the reference and electronic source) of the document(s) ("SD-5") that you want us to read. The next IETF is fast upon us. We innocents and plotters alike will read your documents; please read ours. In RFC 1421, it is mentioned that: ---------------------------------- 6. User Naming Unique naming of electronic mail users, as is needed in order to select corresponding keys correctly, is an important topic and one which has received (and continues to receive) significant study. . . . The use of user identifiers unrelated to the hosts on which the users' mailboxes reside offers generality and value. X.500 distinguished names, as employed in the certificates of the recommended key management infrastructure defined in RFC 1422, provide a basis for such user identification. As directory services become more pervasive, they will offer originators a means to search for desired recipients which is based on a broader set of attributes than mailbox specifiers alone. Future work is anticipated in integration with directory services, particularly the mechanisms and naming schema of the Internet OSI directory pilot activity. In RFC 1422, it is mentioned that: ---------------------------------- 3.1 Scope and Restrictions ... Specifically, the architecture proposes a system in which user (or mailing list) certificates represent the leaves in a certification hierarchy. This certification hierarchy is largely isomorphic to the X.500 directory naming hierarchy, with two exceptions: the IPRA forms the root of the tree (the root of the X.500 DIT is not instantiated as a node), and a number of Policy Certification Authorities (PCAs) form the "roots" of subtrees, each of which represents a different certification policy. ... 3.2 Relation to X.509 Architecture CCITT 1988 Recommendation X.509, "The Directory - Authentication Framework", defines a framework for authentication of entities involved in a distributed directory service. Strong authentication, as defined in X.509, is accomplished with the use of public-key cryptosystems. Unforgeable certificates are generated by certification authorities; these authorities may be organized hierarchically, though such organization is not required by X.509. There is no implied mapping between a certification hierarchy and the naming hierarchy imposed by directory system naming attributes. This document interprets the X.509 certificate mechanism to serve the needs of PEM in the Internet environment. The certification hierarchy proposed in this document in support of privacy enhanced mail is intentionally a subset of that allowed under X.509. This certification hierarchy also embodies semantics which are not explicitly addressed by X.509, but which are consistent with X.509 precepts. An overview of the rationale for these semantics is provided in Section 1. . . . 3.3.4 Subject Name A certificate provides a representation of its subject's identity in the form of a Distinguished Name (DN). The fundamental binding ensured by the key management architecture is that between the public component and the user's identity in this form. A distinguished name is an X.500 directory system concept and if a user is already registered in an X.500 directory, his distinguished name is defined via that registration. Users who are not registered in a directory should keep in mind likely directory naming structure (schema) when selecting a distinguished name for inclusion in a certificate. 3.3.5 Issuer Name A certificate provides a representation of its issuer's identity, in the form of a Distinguished Name. ... 3.4.4.2 Residential CAs . . . Such users can be registered as residential persons and the DN of such a user should be consistent with the attributes of the corresponding X.521 object class. Over time we anticipate that such users will be accommodated by civil government entities who will assume electronic certification responsibility at geographically designated points in the naming hierarchy. Until civil authorities are prepared to issue certificates of this form, residential user CAs will accommodate such users. Because residential CAs may be operated under the auspices of multiple PCAs, there is a potential for the same residential CA DN to be assumed by several distinct entities. This represents the one exception to the rule articulated throughout this document that no two entities may have the same DN. This conflict is tolerated so as to allow residential CAs to be established offering different policies. Two requirements are levied upon residential CAs as a result: (1) residential CAs must employ the residential DN conflict detection database maintained by the IPRA, and (2) residential CAs must coordinate to ensure that they do not assign duplicate certificate serial numbers. 6. Naming Conventions- If the PCA imposes any conventions on DNs used by the CAs it certifies, or by entities certified by these CAs, these conventions must be specified. If any semantics are associated with such conventions, these semantics must be specified. . . . [5] North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, NADF, September 1991. [9] North American Directory Forum, "NADF Standing Documents: A Brief Overview", RFC 1417, NADF, February 1993. In RFCs 1423 and 1424, there is no mention of "naming". ------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07626; 23 Feb 93 13:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07619; 23 Feb 93 13:22 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa20600; 23 Feb 93 13:22 EST Received: by TIS.COM (4.1/SUN-5.64) id AA13933; Tue, 23 Feb 93 13:23:01 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA13926; Tue, 23 Feb 93 13:22:57 EST Message-Id: <9302231822.AA13926@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Tue, 23 Feb 1993 10:21:49 -0800 To: "Robert W. Shirey" Cc: Einar Stefferud , pem-dev@tis.com, egardner%mdf@mwunix.mitre.org Subject: Re: PEM Test Service In-Reply-To: Your message of "Tue, 23 Feb 1993 10:03:57 EST." <9302231501.AA04859@smiley.mitre.org.sit> Date: Tue, 23 Feb 1993 10:21:41 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com Calmly, calmly, folks. We're all big kids now. >Honestly, I naively thought that *someone else* (like >those North American Forum guys or NIST or somebody) was going eventually >going to get around to *registering* names, and that PEM would then *use* >those names by incorporating them in X.509 certificates. The intent of SD-5 is that this won't be necessary (excepting, as Ella Gardner points out, if you wish to register a nationally unique organizational name with ANSI). >Now that you know that most of the PEM WG is innocent, surely you will >enlighten us by explaining (in small words, sans rhetoric) just what the >heck is going on and where PEM has gone wrong. After that, we will be >ready to receive your new Internet-Draft text of the RFC modifications that >we need to ratify to put ourselves back on the side of the angels. I may have misread Stef's message, but I don't think he intends to say (nor do I) that PEM has gone wrong, but that there is a potential for problems later on down the line should PEM and X.500 not be harmonized early on (while it's easy to do). >(2) I am told that in some WGs of the IETF, it has gotten to the point >where they are forced to give the following kinds of instruction if they >want to get anything done: "If you have been working on implementing or >modifying the current draft text, sit in front. If you have read the >current draft text *before* the meeting and have constructive comments, sit >in the middle and take your turn. If you have not read the draft before >coming to this meeting or are just learning what it is all about, sit in >back and shut up." While that sentiment is well-suited in many cases, Stef's comments should not be ignored because he hasn't read the PEM drafts. The material from the PEM RFCs which you quote below does not necessarily indicate that naming problems with respect to X.500 will not occur. The harmonization as suggested below (RFC 1421, Section 6) would occur some time in the future. The reason that I brought up the need for early harmonization is that I don't want either group to have to make major naming changes later on down the line. The 1421 is fine as it stands. Stef and I are just pointing out that some forethought here will be more than useful. >Since I am near-sighted, I don't want to sit in back. So, although we >really don't deserve it after our Philistine behavior, please provide a >copy (or at least the reference and electronic source) of the document(s) >("SD-5") that you want us to read. The next IETF is fast upon us. We >innocents and plotters alike will read your documents; please read ours. NADF 175 (the previous incarnation of SD-5) was submitted as an informational RFC (as you show in your references). The RFC version should be enough to supply the gist of it, though. I've attempted to explain the notion behind SD-5 in a previous message. Perhaps I didn't do so in a clear manner. NADF documents may be also be obtained (in their current form) from ftp.ics.uci.edu, in the mrose/nadf directory. Files are named sd-*.ps. -Peter >Users who are not registered in a directory >should keep in mind likely directory naming structure (schema) when >selecting a distinguished name for inclusion in a certificate. This is particularly important text. Doing something concrete with this suggestion is critical.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08640; 23 Feb 93 14:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08633; 23 Feb 93 14:01 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa22379; 23 Feb 93 14:01 EST Received: by TIS.COM (4.1/SUN-5.64) id AA15947; Tue, 23 Feb 93 14:01:41 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA15941; Tue, 23 Feb 93 14:01:40 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08342; 23 Feb 93 13:53 EST To: Peter Yee Cc: "Robert W. Shirey" , Einar Stefferud , pem-dev@tis.com, egardner%mdf@mwunix.mitre.org Subject: Re: PEM Test Service In-Reply-To: Your message of "Tue, 23 Feb 93 10:21:41 PST." <9302231822.AA13926@TIS.COM> Date: Tue, 23 Feb 93 13:53:36 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302231353.aa08342@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Folks, there are some important features of Distinguished Names which the PEM system currently would like to rely upon - with regard to hierarchical relationships between the DN of the certificate authority and the DNs of the entities whose certificates are signed/issued by the CA. Is there concern that these hierarchical relationships will prove incompatible with previously adopted X.500 distinguished names? vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09535; 23 Feb 93 14:42 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09527; 23 Feb 93 14:42 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa23857; 23 Feb 93 14:42 EST Received: by TIS.COM (4.1/SUN-5.64) id AA20174; Tue, 23 Feb 93 14:41:49 EST Received: from gateway.mitre.org by TIS.COM (4.1/SUN-5.64) id AA20168; Tue, 23 Feb 93 14:41:48 EST Received: from cutter.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA10576; Tue, 23 Feb 93 14:41:13 -0500 Date: Tue, 23 Feb 93 14:41:13 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Ella P. Gardner" Message-Id: <9302231941.AA10576@gateway.mitre.org> To: vcerf@CNRI.Reston.VA.US, yee@atlas.arc.nasa.gov Subject: Re: PEM Test Service Cc: Stef=pem@nma.com, pem-dev@tis.com, shirey@mitre.org X-Orig-Sender: pem-dev-relay@tis.com Well, Rob quoted the text from RFC 1422 as follows: To complete the strategy for ensuring uniqueness of DNs, there is a DN subordination requirement levied on CAs. In general, CAs are expected to sign certificates only if the subject DN in the certificate is subordinate to the issuer (CA) DN. This ensures that certificates issued by a CA are syntactically constrained to refer to subordinate entities in the X.500 directory information tree (DIT), and this further limits the possibility of duplicate DN registration. CAs may sign certificates which do not comply with this requirement if the certificates are "cross-certificates" or "reverse certificates" (see X.509) used with applications other than PEM. This appears to make the CA a registration authority for names. "In general, CAs are expected to sign certificates only if the subject DN in the certificate is subordinate to the issuer (CA) DN." Is this what is meant? Also, In RFC 1422, 3.3.4, saying "listed" rather than "registered" when referring to the Directory would be better. Ella Gardner MITRE   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09932; 23 Feb 93 14:58 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09925; 23 Feb 93 14:58 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24577; 23 Feb 93 14:58 EST Received: by TIS.COM (4.1/SUN-5.64) id AA21456; Tue, 23 Feb 93 14:58:32 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA21449; Tue, 23 Feb 93 14:58:30 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09846; 23 Feb 93 14:56 EST To: "Ella P. Gardner" Cc: yee@atlas.arc.nasa.gov, Stef=pem@nma.com, pem-dev@tis.com, shirey@mitre.org Subject: Re: PEM Test Service In-Reply-To: Your message of "Tue, 23 Feb 93 14:41:13 EST." <9302231941.AA10576@gateway.mitre.org> Date: Tue, 23 Feb 93 14:56:25 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302231456.aa09846@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Ella, I think one can also read this to mean the the CA is constrained as to which certificates it can sign - that doesn't make it a registration authority - one can register elsewhere and then get certificates binding the DN to the public key. Vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09980; 23 Feb 93 15:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09973; 23 Feb 93 15:02 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24759; 23 Feb 93 15:02 EST Received: by TIS.COM (4.1/SUN-5.64) id AA21619; Tue, 23 Feb 93 15:01:59 EST Received: from GOVERNMENT-CENTER.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA21607; Tue, 23 Feb 93 15:01:51 EST Message-Id: <9302232001.AA21607@TIS.COM> Date: Tue, 23 Feb 93 14:57:05 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Lowry To: "Ella P. Gardner" Cc: Stef=pem@nma.com, pem-dev@tis.com, shirey@mitre.org Subject: Re: PEM Test Service X-Orig-Sender: pem-dev-relay@tis.com I would argue that the CA is not a "name registration authority". The functions are not equivalent. John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03252; 24 Feb 93 4:08 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03245; 24 Feb 93 4:08 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa02764; 24 Feb 93 4:08 EST Received: by TIS.COM (4.1/SUN-5.64) id AA20736; Wed, 24 Feb 93 04:08:38 EST Received: from bells.cs.ucl.ac.uk by TIS.COM (4.1/SUN-5.64) id AA20730; Wed, 24 Feb 93 04:08:35 EST Message-Id: <9302240908.AA20730@TIS.COM> Received: from mercury.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Feb 1993 09:06:25 +0000 To: Peter Yee Cc: "Robert W. Shirey" , Einar Stefferud , pem-dev@tis.com, egardner <@mwunix.mitre.org:egardner@mdf> Subject: Re: PEM Test Service In-Reply-To: Your message of "Tue, 23 Feb 93 10:21:41 PST." <9302231822.AA13926@TIS.COM> Date: Wed, 24 Feb 93 09:06:22 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: D F Sadok X-Orig-Sender: pem-dev-relay@tis.com >From: Peter Yee >Subject: Re: PEM Test Service >Date: Tue, 23 Feb 1993 10:21:41 -0800 > >NADF 175 (the previous incarnation of SD-5) was submitted as an informational >RFC (as you show in your references). The RFC version should be enough to >supply the gist of it, though. I've attempted to explain the notion behind >SD-5 in a previous message. Perhaps I didn't do so in a clear manner. >NADF documents may be also be obtained (in their current form) from >ftp.ics.uci.edu, in the mrose/nadf directory. Files are named sd-*.ps. > Is this document the same as the one referenced in Part II of the PEM RFCs in 3.4.2.4. If so then, why wasn't this made available earlier? Jamel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03442; 24 Feb 93 5:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03435; 24 Feb 93 5:22 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa04955; 24 Feb 93 5:22 EST Received: by TIS.COM (4.1/SUN-5.64) id AA22499; Wed, 24 Feb 93 05:21:11 EST Received: from ics.uci.edu by TIS.COM (4.1/SUN-5.64) id AA22492; Wed, 24 Feb 93 05:20:57 EST Received: from nma.com by q2.ics.uci.edu id aa21079; 24 Feb 93 2:15 PST Received: from localhost by odin.nma.com id aa10242; 23 Feb 93 20:33 PST To: "Robert W. Shirey" Cc: pem-dev@tis.com Subject: Re: PEM Test Service In-Reply-To: Your message of Tue, 23 Feb 1993 10:03:57 -0500. <9302231501.AA04859@smiley.mitre.org.sit> Reply-To: Stef=pem@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Date: Tue, 23 Feb 1993 20:33:00 -0800 Message-Id: <10229.730528380@nma.com> X-Orig-Sender: pem-dev-relay@tis.com Hello Robert, et al ... I tire of your condescending discussion. It is really hard to avoid responding in kind. However, since there seems to be a long standing pattern of this kind of abuse in the PEM WG, I will respond to set the record straight from my perspective. In Boston I sat in the back of the room, and I freely admitted that I had not read the documents under discussion, and I did not participate in the discussion until the question of DN handling came up. Then I only proposed that you should look at the NADF naming document for information that would be helpful to anyone trying to deal with DN handling in the context of c=us. You and the WG reacted rather badly. I only spoke up at that point because it was clear from the discussion that no one in the PEM WG had digested the NADF naming document, and that it would be helpful if they did. I figured that if the whole WG is groping for an answer, and if I can help end the grope by accident of being in the room at the right time, then I should offer to help. I respect the concept of expecting participants to have done their homework, but I also respect that concept that outsiders are sometimes able to provide useful suggestions and make useful proposals. You summarily shut me down. Fine by me. You are full grown and all haired over, so you are free to do things as you may wish. So, I left it at that, figuring that sooner or later you might awaken to realize that there was something you may have missed along the way. Regrettably, someone also awakened me and encouraged me to return to the fray. So much for the sleep of innocence... So, now that we have both awakened, I will say: "Good Morning!" "Have you read NADF 175 yet?" "Did you understand it?" Your message suggests you have not read it or do not understand it. NADF 175, as cited in your document, is an early version of what has become NADF SD-5. NADF 175 contains the basic concepts in any case. Later versions refined it and restructured it to make it international instead of c=us specific. Of course, you should get yourself the latest version to read now! I can see from the extracted text you sent in your last message that the PEM WG has not yet understood what the NADF naming document is trying to convey. I might assume the WG has not read the document. Unfortunately, I am no longer participating in NADF (since April '92), and I do not have ready access to information on how to access the latest SD-5 version. Someone in PEM-DEV surely has the access information. Marshall Rose recently put the whole set of NADF SD's out on the net for FTP Anon. Perhaps he can tell you how to get them? I do see RFC1417 contains an overview of the NADF Standing documents: 02/03 14:21PST "Joyce K. Reynold RFC1417 on NADF Standing Documents. Perhaps it will tell you how to get a copy of SD-5. After you have read SD-5, you should ask questions of the current NADF participants (of which I am not one) to get answers and clarify your understanding of how the NADF Naming Scheme uses normal, already in place, c=us civil infrastructure names to form DN values for X.500. As things turn out, virtually any person anywhere in c=us already has a way to get a good serviceable DN without any further action to register somewhere else. This is true for organizational persons and residential persons. This arises out of recognition of the difference between name registration (which is what the civil infrastructure does), and entry listing, which is what X.500 does. I am not going to further enlighten you, beyond saying that it will be very wise for you to read and understand SD-5, and align PEM with it. There are many subtle concepts involved, and you need to read it straight from SD-5 to get them straight. My lectures will not help. BTW, if I must read and understand all your documents in order to get you to take my advice in this matter, then you should proceed at your peril without taking my advice. It is your problem to align PEM with SD-5, if you want to, not mine. Cheers...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05654; 24 Feb 93 9:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05647; 24 Feb 93 9:54 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa13144; 24 Feb 93 9:54 EST Received: by TIS.COM (4.1/SUN-5.64) id AA01802; Wed, 24 Feb 93 09:54:16 EST Received: from darmstadt.gmd.de (erde.darmstadt.gmd.de) by TIS.COM (4.1/SUN-5.64) id AA01759; Wed, 24 Feb 93 09:54:03 EST Received: from libra.darmstadt.gmd.de by darmstadt.gmd.de (4.1/GMDDA-MS2.0) id AA17025; Wed, 24 Feb 93 15:51:52 +0100 Date: Wed, 24 Feb 93 15:51:52 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Wolfgang Schneider Message-Id: <9302241451.AA17025@darmstadt.gmd.de> To: epg@gateway.mitre.org Subject: Re: PEM Test Service Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com > From: epg@gateway.mitre.org (Ella P. Gardner) > To: vcerf@CNRI.Reston.VA.US, yee@atlas.arc.nasa.gov > Subject: Re: PEM Test Service > Cc: Stef=pem@nma.com, pem-dev@TIS.COM, shirey@mitre.org > Sender: pem-dev-relay@TIS.COM > Content-Length: 1105 > > Well, Rob quoted the text from RFC 1422 as follows: > > To complete the strategy for ensuring uniqueness of DNs, there is a > DN subordination requirement levied on CAs. In general, CAs are > expected to sign certificates only if the subject DN in the > certificate is subordinate to the issuer (CA) DN. This ensures that > certificates issued by a CA are syntactically constrained to refer to > subordinate entities in the X.500 directory information tree (DIT), > and this further limits the possibility of duplicate DN registration. > CAs may sign certificates which do not comply with this requirement > if the certificates are "cross-certificates" or "reverse > certificates" (see X.509) used with applications other than PEM. > > This appears to make the CA a registration authority for names. "In > general, CAs are expected to sign certificates only if the subject DN in > the certificate is subordinate to the issuer (CA) DN." Is this what is > meant? > > Ella Gardner > MITRE > RFC 1422 in fact requires a strict relationship between the DIT and the certification tree from a certain level on downwards, and this may create a problem, depending on your view of what certification means. You simply may consider certification as a means to make your DN provable to others. This is what an X.509 certificate technically is: a key-to-DN binding. In an e-mail environment like PEM, DNs are read by human users, and certification just provides you a proof that a sender has the claimed name. What the receiver concludes from that DN is outside the system. As long as certification is only used to be able to provably present DNs to others, it sounds reasonable to link the certification tree to the DIT. I admit that PEM does not require a particular DN structure for user-DNs (nor does it need CAs which are naming authorities for users). It can deal with any DN coming from the real word. But it requires a CA structure which fits to these DNs. In the case that certification is being used for authorization purposes, i.e. when you derive capabilities, access rights or whatever from authen- ticated DNs, that certification structure is too restrictive, in my view. The Directory itself is a good example. If you access a DSA using strong authentication, the DSA will grant or deny you access rights to the DIB which he may derive from your authenticated DN, following an authorization policy. It could also be part of the particular DSA authorization policy, for instance, that your access rights are not derived from your name, but from the name of the issuer of your certificate. I can imagine a lot of applications where X.509-certification is being used to derive capabilities not from your DN, but from the place where you are in the certification tree. For the greatest possible flexibility and a wide-range applicability of the certification infrastructure, I think RFC 1422 style CA naming requirements are an obstacle. The DIT and the certification tree should be independent. In the particular case of my company, for instance, the PEM certification structure would not fit to the certification structure which we have already established. Participating in PEM would mean for us to open up a new certifi- cation line. It is our goal, however, to establish a security infrastructure for our people which is usable in a number of applications, not only in PEM. RFC 1422 tries to solve technical problems through naming conventions which should probably be solved at other places or by other means. Wolfgang Schneider --------------------------------------------------------------------------- German National Research Center Tel +49-6151-869-262 for Computer Science (GMD) Fax +49-6151-869-224 Institute I2 Dolivostr. 15 D-6100 Darmstadt - Germany ---------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06545; 24 Feb 93 10:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06538; 24 Feb 93 10:19 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa14358; 24 Feb 93 10:19 EST Received: by TIS.COM (4.1/SUN-5.64) id AA03081; Wed, 24 Feb 93 10:19:14 EST Received: from GOVERNMENT-CENTER.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA03071; Wed, 24 Feb 93 10:19:11 EST Message-Id: <9302241519.AA03071@TIS.COM> Date: Wed, 24 Feb 93 10:08:36 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Lowry To: Wolfgang Schneider Cc: epg@gateway.mitre.org, pem-dev@tis.com Subject: Re: PEM Test Service X-Orig-Sender: pem-dev-relay@tis.com >In the case that certification is being used for authorization purposes, >i.e. when you derive capabilities, access rights or whatever from authen- >ticated DNs, that certification structure is too restrictive, in my view. It has been a while since I have followed this closely but I believe that PEM certification implies no authorization. PEM certificates are used by PEM solely for the purpose of authenticating identity. What use other applications wish to make of certificates is, of course, up to them. John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07209; 24 Feb 93 10:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07202; 24 Feb 93 10:43 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa15343; 24 Feb 93 10:43 EST Received: by TIS.COM (4.1/SUN-5.64) id AA05129; Wed, 24 Feb 93 10:43:22 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA05123; Wed, 24 Feb 93 10:43:18 EST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA24386; Wed, 24 Feb 1993 10:42:42 -0500 Received: from by smiley.mitre.org.sit (4.1/SMI-4.1) id AB22702; Wed, 24 Feb 93 10:42:27 EST Message-Id: <9302241542.AB22702@smiley.mitre.org.sit> Date: Wed, 24 Feb 1993 10:45:06 -0500 To: Wolfgang Schneider Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" X-Sender: shirey@smiley.mitre.org Subject: Re: PEM Test Service Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com Could you please offer a concrete example of how it "would not fit?"   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07223; 24 Feb 93 10:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07215; 24 Feb 93 10:43 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa15351; 24 Feb 93 10:43 EST Received: by TIS.COM (4.1/SUN-5.64) id AA05122; Wed, 24 Feb 93 10:43:17 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA05114; Wed, 24 Feb 93 10:43:10 EST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA24358; Wed, 24 Feb 1993 10:42:32 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA22702; Wed, 24 Feb 93 10:42:10 EST Message-Id: <9302241542.AA22702@smiley.mitre.org.sit> Date: Wed, 24 Feb 1993 10:44:49 -0500 To: Peter Yee Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" X-Sender: shirey@smiley.mitre.org Subject: Re: PEM Test Service Cc: pem-dev@tis.com, egardner%mdf@mwunix.mitre.org X-Orig-Sender: pem-dev-relay@tis.com Peter, I'm still trying to find out just what in the PEM RFCs, presumably only in RFC 1422, that needs to be "aligned" with SD-5. Would you please try to explain it to me in small words? Mr. Stefferud points out that there are "many subtle concepts" involved, and I obviously don't understand what is going on here. Mostly, I don't understand why anyone would think that "PEM and friends appear to want to establish a new (different) global name registration system in parallel with the existing national civil naming infrastructures." Is this whole thing just a confusion arising from choice of language in RFC 1422?? Ella Gardner suggests that the following paragraph, which is found in RFC 1422 in 3.4.2.2, Ensuring the Uniqueness of Distinguished Names, appears to make the CA a registration authority for names. To complete the strategy for ensuring uniqueness of DNs, there is a DN subordination requirement levied on CAs. In general, CAs are expected to sign certificates only if the subject DN in the certificate is subordinate to the issuer (CA) DN. This ensures that certificates issued by a CA are syntactically constrained to refer to subordinate entities in the X.500 directory information tree (DIT), and this further limits the possibility of duplicate DN registration. CAs may sign certificates which do not comply with this requirement if the certificates are "cross-certificates" or "reverse certificates" (see X.509) used with applications other than PEM. Having worked on PEM for a long time, I know that this does not mean that the PEM infrstructure registers DNs. Names are "registered" somewhere else. The only thing a CA does is bind a name to a public key, and also list CA names in a registry that allows PCAs to avoid duplciation. Is the use of the word "register" the source of all the excitement? I have pulled out of RFC 1422 each piece of text that includes the word fragment "regist": ----- The infrastructure specified in this document establishes a single root for all certification within the Internet, the Internet Policy *Regist*ration Authority (IPRA). [The name IPRA has already been changed for legal reasons. (Steve Crocker, would you remind us of the new name?) Anyway, names are not being registered, just the fact that a particular authority is associated with a particular policy and public key.] Initially, we expect the majority of users will be *regist*ered via organizational affiliation, consistent with current practices for how most user mailboxes are provided. In this sense the *regist*ration is analogous to the issuance of a university or company ID card. [This is just a background discussion of PEM's environment, in which somebody (not us) registers DNs.] [The next use of *regist*er is a little confusing. It means that a PEM user who want a certificate that is not subordinate to an organizational CA can get one. So maybe it should say "who wish to BE ISSUED A CERTIFICATE independent of any organizational certification." Some CAs are expected to provide certification for residential users in support of users who wish to *regist*er independent of any organizational affiliation. Over time, we anticipate that civil government entities which already provide analogous identification services in other contexts, e.g., driver's licenses, may provide this service. For users who wish anonymity while taking advantage of PEM privacy facilities, one or more PCAs will be established with policies that allow for *regist*ration of users, under subordinate CAs, who do not wish to disclose their identities. The architecture describes procedures for *regist*ering certification authorities and users, for generating and distributing certificates, and for generating and distributing CRLs. [The DNs are not being registered. We are just registering that fact that an entity with an (already registered, hopefully) DN is going to be a CA, or that the entity is going to be a PEM user under a certain CA.] A certificate provides a representation of its subject's identity in the form of a Distinguished Name (DN). The fundamental binding ensured by the key management architecture is that between the public component and the user's identity in this form. A distinguished name is an X.500 directory system concept and if a user is already *regist*ered in an X.500 directory, his distinguished name is defined via that *regist*ration. Users who are not *regist*ered in a directory should keep in mind likely directory naming structure (schema) when selecting a distinguished name for inclusion in a certificate. The following sections identify four types of entities within this architecture: users and user agents, the Internet Policy *regist*ration Authority, Policy Certification Authorities, and other Certification Authorities. For each type of entity, this document specifies the procedures which the entity must execute as part of the architecture and the responsibilities the entity assumes as a function of its role in the architecture. [The following is not name registration either.] 3.4.1.2 User *regist*ration Most details of user *regist*ration are a local matter, subject to policies established by the user's CA and the PCA under which that CA has been certified. In general a user must provide, at a minimum, his public component and distinguished name to a CA, or a representative thereof, for inclusion in the user's certificate. (The user also might provide a complete certificate, minus the signature, as described in RFC 1424.) The CA will employ some means, specified by the CA in accordance with the policy of its PCA, to validate the user's claimed identity and to ensure that the public component provided is associated with the user whose distinguished name is to be bound into the certificate. (In the case of PERSONA certificates, described below, the procedure is a bit different.) The certifying authority generates a certificate containing the user's distinguished name and public component, the authority's distinguished name and other information (see Section 3.3) and signs the result using the private component of the authority. [Is the problem that in the foregoing the CA is not required to make sure that the DN provided in the "complete certificate, minus signature" is already properly "registered" somewhere?] 3.4.2 The Internet Policy *regist*ration Authority (IPRA) [Name change aside, no DNs are being registered in this section, only the fact that an entity with a given DN is associated with a given policy and public key.] 3.4.2.1 PCA *regist*ration As part of *regist*ration, each PCA will be required to execute a legal agreement with the IPRA, and to pay a fee to defray the costs of operating the IPRA. Each a PCA must specify its distinguished name. The IPRA will take reasonable precautions to ensure that the distinguished name claimed by a PCA is legitimate, e.g., requiring the PCA to provide documentation supporting its claim to a DN. [Here we point to the fact of a registration outside the PEM certification system] However, the certification of a PCA by the IPRA does not constitute a endorsement of the PCA's claim to this DN outside of the context of this certification system. In support of the uniqueness requirement, the IPRA will establish and maintain a database to detect potential, unintended duplicate certification of CA distinguished names. This database will be made accessible to all PCAs via an email interface. Each entry in this database will consist of a 4-tuple. The first element in each entry is a hash value, computed on a canonical, ASN.1 encoded representation of a CA distinguished name. The second element contains the subjectPublicKey that appears in the CA's certificate. The third element is the distinguished name of the PCA which *regist*ered the entry. The fourth element consists of the date and time at which the entry was made, as established by the IPRA. This database structure provides a degree of privacy for CAs *regist*ered by PCAs, while providing a facility for ensuring global uniqueness of CA DNs certified in this scheme. [Perhaps this last use of *regist*ered could be changed to certified or some other word?] [In the next, we are *regist*ering the fact that a DN has already been taken for use by a CA. Perhaps we could say *list*ing?] In order to avoid conflicts, a PCA should query the database using a CA DN hash value as a search key, prior to certifying a CA. The database will return any entries which match the query, i.e., which have the same CA DN. The PCA can use the information contained in any returned entries to determine if any PCAs should be contacted to resolve possible DN conflicts. If no potential conflicts appear, a PCA can then submit a candidate entry, consisting of the first three element values, plus any entries returned by the query. The database will *regist*er this entry, supplying the time and date stamp, only if two conditions are met: (1) the first two elements (the CA DN hash and the CA subjectPublicKey) of the candidate entry together must be unique and, (2) any other entries included in the submission must match what the current database would return if the query corresponding to the candidate entry were submitted. In support of the uniqueness requirement, the IPRA will establish and maintain a database to detect potential, unintended duplicate certification of CA distinguished names. This database will be made accessible to all PCAs via an email interface. Each entry in this database will consist of a 4-tuple. The first element in each entry is a hash value, computed on a canonical, ASN.1 encoded representation of a CA distinguished name. The second element contains the subjectPublicKey that appears in the CA's certificate. The third element is the distinguished name of the PCA which *regist*ered the entry. The fourth element consists of the date and time at which the entry was made, as established by the IPRA. This database structure provides a degree of privacy for CAs *regist*ered by PCAs, while providing a facility for ensuring global uniqueness of CA DNs certified in this scheme. In order to avoid conflicts, a PCA should query the database using a CA DN hash value as a search key, prior to certifying a CA. The database will return any entries which match the query, i.e., which have the same CA DN. The PCA can use the information contained in any returned entries to determine if any PCAs should be contacted to resolve possible DN conflicts. If no potential conflicts appear, a PCA can then submit a candidate entry, consisting of the first three element values, plus any entries returned by the query. The database will *regist*er this entry, supplying the time and date stamp, only if two conditions are met: (1) the first two elements (the CA DN hash and the CA subjectPublicKey) of the candidate entry together must be unique and, (2) any other entries included in the submission must match what the current database would return if the query corresponding to the candidate entry were submitted. [Finally, does the following subordination requirement contradict or become impossible under the NADF rules? I don't think so. If so, please point out the text for us.] To complete the strategy for ensuring uniqueness of DNs, there is a DN subordination requirement levied on CAs. In general, CAs are expected to sign certificates only if the subject DN in the certificate is subordinate to the issuer (CA) DN. This ensures that certificates issued by a CA are syntactically constrained to refer to subordinate entities in the X.500 directory information tree (DIT), and this further limits the possibility of duplicate DN *regist*ration. CAs may sign certificates which do not comply with this requirement if the certificates are "cross-certificates" or "reverse certificates" (see X.509) used with applications other than PEM. The IPRA also will establish and maintain a separate database to detect potential duplicate certification of (residential) user distinguished names. Each entry in this database will consist of 4- tuple as above, but the first components is the hash of a residential user DN and the third component is the DN of the residential CA DN which *regist*ered the user. This structure provides a degree of privacy for users *regist*ered by CAs which service residential users while providing a facility for ensuring global uniqueness of user DNs certified under this scheme. The same database access facilities are provided as described above for the CA database. Here it is the responsibility of the CAs to coordinate whenever the database indicates a potential conflict and to resolve the conflict prior to (residential) user certification. Users may wish to obtain certificates which do not imply any organizational affiliation but which do purport to accurately and uniquely identify them. Such users can be *regist*ered as residential persons and the DN of such a user should be consistent with the attributes of the corresponding X.521 object class. Over time we anticipate that such users will be accommodated by civil government entities who will assume electronic certification responsibility at geographically designated points in the naming hierarchy. Until civil authorities are prepared to issue certificates of this form, residential user CAs will accommodate such users. The public component needed to validate certificates signed by the IPRA is made available to each user as part of the *regist*ration or via the PEM installation process. Thus a user will be able to validate any PCA certificate immediately. CAs are certified by PCAs, so validation of a CA certificate requires processing a validation path of length two. User certificates are issued by CAs (either immediately subordinate to PCAs or subordinate to other CAs), thus validation of a user certificate may require three or more steps. Local caching of validated certificates by a UA can be used to speed up this process significantly.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07396; 24 Feb 93 11:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07387; 24 Feb 93 11:01 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa15975; 24 Feb 93 11:01 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06420; Wed, 24 Feb 93 11:01:19 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06410; Wed, 24 Feb 93 11:01:17 EST Message-Id: <9302241601.AA06410@TIS.COM> Reply-To: James M Galvin To: pem-dev@tis.com Subject: Re: PEM Test Service In-Reply-To: 's message of Wed, 24 Feb 93 15:51:52 +0100. <9302241451.AA17025@darmstadt.gmd.de> Date: Wed, 24 Feb 93 11:01:06 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBjjCCATgCAQIwDQYJKoZIhvcNAQECBQAwRjELM AkGA1UEBhMCVVMxJDAiBgNVBAoTG1RydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtc zERMA8GA1UECxMIR2xlbndvb2QwHhcNOTIwNzE3MTQwNzM0WhcNOTQwNzE3MTQwN zM0WjBgMQswCQYDVQQGEwJVUzEkMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvb iBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMPSmFtZXMgTS4gR 2FsdmluMFowDQYJKoZIhvcNAQEBBQADSQAwRgJBAMQMw5IxCtHdZfe+oAdrm8mq9 6RjvRfbG8I6Y903VX3ZJysXlWEDB2jYlm5aif6Pds2OdGq9DqNo5+swciLIXvECA QMwDQYJKoZIhvcNAQECBQADQQATTPt6kCH9064K6dlzxZRGxfPUZOGw5R4DpurJx +hpHf5/3SXztgusxGbhv9XU/GezmLvNQDdjwqWCp8g7VpDD Issuer-Certificate: MIIBZTCCAQ8CAQIwDQYJKoZIhvcNAQECBQAwNzELMAkGA 1UEBhMCVVMxKDAmBgNVBAoTH1RydXN0ZWQgSW5mb3JtYXRpb24gU3lzdGVtcyBQQ 0EwHhcNOTIwNzE3MTMyMzI4WhcNOTQwNzE3MTMyMzI4WjBGMQswCQYDVQQGEwJVU zEkMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLE whHbGVud29vZDBaMA0GCSqGSIb3DQEBAQUAA0kAMEYCQQDE+Wmy9YJM1p+NNPBwa GAJWx1FvRNSTNaCa+ZgItM5x3Yl5+BFBIf/QfApcyiaOpFteindkKbryeu4WXd1v C6HAgEDMA0GCSqGSIb3DQEBAgUAA0EAJQZuSuHg+LJy3wCv1YRd1l0eB66UOVDfZ nbdG/u86flC8J/4Y+QaD7DM579sPbAF0Hv7Wv2yaMzlarafMGaibA== MIC-Info: RSA-MD5,RSA,duRqW5oVLyZRl2trlPC/iTyoDx1MOYcwIlF0qQvAN1G jenBJMR+GjqO2qwLYeu0w9E9HpjJrbgoxVpxLjZN+gA== Gentlefolks, This philosophical discussion is interesting, but let's talk about what's working today. The Internet reference implementation is beta testing today, its available today to any qualifying individual/organization (sorry, legal restrictions not subjective ones), and we're dealing with these issues every day. 1. Stef, I take exception to your comment that when you mentioned the NADF 175 document at the Boston IETF no one had read it or understood it. As PEM implementors, we (TIS) most certainly had read it and understood it, including its predecessor. In fact, when determining an organization's distinguished name to be used for PEM, we recommend people read it and even distribute it to them (as RFC 1255) if its convenient for them. 2. Vint and Wolfgang are both correct. RFC 1422 does tightly couple the naming hierarchy with the certification hierarchy. The principal reason for this is a pragmatic one: distinguished names must be unique and unambigous. In the absence of registration services PEM needed a mechanism to satisfy this requirement. Now, we can discuss the choice that was made, and make a motion to use other choices, but let us focus on the technical issue. There will be opportunities to revise the RFC to allow other choices. Wolfgang's observation that the requirements of the RFC are too restrictive for his environment are significant. We need to determine if he's unique or represents a substantial community. Obviously, this will determine the importance of changing the choice made by the current RFC. 3. In beginning our beta testing of TIS/PEM, we had to consider what to do about approving or disapproving an individual's or organization's distinguished name. After much discussion we decided it was very difficult for us to pass judgement on the choice of distinguished names. At most, there were names we knew were wrong but it did not make sense for us to decide what was right. Therefore, what we decided is that we would offer all the advice and guidance we had to the process of choosing a name, but as long as the name was not wrong and it was consistent with the suggestions in RFC 1255 and it was consistent with the PEM requirements in RFC 1422, we would allow it. The caveat we emphasized to all organizations and individuals is that *THEY* are responsible for their distinguished name and how it is used. We reserve the right to tell them their name is wrong at some point in the future and therefore must be changed. Although this sounds harsh it really isn't. We expect that this policy will be an element of all PCA policies. Let face it, we're all learning about distinguished names. There is a culture that needs to be established within the community of the "common man". We should expect change as we gain more experience with this issue. Toward this end, our PCA issues CA certificates with a 3 month validity period. This allows for fairly quick changes to distinguished names, if necessary. Jim - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info@tis.com". -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10561; 24 Feb 93 14:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10554; 24 Feb 93 14:04 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa22105; 24 Feb 93 14:04 EST Received: by TIS.COM (4.1/SUN-5.64) id AA17426; Wed, 24 Feb 93 14:04:42 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA17417; Wed, 24 Feb 93 14:04:39 EST Message-Id: <9302241904.AA17417@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Wed, 24 Feb 1993 11:03:51 -0800 To: "Robert W. Shirey" Cc: pem-dev@tis.com, egardner%mdf@mwunix.mitre.org Subject: Re: PEM Test Service In-Reply-To: Your message of "Wed, 24 Feb 1993 10:44:49 EST." <9302241542.AA22702@smiley.mitre.org.sit> Date: Wed, 24 Feb 1993 11:03:48 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com >I'm still trying to find out just what in the PEM RFCs, presumably only in >RFC 1422, that needs to be "aligned" with SD-5. Would you please try to >explain it to me in small words? Mr. Stefferud points out that there are >"many subtle concepts" involved, and I obviously don't understand what is >going on here. Mostly, I don't understand why anyone would think that >"PEM and friends appear to want to establish a new (different) global name >registration system in parallel with the existing national civil naming >infrastructures." I'll try to explain it. I was not at the Boston IETF, so I'm unfamiliar with the animosity that has developed between some members of the PEM WG and Mr. Stefferud. >Is this whole thing just a confusion arising from choice of language in RFC >1422?? Not as far as I know. I brought up initial comments based on what I had heard during selection of DNs for beta testing of TIS/PEM. Some of the suggested and requested DNs were not in line with what is currently used in the Internet Pilot and what is sugggested by NADF SD-5. >Ella Gardner suggests that the following paragraph, which is found in RFC >1422 in 3.4.2.2, Ensuring the Uniqueness of Distinguished Names, appears to >make the CA a registration authority for names. > > To complete the strategy for ensuring uniqueness of DNs, there is a > DN subordination requirement levied on CAs. In general, CAs are > expected to sign certificates only if the subject DN in the > certificate is subordinate to the issuer (CA) DN. This ensures that > certificates issued by a CA are syntactically constrained to refer to > subordinate entities in the X.500 directory information tree (DIT), > and this further limits the possibility of duplicate DN registration. > CAs may sign certificates which do not comply with this requirement > if the certificates are "cross-certificates" or "reverse > certificates" (see X.509) used with applications other than PEM. >Having worked on PEM for a long time, I know that this does not mean that >the PEM infrstructure registers DNs. Names are "registered" somewhere >else. The only thing a CA does is bind a name to a public key, and also >list CA names in a registry that allows PCAs to avoid duplciation. Is the >use of the word "register" the source of all the excitement? For me, the use of the word "register" is not the source of my "excitement." I will admit that limiting the possibility of duplicate DN registration does seem out of place if the registration is already done outside of the scope of PEM, but again, this is not the issue I was raising. > Initially, we expect the majority of users will > be *regist*ered via organizational affiliation, consistent with current > practices for how most user mailboxes are provided. In this sense > the *regist*ration is analogous to the issuance of a university or > company ID card. >[This is just a background discussion of PEM's environment, in which >somebody (not us) registers DNs.] Yes, but it does not (at this point) constrain someone from setting up a DN registry that is not aligned with the current X.500 practices. I used to be a student at UC Berkeley. I could have had a DN of, say, US, UCB, Peter Yee. What about University of Colorado, Boulder? The point is that if my org DN is aligned with SD-5, I have no such problem. This is not precisely a PEM problem (you're right, PEM shouldn't be in the "registration" business), but a problem of ensuring that when PEM chooses to align to a registration authority, that it chooses the "right" authority. I've been suggesting that since X.500 is expected to play a large role in certificate management and retrieval, that PEM choose to align to X.500 DNs (as used or suggested in the current NADF documents and the Internet Pilot). Without naming name, I've heard of a case where an organization wished to use its DNS name as part of its DN. Use, it would have been a unique DN. Yes, the portion of the DN that had to be unique would have been registered with a naming authority. But it would not have fit in well with what we are doing with X.500. That's one of the situations I wish to avoid. By being up front about selecting DNs and DN registration authorities, PEM can avoid problems down the line. >[The next use of *regist*er is a little confusing. It means that a PEM >user who want a certificate that is not subordinate to an organizational CA >can get one. So maybe it should say "who wish to BE ISSUED A CERTIFICATE >independent of any organizational certification." Yes, that would help to ensure that CAs don't get into the registration business unnecessarily. > Some CAs are expected to provide certification for residential users > in support of users who wish to *regist*er independent of any > organizational affiliation. Over time, we anticipate that civil > government entities which already provide analogous identification > services in other contexts, e.g., driver's licenses, may provide > this service. For users who wish anonymity while taking advantage of > PEM privacy facilities, one or more PCAs will be established with > policies that allow for *regist*ration of users, under subordinate CAs, > who do not wish to disclose their identities. > The > architecture describes procedures for *regist*ering certification > authorities and users, for generating and distributing certificates, > and for generating and distributing CRLs. >[The DNs are not being registered. We are just registering that fact that >an entity with an (already registered, hopefully) DN is going to be a CA, >or that the entity is going to be a PEM user under a certain CA.] And in my mind, it is merely a question of who did the registration of the DN. Joe's Auto Garage and Distinguished Name Registry is probably not my choice for the source of DNs used by PEM. > A certificate provides a representation of its subject's identity in > the form of a Distinguished Name (DN). The fundamental binding > ensured by the key management architecture is that between the public > component and the user's identity in this form. A distinguished name > is an X.500 directory system concept and if a user is already > *regist*ered in an X.500 directory, his distinguished name is defined > via that *regist*ration. Users who are not *regist*ered in a directory > should keep in mind likely directory naming structure (schema) when > selecting a distinguished name for inclusion in a certificate. Care should be taken with the last sentence. This has the not-currently- registered user selecting his own distinguished name, hopefully with some consideration taken. But the possibility certainly exists that the user can choose a "bad" DN as well. >[Is the problem that in the foregoing the CA is not required to make sure >that the DN provided in the "complete certificate, minus signature" is >already properly "registered" somewhere?] That could be a problem. If I handed you a "complete certificate, minus signature" with a DN that read US, NASA, ARC, Peter Yee, it would seem reasonable. However, my real DN (and the one that the world knows me by) is US, National Aeronautics and Space Administration, Ames Research Center, Peter Yee. The first DN will only work during searches of the directory. A direct read of that DN will fail because the components used are not made of RDNs for those nodes in the directory. I don't wish to say that I'm asking that PEM CAs be burdened with obtuse requirements for DN validation, but I must state that without some validation of all DNs used by PEM (CAs and users), there may be problems when PEM implementations begin to rely on the growing X.500 infrastructure. > 3.4.2.1 PCA *regist*ration > As part of *regist*ration, each PCA will be required to execute a legal > agreement with the IPRA, and to pay a fee to defray the costs of > operating the IPRA. Each a PCA must specify its distinguished name. ^^^^^^^^^^^ ??? > The IPRA will take reasonable precautions to ensure that the > distinguished name claimed by a PCA is legitimate, e.g., requiring > the PCA to provide documentation supporting its claim to a DN. >[Here we point to the fact of a registration outside the PEM certification >system] Yes. Whose registration authority, though? > In support of the uniqueness requirement, the IPRA will establish and > maintain a database to detect potential, unintended duplicate > certification of CA distinguished names. This database will be made > accessible to all PCAs via an email interface. Each entry in this I take it that this means that you [PEM] is trying to prevent a CA from registering more than once with the same DN. > database will consist of a 4-tuple. The first element in each entry > is a hash value, computed on a canonical, ASN.1 encoded > representation of a CA distinguished name. The second element Which encoding? BER? DER? PER? [Not important to my discussion!] > contains the subjectPublicKey that appears in the CA's certificate. > The third element is the distinguished name of the PCA which > *regist*ered the entry. The fourth element consists of the date and > time at which the entry was made, as established by the IPRA. This > database structure provides a degree of privacy for CAs *regist*ered by > PCAs, while providing a facility for ensuring global uniqueness of CA > DNs certified in this scheme. >[Perhaps this last use of *regist*ered could be changed to certified or >some other word?] That would certainly be better. >[In the next, we are *regist*ering the fact that a DN has already been >taken for use by a CA. Perhaps we could say *list*ing?] > In order to avoid conflicts, a PCA should query the database using a > CA DN hash value as a search key, prior to certifying a CA. The > database will return any entries which match the query, i.e., which > have the same CA DN. The PCA can use the information contained in > any returned entries to determine if any PCAs should be contacted to > resolve possible DN conflicts. If no potential conflicts appear, a > PCA can then submit a candidate entry, consisting of the first three > element values, plus any entries returned by the query. The database > will *regist*er this entry, supplying the time and date stamp, only if > two conditions are met: (1) the first two elements (the CA DN hash > and the CA subjectPublicKey) of the candidate entry together must be > unique and, (2) any other entries included in the submission must > match what the current database would return if the query > corresponding to the candidate entry were submitted. I must have missed the point. Why, other than for a CA registering more than once, would you have a duplicate DN? I assume you that a hash collision (for two distinct values) doesn't really count as a non-unique DN. >[Finally, does the following subordination requirement contradict or become >impossible under the NADF rules? I don't think so. If so, please point >out the text for us.] > To complete the strategy for ensuring uniqueness of DNs, there is a > DN subordination requirement levied on CAs. In general, CAs are > expected to sign certificates only if the subject DN in the > certificate is subordinate to the issuer (CA) DN. This ensures that > certificates issued by a CA are syntactically constrained to refer to > subordinate entities in the X.500 directory information tree (DIT), > and this further limits the possibility of duplicate DN *regist*ration. > CAs may sign certificates which do not comply with this requirement > if the certificates are "cross-certificates" or "reverse > certificates" (see X.509) used with applications other than PEM. I don't see this a contradicting the NADF suggestions, in light of what has been discussed earlier. The term registration, though, is probably not desirable. In summary, my comments are PEM should not be in the registration business (I believe we agree here), that PEM should rely on external registration authorities for establishing DNs, and that PEM should rely on the "right" authority, if it is to have any hope of interworking with X.500. Hope that clarifies things. -Peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10878; 24 Feb 93 14:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10871; 24 Feb 93 14:19 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa22627; 24 Feb 93 14:19 EST Received: by TIS.COM (4.1/SUN-5.64) id AA18374; Wed, 24 Feb 93 14:19:03 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA18365; Wed, 24 Feb 93 14:19:00 EST Message-Id: <9302241919.AA18365@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Wed, 24 Feb 1993 11:18:24 -0800 To: James M Galvin Cc: pem-dev@tis.com Subject: Re: PEM Test Service In-Reply-To: Your message of "Wed, 24 Feb 1993 11:01:06 EST." <9302241601.AA06410@TIS.COM> Date: Wed, 24 Feb 1993 11:18:18 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com >2. Vint and Wolfgang are both correct. RFC 1422 does tightly couple the > naming hierarchy with the certification hierarchy. The principal > reason for this is a pragmatic one: distinguished names must be > unique and unambigous. In the absence of registration services PEM > needed a mechanism to satisfy this requirement. > Now, we can discuss the choice that was made, and make a motion to > use other choices, but let us focus on the technical issue. There > will be opportunities to revise the RFC to allow other choices. I've no problem with pragmatic decision made. The discussion I've raised centers around how well the certification hierarchy will be coupled to the naming hierarchy. >3. In beginning our beta testing of TIS/PEM, we had to consider what to > do about approving or disapproving an individual's or organization's > distinguished name. After much discussion we decided it was very > difficult for us to pass judgement on the choice of distinguished > names. At most, there were names we knew were wrong but it did not > make sense for us to decide what was right. > Therefore, what we decided is that we would offer all the advice and > guidance we had to the process of choosing a name, but as long as the > name was not wrong and it was consistent with the suggestions in RFC > 1255 and it was consistent with the PEM requirements in RFC 1422, we > would allow it. The caveat we emphasized to all organizations and > individuals is that *THEY* are responsible for their distinguished > name and how it is used. We reserve the right to tell them their > name is wrong at some point in the future and therefore must be > changed. My whole argument (well most of it :-)) has been that getting the DNs right now will mean a lot less of "you chose poorly, now fix it!" later. In the case of organizational names in DNs, you can very well determine if they fit in with the SD-5 scheme (assuming you care to buy into this scheme), and you can avoid creating untenable DNs. Sure, it is not TIS's problem, but by pushing the problem to the user, you have still placed yourself in a registration role -- no one else is out there avoiding DN conflicts. Certainly not the users who create their own DNs from the void. I'm not criticizing you, but merely stating that real care must be taken now, not later. (And I don't comment on Wolfgang's requirements because I don't claim to understand them fully). > Although this sounds harsh it really isn't. We expect that this > policy will be an element of all PCA policies. Let face it, we're > all learning about distinguished names. There is a culture that > needs to be established within the community of the "common man". We > should expect change as we gain more experience with this issue. And I suggest that extra work now, to bring us all up to speed on DNs will be well worth the investment. > Toward this end, our PCA issues CA certificates with a 3 month > validity period. This allows for fairly quick changes to > distinguished names, if necessary. Great. As long as no one assumes that renewal of the CA name is guaranteed should there be a problem, this would seem to be a helpful policy. -Peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11214; 24 Feb 93 14:40 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11207; 24 Feb 93 14:40 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa23383; 24 Feb 93 14:40 EST Received: by TIS.COM (4.1/SUN-5.64) id AA19821; Wed, 24 Feb 93 14:40:40 EST Received: from transfer.stratus.com by TIS.COM (4.1/SUN-5.64) id AA19813; Wed, 24 Feb 93 14:40:37 EST Received: from lectroid.sw.stratus.com by transfer.stratus.com (4.1/3.12-jjm) id AA14380; Wed, 24 Feb 93 14:40:02 EST Received: from ellisun.sw.stratus.com by lectroid.sw.stratus.com (4.1/3.8-jjm) id AA15960; Wed, 24 Feb 93 14:40:01 EST Received: by ellisun.sw.stratus.com (4.1/SMI-4.1) id AA05724; Wed, 24 Feb 93 14:39:59 EST Date: Wed, 24 Feb 93 14:39:59 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Carl Ellison Message-Id: <9302241939.AA05724@ellisun.sw.stratus.com> To: pem-dev@tis.com Subject: Unique DNs (was Re: PEM Test Service) X-Orig-Sender: pem-dev-relay@tis.com Since a person's public key is guaranteed unique (or there's a serious flaw in the key generation algorithm), I fail to see why the DN portion of the [DN,key] pair needs to be unique. I could be mis-reading this exchange. [I must admit that I lost interest a while ago and am just skimming it now.] However, it sounds a little like one which flares up on sci.crypt every once in a while: (1) There seem to be people who believe that "identity" rests in a human body and that there needs to be a hierarchical way to identify that body uniquely -- and that that (DN) is the fundamental identifier while all else (eg., public keys) are secondary. (2) Then there are those of us who believe that any name is OK -- and since a public key is unique, that's all we need -- and all else is secondary (including the name I call myself). I'm sorry if I've brought up a useless point -- but it does feel like an argument based on premise (1), a premise I believe to be unnecessary. - Carl - <> - Carl Ellison cme@sw.stratus.com - Stratus Computer Inc. M3-2-BKW TEL: (508)460-2783 - 55 Fairbanks Boulevard ; Marlborough MA 01752-1298 FAX: (508)624-7488   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11501; 24 Feb 93 14:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11494; 24 Feb 93 14:59 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa23858; 24 Feb 93 14:59 EST Received: by TIS.COM (4.1/SUN-5.64) id AA21169; Wed, 24 Feb 93 14:59:10 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA21161; Wed, 24 Feb 93 14:59:07 EST Message-Id: <9302241959.AA21161@TIS.COM> Reply-To: James M Galvin To: Carl Ellison Cc: pem-dev@tis.com Subject: Re: Unique DNs (was Re: PEM Test Service) In-Reply-To: 's message of Wed, 24 Feb 93 14:39:59 EST. <9302241939.AA05724@ellisun.sw.stratus.com> Date: Wed, 24 Feb 93 14:58:56 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,ZZE8Bu+VrtwBqOWnqZVkFo4vNImT1wpPCX/3Ot0nev7 N1Pobp//v9u9EGsEa5NGFxFXP63+cEINmJAhfgy4LZQ== Since a person's public key is guaranteed unique (or there's a serious flaw in the key generation algorithm), I fail to see why the DN portion of the [DN,key] pair needs to be unique. There is absolutely nothing that suggests let only guarantees that a public key is unique. In fact, it is widely known (I know I've mentioned it a few times in very public places) that it is entirely reasonable to expect that an individual could collect as many certificates as possible and generate as many public/private key pairs as possible and look for matches. If you further consider that a majority of the community will be using the same software, you begin to wonder what the likelihood of a match is. Now, I'm no mathematician, so maybe the point is moot, but has anyone given any serious thought to this issue? The quality of the unpredictable (I purposely avoided random) value used to initiate generation of a public/private key pair is paramount, but not sufficient to prevent duplicates. After all, there is nothing to prevent two independent machines from independently generating for use the same unpredictable start value! Jim PS. I note for completeness this issue is not specific to PEM. It applies equally validly to any public key application. - ------------------------------------------------------------------------ This message digitally signed with Privacy Enhanced Mail. Get your copy of the Internet reference implementation from "pem-info@tis.com". -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11816; 24 Feb 93 15:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11809; 24 Feb 93 15:22 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24912; 24 Feb 93 15:22 EST Received: by TIS.COM (4.1/SUN-5.64) id AA22704; Wed, 24 Feb 93 15:22:38 EST Received: from ics.uci.edu by TIS.COM (4.1/SUN-5.64) id AB22678; Wed, 24 Feb 93 15:22:32 EST Received: from nma.com by q2.ics.uci.edu id ad10568; 24 Feb 93 11:10 PST Received: from ics.uci.edu by odin.nma.com id aa11368; 24 Feb 93 10:29 PST To: James M Galvin Cc: pem-dev@tis.com Subject: Re: ["Joyce K. Reynolds": RFC1424 on Key Certification and Related Services] In-Reply-To: Your message of Tue, 09 Feb 1993 20:47:53 -0500. <9302100147.AA06837@TIS.COM> Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Date: Wed, 24 Feb 1993 10:29:30 -0800 Message-Id: <11366.730578570@nma.com> X-Orig-Sender: pem-dev-relay@tis.com I think Jim's PEM forwarding of the MIME messages from Joyce Reynolds makes an elequent statement of the problems we are headed for in the great debate about convergence/divergence of PEM/MIME;-)...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11941; 24 Feb 93 15:32 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11934; 24 Feb 93 15:32 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa25299; 24 Feb 93 15:32 EST Received: by TIS.COM (4.1/SUN-5.64) id AA23521; Wed, 24 Feb 93 15:31:50 EST Received: from transfer.stratus.com by TIS.COM (4.1/SUN-5.64) id AA23512; Wed, 24 Feb 93 15:31:46 EST Received: from lectroid.sw.stratus.com by transfer.stratus.com (4.1/3.12-jjm) id AA16002; Wed, 24 Feb 93 15:31:10 EST Received: from ellisun.sw.stratus.com by lectroid.sw.stratus.com (4.1/3.8-jjm) id AA16487; Wed, 24 Feb 93 15:31:09 EST Received: by ellisun.sw.stratus.com (4.1/SMI-4.1) id AA05854; Wed, 24 Feb 93 15:31:08 EST Date: Wed, 24 Feb 93 15:31:08 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Carl Ellison Message-Id: <9302242031.AA05854@ellisun.sw.stratus.com> To: galvin@tis.com Subject: Re: Unique DNs (was Re: PEM Test Service) Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 2001,MIC-CLEAR Originator-Name: cme@ellisun.sw.stratus.com Originator-Key-Asymmetric: MIGbMAoGBFUIAQECAgP+A4GMADCBiAKBgCl79/jl0DEVl1GQzOHlzjDmChDDxnWO Acd7jShj2x1vclFh6vbHx9IJqkQdwNhNAWf8XnTrqBDN+VSBc1qdT6nSEAbNPxHD XcvY2DudhuRaRBVLgUQ4scTK657m90Q+bTL5yIh2MaFipUw9BgbIXPTDlksSskWP 9oHjo+pCJC+lAgMBAAF= MIC-Info: RSA-MD5,RSA, ED6gKMkk4+esDY6JuVyyWEnQfdwH5TS2J3IVjjeByeZvUxSfSLbeGPXcyLdnCmJ7 cylozrOZKXzIZlhnyPNa/chDBXhVDcJg6MKQZwn65/vSCeOmkIdhdJ41Ccne5QEB FiWte35UlqJ+3gATDkRStV8/YmR3855KMXnr71+0Tsg= >Message-Id: <9302241959.AA21161@TIS.COM> >Subject: Re: Unique DNs (was Re: PEM Test Service) >Date: Wed, 24 Feb 93 14:58:56 -0500 > > > > Since a person's public key is guaranteed unique (or there's a > serious flaw in the key generation algorithm), I fail to see why > the DN portion of the [DN,key] pair needs to be unique. > >There is absolutely nothing that suggests let only guarantees that a >public key is unique. >The quality of the unpredictable (I purposely avoided random) value used >to initiate generation of a public/private key pair is paramount, but >not sufficient to prevent duplicates. After all, there is nothing to >prevent two independent machines from independently generating for use >the same unpredictable start value! Not to nit pick, but my "or there's a serious flaw in the key generation algorithm" was speaking to this possibility. If truly random numbers are used, there is a chance for two people to generate the same key, but it's unlikely enough that I would consider it impossible. (eg., 1 chance in 2^1024). If non-random numbers are used and two people generate the same key, then the key generation algorithm is flawed by definition and needs to be fixed before anything else is done. - Carl - <> - Carl Ellison cme@sw.stratus.com - Stratus Computer Inc. M3-2-BKW TEL: (508)460-2783 - 55 Fairbanks Boulevard ; Marlborough MA 01752-1298 FAX: (508)624-7488 -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12635; 24 Feb 93 16:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12628; 24 Feb 93 16:02 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa26221; 24 Feb 93 16:02 EST Received: by TIS.COM (4.1/SUN-5.64) id AA26457; Wed, 24 Feb 93 16:02:12 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA26450; Wed, 24 Feb 93 16:02:09 EST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA11389; Wed, 24 Feb 1993 16:01:34 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA06915; Wed, 24 Feb 93 16:01:18 EST Message-Id: <9302242101.AA06915@smiley.mitre.org.sit> Date: Wed, 24 Feb 1993 16:03:58 -0500 To: Peter Yee Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" X-Sender: shirey@smiley.mitre.org Subject: Re: PEM Test Service Cc: pem-dev@tis.com, egardner%mdf@mwunix.mitre.org X-Orig-Sender: pem-dev-relay@tis.com I thought your answer was pretty good. Now, I think the PEM WG needs to consider in the March meeting in Columbus whether the procedures that the ISOC is mandating for PCAs and their CAs are necessary and sufficient. Meanwhile, people who are hard over on the "alignment" of PEM with the NADF registration rules really do need to reed 1422 (and maybe 1424) and tell us what they think needs to be put in there to accomplish that alignment economically.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14557; 24 Feb 93 17:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14550; 24 Feb 93 17:38 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa29109; 24 Feb 93 17:38 EST Received: by TIS.COM (4.1/SUN-5.64) id AA01909; Wed, 24 Feb 93 17:37:43 EST Received: from darmstadt.gmd.de (erde.darmstadt.gmd.de) by TIS.COM (4.1/SUN-5.64) id AA01902; Wed, 24 Feb 93 17:37:39 EST Received: from libra.darmstadt.gmd.de by darmstadt.gmd.de (4.1/GMDDA-MS2.0) id AA05149; Wed, 24 Feb 93 23:36:51 +0100 Date: Wed, 24 Feb 93 23:36:51 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Wolfgang Schneider Message-Id: <9302242236.AA05149@darmstadt.gmd.de> To: shirey@mitre.org Subject: Re: PEM Test Service Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com > From: shirey@mitre.org (Robert W. Shirey) > X-Sender: shirey@smiley.mitre.org > Subject: Re: PEM Test Service > Cc: pem-dev@TIS.COM > Sender: pem-dev-relay@TIS.COM > Content-Length: 70 > > Could you please offer a concrete example of how it "would not fit?" > GMD has three major sites in Birlinghoven (near Bonn, this is the main site), Darmstadt and Berlin and has a number of smaller units in other locations. We decided to operate four CAs with the DNs < C=DE; O=GMD; OU=CA > < C=DE; O=GMD; L=Birlinghoven; OU=CA > < C=DE; O=GMD; L=Darmstadt; OU=CA > < C=DE; O=GMD; L=Berlin; OU=CA > where the GMD-wide CA only certifies the three location-CAs, and each employee is certified by one of the location-CAs. We used these DNs with the OU=CA attribute because first we consider a CA to be an organization or organizational unit which is operated by administrators, second to be able to have two different directory entries for the CA and the site it serves (i.e. to have two different entries for < C=DE; O=GMD; L=Darmstadt > and < C=DE; O=GMD; L=Darmstadt; OU=CA > for instance), and third to be able to see from the DN that it names a CA. Similarly we operate three DSAs, each maintaining the location part of the GMD DIB. Most employees have DNs of the form < C=DE; O=GMD; L=Birlinghoven; CN=yyy > < C=DE; O=GMD; L=Darmstadt; CN=yyy > < C=DE; O=GMD; L=Berlin; CN=yyy > so that in most cases DNs of the form < C=DE; O=GMD; L=xxx; CN=yyy > are certified by < C=DE; O=GMD; L=xxx; OU=CA >. However, we have for various reasons also DNs of the form < C=DE; O=GMD; OU=xxx; CN=yyy > where OU=xxx denotes an institute, for instance, or something else. Reasons are that employees are in none of the three major sites, or that certain institutes want to have their institute name in their DNs. These DNs are also certified by one of the three location-CAs < C=DE; O=GMD; L=xxx; OU=CA >. That's the reality in the moment. It would have been very nice if once the Internet CA is being operational and we have a PCA in Germany, we simply get a certificate for < C=DE; O=GMD; OU=CA > from that PCA and have the whole GMD staff connected to the PEM certification tree. But as it stands this will not be the case. We will either have to rename the CAs and to reshuffle the whole thing, or to establish a second certification structure. I admit that it would be possible to do the whole with an RFC 1422 style naming scheme, too, perhaps with a number of restrictions, but I think our system is not extremely odd. What we do at the moment with that certification system is just emerging and in pilot stages, so if ever we have a chance for reorganization or renaming then this will be now. But on the other hand, it is very difficult anyway to motivate colleagues and particularly administration employees to participate in new security enhanced services or to convince them that they should put their efforts into a potential gain in security. It would be very counterproductive to change names, certifiactes, keys etc. more often than absolutely necessary. We think about a number of applications, from a unique GMD-wide access to system resources to administrative procedures which are currently paper bound, which include the usage of X.500 directories also for internal purposes and which will include in the future system management functionality (not to be confused with network management functionality) in order to have a unique management platform for systems and applications. All this must be founded on a common security infrastructure which includes a common certification infrastructure. We will have a lot of authorization stuff derived from authenticated DNs, but I will not say at this point that all can be done with X.509 certificates. We will have to gain a lot of experience and then see. But PEM will certainly be only one of our intended applications which will use the certification stuff. Wolfgang Schneider GMD   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14839; 24 Feb 93 18:07 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14832; 24 Feb 93 18:07 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa00123; 24 Feb 93 18:07 EST Received: by TIS.COM (4.1/SUN-5.64) id AA03259; Wed, 24 Feb 93 18:06:22 EST Received: from darmstadt.gmd.de (erde.darmstadt.gmd.de) by TIS.COM (4.1/SUN-5.64) id AA03253; Wed, 24 Feb 93 18:06:19 EST Received: from libra.darmstadt.gmd.de by darmstadt.gmd.de (4.1/GMDDA-MS2.0) id AA06724; Thu, 25 Feb 93 00:05:26 +0100 Date: Thu, 25 Feb 93 00:05:26 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Wolfgang Schneider Message-Id: <9302242305.AA06724@darmstadt.gmd.de> To: jlowry@bbn.com Subject: Re: PEM Test Service Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com > From: John Lowry > To: Wolfgang Schneider > Cc: epg@gateway.mitre.org, pem-dev@TIS.COM > Subject: Re: PEM Test Service > Sender: pem-dev-relay@TIS.COM > Content-Length: 520 > > >In the case that certification is being used for authorization purposes, > >i.e. when you derive capabilities, access rights or whatever from authen- > >ticated DNs, that certification structure is too restrictive, in my view. > > It has been a while since I have followed this closely but I believe > that PEM certification implies no authorization. PEM certificates > are used by PEM solely for the purpose of authenticating identity. > Yes, correct. My remark means that I consider it to be a requirement in the future that an organization is able to create a common certification structure which suites for a number of different applications, one of them being PEM, others doing authorization processes, for instance. Wolfgang   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14884; 24 Feb 93 18:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14877; 24 Feb 93 18:13 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa00255; 24 Feb 93 18:13 EST Received: by TIS.COM (4.1/SUN-5.64) id AA03611; Wed, 24 Feb 93 18:12:21 EST Received: from darmstadt.gmd.de (erde.darmstadt.gmd.de) by TIS.COM (4.1/SUN-5.64) id AA03594; Wed, 24 Feb 93 18:12:16 EST Received: from libra.darmstadt.gmd.de by darmstadt.gmd.de (4.1/GMDDA-MS2.0) id AA07058; Thu, 25 Feb 93 00:11:18 +0100 Date: Thu, 25 Feb 93 00:11:18 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Wolfgang Schneider Message-Id: <9302242311.AA07058@darmstadt.gmd.de> To: W.Green@utexas.edu Subject: Re: PEM Test Service Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com > From green@mojo.ots.utexas.edu Wed Feb 24 20:00:17 1993 > Date: Wed, 24 Feb 1993 12:35:07 -0600 (GMT-0600) > From: "William C. Green" > Sender: "William C. Green" > Subject: Re: PEM Test Service > To: Wolfgang Schneider > Mime-Version: 1.0 > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 2746 > > On Wed, 24 Feb 93 15:51:52 +0100, Wolfgang Schneider wrote: > > > Subject: Re: PEM Test Service > > To: epg@gateway.mitre.org > > cc: pem-dev@TIS.COM > > > > > In the case that certification is being used for authorization purposes, > > i.e. when you derive capabilities, access rights or whatever from authen- > > ticated DNs, that certification structure is too restrictive, in my view. > > The Directory itself is a good example. If you access a DSA using strong > > authentication, the DSA will grant or deny you access rights to the DIB > > which he may derive from your authenticated DN, following an authorization > > policy. It could also be part of the particular DSA authorization policy, > > for instance, that your access rights are not derived from your name, but > > from the name of the issuer of your certificate. I can imagine a lot of > > applications where X.509-certification is being used to derive capabilities > > not from your DN, but from the place where you are in the certification > > tree. > > > > I guess I'm a bit confused. In the case of a DSA, isn't it the access control > lists that determine what you can accomplish "authorization" ? The access > control lists have as a component distinguished names identifing who can > perform what operations. X.509 certification simply binds a DN > "authentication". > I had X.500-88 DSAs in mind where access control is a local, non-standardized matter. Wolfgang   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14956; 24 Feb 93 18:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14949; 24 Feb 93 18:28 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa00642; 24 Feb 93 18:28 EST Received: by TIS.COM (4.1/SUN-5.64) id AA04312; Wed, 24 Feb 93 18:27:41 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA04306; Wed, 24 Feb 93 18:27:40 EST Message-Id: <9302242327.AA04306@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Wed, 24 Feb 1993 15:26:54 -0800 To: "Robert W. Shirey" Cc: pem-dev@tis.com, egardner%mdf@mwunix.mitre.org Subject: Re: PEM Test Service In-Reply-To: Your message of "Wed, 24 Feb 1993 16:03:58 EST." <9302242101.AA06915@smiley.mitre.org.sit> Date: Wed, 24 Feb 1993 15:26:48 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com Unfortunately, I won't be at the March IETF to discuss this in open session. I'd say the only changes are to suggest (strongly) that the NADF rules are worth applying as opposed to someother registration authority's. And I suggest this because that's the way current X.500 thinking is running. Obviously, I'm not in a position to force the issue (nor do I want to be!). -Peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14978; 24 Feb 93 18:32 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14971; 24 Feb 93 18:32 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa00812; 24 Feb 93 18:32 EST Received: by TIS.COM (4.1/SUN-5.64) id AA04643; Wed, 24 Feb 93 18:33:01 EST Received: from atlas.arc.nasa.gov by TIS.COM (4.1/SUN-5.64) id AA04633; Wed, 24 Feb 93 18:32:59 EST Message-Id: <9302242332.AA04633@TIS.COM> Received: from 0.0.0.0 by atlas.arc.nasa.gov with SMTP (PP); Wed, 24 Feb 1993 15:32:08 -0800 To: Carl Ellison Cc: pem-dev@tis.com Subject: Re: Unique DNs (was Re: PEM Test Service) In-Reply-To: Your message of "Wed, 24 Feb 1993 14:39:59 EST." <9302241939.AA05724@ellisun.sw.stratus.com> Date: Wed, 24 Feb 1993 15:32:02 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Yee X-Orig-Sender: pem-dev-relay@tis.com >Since a person's public key is guaranteed unique (or there's a serious flaw >in the key generation algorithm), I fail to see why the DN portion of the >[DN,key] pair needs to be unique. How would I look you up in the X.500 directory if your DN was the same as someone elses (a concept with a meaning of which I'm unsure)? Say I wish to retrieve your public key so that I may encrypt something for you alone. I'd sure like to be able to find you by some means. The reason that I brought the issue of alignment is that if we are going to use X.500 directories for PEM purposes in the future, we need the DNs to be the same (or very close) so that there isn't a need to change DNs later. Does this make sense? Did I miss something in your argument? -Peter   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16113; 24 Feb 93 22:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16106; 24 Feb 93 22:25 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa06226; 24 Feb 93 22:25 EST Received: by TIS.COM (4.1/SUN-5.64) id AA11578; Wed, 24 Feb 93 22:25:21 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA11572; Wed, 24 Feb 93 22:25:20 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16091; 24 Feb 93 22:24 EST To: "Robert W. Shirey" Cc: Peter Yee , pem-dev@tis.com, egardner%mdf@mwunix.mitre.org Subject: Re: PEM Test Service In-Reply-To: Your message of "Wed, 24 Feb 93 16:03:58 EST." <9302242101.AA06915@smiley.mitre.org.sit> Date: Wed, 24 Feb 93 22:24:11 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302242224.aa16091@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Bob, et al, I am working on the text of the ISOC/PCA agreements - and I am treating this as a kind of experiment for the moment as we gain experience with real situations. I would value some time at IETF to gather more feedback and will do my best to get the drafts out well ahead of IETF for comment. vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07755; 25 Feb 93 10:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07748; 25 Feb 93 10:52 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa11112; 25 Feb 93 10:52 EST Received: by TIS.COM (4.1/SUN-5.64) id AA03984; Thu, 25 Feb 93 10:49:24 EST Received: from transfer.stratus.com by TIS.COM (4.1/SUN-5.64) id AA03969; Thu, 25 Feb 93 10:49:18 EST Received: from lectroid.sw.stratus.com by transfer.stratus.com (4.1/3.12-jjm) id AA10410; Thu, 25 Feb 93 10:48:35 EST Received: from ellisun.sw.stratus.com by lectroid.sw.stratus.com (4.1/3.8-jjm) id AA20549; Thu, 25 Feb 93 10:48:34 EST Received: by ellisun.sw.stratus.com (4.1/SMI-4.1) id AA07369; Thu, 25 Feb 93 10:48:33 EST Date: Thu, 25 Feb 93 10:48:33 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Carl Ellison Message-Id: <9302251548.AA07369@ellisun.sw.stratus.com> To: yee@atlas.arc.nasa.gov Subject: Re: Unique DNs Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com >Message-Id: <9302242332.AA21162@transfer.stratus.com> >Subject: Re: Unique DNs (was Re: PEM Test Service) >Date: Wed, 24 Feb 1993 15:32:02 -0800 > >>Since a person's public key is guaranteed unique (or there's a serious flaw >>in the key generation algorithm), I fail to see why the DN portion of the >>[DN,key] pair needs to be unique. > >How would I look you up in the X.500 directory if your DN was the same as >someone elses (a concept with a meaning of which I'm unsure)? If X.500 needs unique DNs, then that's it's need, not PEM's. Of course, [DN,key] is unique and could be used for X.500, but [DN,key] is not very useful for mail routing. A hierarchy like the current domain name system is better for that. So, if you're using DNs for mail delivery, they need to be unique and should probably be hierarchical as well. I realize that that's not what you were asking about, however. So, for the rest of this message, assume there's some way other than DN to deliver mail (maybe posting it on a newsgroup) so that there can be non-unique DNs. > Say I wish >to retrieve your public key so that I may encrypt something for you alone. How do you know me that you want to send me mail and encrypt it for me? If we have communicated, you would have my key already. If we haven't ever communicated in any way, someone could have given you my address -- in which case they could give you my key as well. If you haven't been given my [DN,key] by anyone but are looking me up in a database, then that lookup is based on some criterion (eg., "computer scientist interested in discussing real-time 3D graphics, fault tolerance or cryptology") -- and if there are 12 such people with the same DN but different public keys, then it shouldn't matter to which one your mail gets encrypted and delivered. It doesn't matter because you have no way to tell one of us from the other. >I'd sure like to be able to find you by some means. If you know me, you know me -- ie., you know my key. That's my name. From that, you can find my DN, my mail address, .... > The reason that I brought >the issue of alignment is that if we are going to use X.500 directories for >PEM purposes in the future, we need the DNs to be the same (or very close) >so that there isn't a need to change DNs later. Does this make sense? Did >I miss something in your argument? I understand a desire not to change DNs. - SOAP BOX ON All I was saying was that I see no reason for PEM to derive unique identities from DNs when the key is unique and the only unique name of a person you would ever need to have. Granted, once you've uniquely named a person that way, you might still want secondary information (e-mail address, where the person works, spoken name, ...) but all of that can be (has to be) acquired by signed messages establishing relationships. I see certificates as a systematized means for gathering and distributing some of those signed messages -- establishing some of those relationships. It doesn't cover all of them. There's no mechanism for verifying my age, gender, height, weight, sexual preference, favorite sports, favorite TV shows, ..., or other things which an e-mail correspondent might very much want to know. I realize that this is a silly conversation for me to be having this late in the game. I have no desire to hold up PEM's release. I like it, just as it is. (Ie., "it's been too long in coming -- just ship it!") But, I fail to see why uniqueness of DNs (or even their format) is of any concern to PEM. It's of concern to others (directory services, mail delivery, ...) -- and without public keys, you might want DNs to establish identity -- but once you have keys, you don't need to establish identity in such an old-fashioned, hierarchical way. - SOAP BOX OFF - Carl - <> - Carl Ellison cme@sw.stratus.com - Stratus Computer Inc. M3-2-BKW TEL: (508)460-2783 - 55 Fairbanks Boulevard ; Marlborough MA 01752-1298 FAX: (508)624-7488   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09463; 25 Feb 93 11:46 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09448; 25 Feb 93 11:46 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa12863; 25 Feb 93 11:46 EST Received: by TIS.COM (4.1/SUN-5.64) id AA07411; Thu, 25 Feb 93 11:46:08 EST Received: from bells.cs.ucl.ac.uk by TIS.COM (4.1/SUN-5.64) id AA07347; Thu, 25 Feb 93 11:45:55 EST Message-Id: <9302251645.AA07347@TIS.COM> Received: from auchentoshan.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 25 Feb 1993 16:44:00 +0000 To: Carl Ellison Cc: yee@atlas.arc.nasa.gov, pem-dev@tis.com Subject: Re: Unique DNs In-Reply-To: Your message of "Thu, 25 Feb 93 10:48:33 EST." <9302251548.AA07369@ellisun.sw.stratus.com> Date: Thu, 25 Feb 93 16:43:57 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Williams X-Orig-Sender: pem-dev-relay@tis.com >From: cme@com.stratus.sw.ellisun (Carl Ellison) >Subject: Re: Unique DNs >Date: Thu, 25 Feb 93 10:48:33 EST >>Message-Id: <9302242332.AA21162@transfer.stratus.com> >>Subject: Re: Unique DNs (was Re: PEM Test Service) >>Date: Wed, 24 Feb 1993 15:32:02 -0800 >> If you want distributed proof services, you need uniqueness of naming proven to a high degree of confidence. If you want to scale to 750 million users, then you need to manage the name space, and the address space, and (lately) a small certification space. If you want people to interwork by intercommunicating, then you provide tools like the X.500 listing to map key=identity/name=legality/adress=connectivity relation. Any database will do provided it is distributed and self-managing. If PEM certification semantics work in practice and manageably, then key=name also. This will be a big bonus for both security, and management. The issue is not about PEM, or even now, about the PEM certification semantics. Concensus has been reached on those. Now. how do we do it? In one local security policy, if your DN is not verifable by a cursory lookup through the untrusted public directory service, then you are low assurance category. If your entry exists in a locally managed trusted DSA, then you may have medium assurance properties, depending upon local beliefs regarding the certification source. If you have a strict PEM chain, then the assurance level is calculable based upon the PCA name, and quality. You may have gleaned from Wolfgangs last message, that we are not concerned only with PEM/SDNS/ODA, nor will we be constrained by such syntaxes or any associated certification profiles. However we will exploit its desirable assurnace properties of PEM where possible. Otherwise secondary strategies are required. these are based upon sensible, well-understood well-practiced solutions for managing the scaling issues of distribution. Pure PEM deployment will be eased in its first 2 years if it adopts those strategies from the outset. it doesnt really need much/any change to RFCs. Just the will to profile PEM suitably amongst implementors such that it works not only on paper, but in practice, and on a massive scale. How many users do we expect in 3 months time? It ought to be greater that the 10.000 mark - I would hope. Perhaps someone else would estimate a growth rate?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10377; 25 Feb 93 12:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10368; 25 Feb 93 12:19 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa13973; 25 Feb 93 12:19 EST Received: by TIS.COM (4.1/SUN-5.64) id AA09067; Thu, 25 Feb 93 12:19:09 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by TIS.COM (4.1/SUN-5.64) id AA09001; Thu, 25 Feb 93 12:19:03 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA00328; Thu, 25 Feb 93 09:16:43 -0800 To: Carl Ellison Cc: yee@atlas.arc.nasa.gov, pem-dev@tis.com Reply-To: pem-dev@tis.com Subject: Re: Unique DNs In-Reply-To: Your message of "Thu, 25 Feb 1993 10:48:33 EST." <9302251548.AA07369@ellisun.sw.stratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Feb 1993 09:16:40 -0800 Message-Id: <327.730660600@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose X-Orig-Sender: pem-dev-relay@tis.com If PEM is going to use DNs, then you have to play by X.500's rules. In X.500, a DN refers to an entity in "the real world" with respect to that entity's role in the real world. DNs do not refer to multiple entities, but may refer to an entity which is a collection of other entities. What this means is that MTR might have one or more DNs: one for MTR in a business role, another for MTR in a residential role, perhaps a third DN for MTR as a student at a university, etc. However, the DN assigned to MTR in any role, may not be assigned to any other entity--NO EXCEPTIONS. This is why it is important to have a way of ensuring the unique assignment of DNs, and why that way should be as simple-to-use and error-free as possible. The NADF's SD-5 document defines such an algorithm for c=US and c=CA. The algorithm doesn't always produce short or pretty DNs, but it leverages off the existing civil naming structure, with its myriad rules of intellectual (naming) property rights, so that the hard registration questions are answered before the DN is generated. With this paradigm, the Directory is where things are listed, not registered. How does this relate to PEM? The answer is that use of DNs by PEM must not behave differently than the 2nd paragraph above ("In X.500, ...") In addition, PEM shouldn't worry about how DNs get assigned, nor try to associate any special semantics with an arbitrary DN--unless it has special knowledge about that DN. To do so is to go looking for trouble. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10790; 25 Feb 93 12:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10783; 25 Feb 93 12:37 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa14683; 25 Feb 93 12:37 EST Received: by TIS.COM (4.1/SUN-5.64) id AA09614; Thu, 25 Feb 93 12:37:16 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA09605; Thu, 25 Feb 93 12:37:10 EST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA00184; Thu, 25 Feb 1993 12:36:36 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA12938; Thu, 25 Feb 93 12:36:19 EST Message-Id: <9302251736.AA12938@smiley.mitre.org.sit> Date: Thu, 25 Feb 1993 12:39:01 -0500 To: Carl Ellison Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" X-Sender: shirey@smiley.mitre.org (Unverified) Subject: Re: Unique DNs Cc: pem-dev@mitre.org X-Orig-Sender: pem-dev-relay@tis.com I HAVE PULLED OUT TWO PARAGRAPHS FOR YOU. The CA DN in a certificate is not subordinated to the PCA's DN. So CA names need to be unique across the PEM system. Otherwise, you do not know how to validate the certificate chain. 3.3.5 Issuer Name A certificate provides a representation of its issuer's identity, in the form of a Distinguished Name. The issuer identification is used to select the appropriate issuer public component to employ in performing certificate validation. (If an issuer (CA) is certified by multiple PCAs, then the issuer DN does not uniquely identify the public component used to sign the certificate. In such circumstances it may be necessary to attempt certificate validation using multiple public components, from certificates held by the issuer under different PCAs. If the 1992 version of a certificate is employed, the issuer may employ distinct issuer UIDs in the certificates it issues, to further facilitate selection of the right issuer public component.) The issuer is the certifying authority (IPRA, PCA or CA) who vouches for the binding between the subject identity and the public key contained in the certificate. . . . 3.4.2.2 Ensuring the Uniqueness of Distinguished Names A fundamental requirement of this certification scheme is that certificates are not issued to distinct entities under the same distinguished name. This requirement is important to the success of distributed management for the certification hierarchy. The IPRA will not certify two PCAs with the same distinguished name and no PCA may certify two CAs with the same DN. However, since PCAs are expected to certify organizational CAs in widely disjoint portions of the directory namespace, and since X.500 directories are not ubiquitous, a facility is required for coordination among PCAs to ensure the uniqueness of CA DNs. (This architecture allows multiple PCAs to certify residential CAs and thus multiple, distinct residential CAs with identical DNs may come into existence, at least until such time as civil authorities assume responsibilities for such certification. Thus, on an interim basis, the architecture explicitly accommodates the potential for duplicate residential CA   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11489; 25 Feb 93 13:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11482; 25 Feb 93 13:15 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa15934; 25 Feb 93 13:15 EST Received: by TIS.COM (4.1/SUN-5.64) id AA11601; Thu, 25 Feb 93 13:15:28 EST Received: from transfer.stratus.com by TIS.COM (4.1/SUN-5.64) id AA11577; Thu, 25 Feb 93 13:15:21 EST Received: from lectroid.sw.stratus.com by transfer.stratus.com (4.1/3.12-jjm) id AA14517; Thu, 25 Feb 93 13:14:46 EST Received: from ellisun.sw.stratus.com by lectroid.sw.stratus.com (4.1/3.8-jjm) id AA21957; Thu, 25 Feb 93 13:14:45 EST Received: by ellisun.sw.stratus.com (4.1/SMI-4.1) id AA08088; Thu, 25 Feb 93 13:14:43 EST Date: Thu, 25 Feb 93 13:14:43 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Carl Ellison Message-Id: <9302251814.AA08088@ellisun.sw.stratus.com> To: shirey@mitre.org Subject: Let's drop this thread (was Re: Unique DNs) Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com >Message-Id: <9302251736.AA12938@smiley.mitre.org.sit> >Date: Thu, 25 Feb 1993 12:39:01 -0500 >Subject: Re: Unique DNs >I HAVE PULLED OUT TWO PARAGRAPHS FOR YOU. Thank you. I would like to see us drop this topic. To me, it's an interesting observation for discussion among relaxed people who have nothing better to do. PEM, however, is in the midst of release and standardization and I believe it needs to get released and accepted with a minimum of delay. So, I don't want to debate this in any way which might hold up PEM adoption. However, for those pem-dev readers who are up for relaxed consideration -- >3.3.5 Issuer Name If unique names in PEM-space had been defined to be RSA public keys, then there might be other problems to solve but this current debate about uniqueness of DNs wouldn't affect PEM adoption. > 3.4.2.2 Ensuring the Uniqueness of Distinguished Names > > A fundamental requirement of this certification scheme is that > certificates are not issued to distinct entities under the same > [...] name. Of course. If name were RSA key, there wouldn't need to be procedural safeguards enforcing uniqueness. The key generation algorithm does that for you -- and you can't get a more distributed algorithm. > This requirement is important to the success of > distributed management for the certification hierarchy. Yup -- much better once you know all names are unique. - Carl   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13222; 25 Feb 93 14:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13215; 25 Feb 93 14:29 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa18142; 25 Feb 93 14:29 EST Received: by TIS.COM (4.1/SUN-5.64) id AA16711; Thu, 25 Feb 93 14:29:33 EST Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by TIS.COM (4.1/SUN-5.64) id AA16705; Thu, 25 Feb 93 14:29:32 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13013; 25 Feb 93 14:22 EST To: pem-dev@tis.com Cc: Carl Ellison , yee@atlas.arc.nasa.gov Subject: Re: Unique DNs In-Reply-To: Your message of "Thu, 25 Feb 93 09:16:40 PST." <327.730660600@dbc.mtview.ca.us> Date: Thu, 25 Feb 93 14:22:28 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Vinton G. Cerf" Message-Id: <9302251422.aa13013@IETF.CNRI.Reston.VA.US> X-Orig-Sender: pem-dev-relay@tis.com Marshall, I could not quite tell from your last paragraph whether you meant to imply that the hierarchical relationships among the DNs of certificates authorized by CAs should or should not be required as part of the architecture. The syntactic relation makes it much easier to validate the certification chain and that seems very attractive. vint   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13239; 25 Feb 93 14:30 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13232; 25 Feb 93 14:30 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa18179; 25 Feb 93 14:30 EST Received: by TIS.COM (4.1/SUN-5.64) id AA16724; Thu, 25 Feb 93 14:29:46 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA16718; Thu, 25 Feb 93 14:29:43 EST Received: from mwvm.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA07715; Thu, 25 Feb 1993 14:28:49 -0500 Received: from mwunix.mitre.org by mwvm.mitre.org (IBM VM SMTP V2R1) with TCP; Thu, 25 Feb 93 13:39:49 EST Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA04073; Thu, 25 Feb 1993 13:39:45 -0500 Message-Id: <199302251839.AA04073@mwunix.mitre.org> Date: Thu, 25 Feb 93 13:38:14 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: PostMast@mwmgate1.mitre.org To: "PEM-DEV at TIS.COM@MWUNIX" Subject: Undeliverable mail X-Orig-Sender: pem-dev-relay@tis.com Gateway MWMGATE1 could not deliver your mail to cc:Mail user w035_nw because of the error(s) cited below. Your undelivered message follows: - - - - - - - - - - - - - - - - - - - - - - - *** Unknown message recipient *** Subject: Re: Unique DNs Date: 25-FEB-1993 13:27:54 -------------- The following note was forwarded to you by AWAY... ------------- Received: from mwunix.mitre.org by mwvm.mitre.org (IBM VM SMTP V2R1) with TCP; Thu, 25 Feb 93 13:26:55 EST Return-Path: Received: from TIS.COM by mwunix.mitre.org (5.65c/SMI-2.2) id AA03235; Thu, 25 Feb 1993 13:26:50 -0500 Received: by TIS.COM (4.1/SUN-5.64) id AA09067; Thu, 25 Feb 93 12:19:09 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by TIS.COM (4.1/SUN-5.64) id AA09001; Thu, 25 Feb 93 12:19:03 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA00328; Thu, 25 Feb 93 09:16:43 -0800 To: cme@ellisun.sw.stratus.com (Carl Ellison) Cc: yee@atlas.arc.nasa.gov, pem-dev@TIS.COM Reply-To: pem-dev@TIS.COM Subject: Re: Unique DNs In-Reply-To: Your message of "Thu, 25 Feb 1993 10:48:33 EST." <9302251548.AA07369@ellisun.sw.stratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Feb 1993 09:16:40 -0800 Message-Id: <327.730660600@dbc.mtview.ca.us> From: Marshall Rose Sender: pem-dev-relay@TIS.COM If PEM is going to use DNs, then you have to play by X.500's rules. In X.500, a DN refers to an entity in "the real world" with respect to that entity's role in the real world. DNs do not refer to multiple entities, but may refer to an entity which is a collection of other entities. What this means is that MTR might have one or more DNs: one for MTR in a business role, another for MTR in a residential role, perhaps a third DN for MTR as a student at a university, etc. However, the DN assigned to MTR in any role, may not be assigned to any other entity--NO EXCEPTIONS. This is why it is important to have a way of ensuring the unique assignment of DNs, and why that way should be as simple-to-use and error-free as possible. The NADF's SD-5 document defines such an algorithm for c=US and c=CA. The algorithm doesn't always produce short or pretty DNs, but it leverages off the existing civil naming structure, with its myriad rules of intellectual (naming) property rights, so that the hard registration questions are answered before the DN is generated. With this paradigm, the Directory is where things are listed, not registered. How does this relate to PEM? The answer is that use of DNs by PEM must not behave differently than the 2nd paragraph above ("In X.500, ...") In addition, PEM shouldn't worry about how DNs get assigned, nor try to associate any special semantics with an arbitrary DN--unless it has special knowledge about that DN. To do so is to go looking for trouble. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16781; 25 Feb 93 16:55 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16774; 25 Feb 93 16:55 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa22685; 25 Feb 93 16:55 EST Received: by TIS.COM (4.1/SUN-5.64) id AA26258; Thu, 25 Feb 93 16:55:02 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by TIS.COM (4.1/SUN-5.64) id AA26240; Thu, 25 Feb 93 16:54:58 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA03125; Thu, 25 Feb 93 13:52:51 -0800 To: "Vinton G. Cerf" Cc: pem-dev@tis.com, Carl Ellison , yee@atlas.arc.nasa.gov Reply-To: pem-dev@tis.com Subject: Re: Unique DNs In-Reply-To: Your message of "Thu, 25 Feb 1993 14:22:28 EST." <9302251422.aa13013@IETF.CNRI.Reston.VA.US> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Feb 1993 13:52:46 -0800 Message-Id: <3124.730677166@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose X-Orig-Sender: pem-dev-relay@tis.com I was purposefully vague in that part of my response, and I'm glad that you caught that. Once a DN has been assigned to an entity, then that entity gets to define the semantics associated with subordinate DNs. So, in the case of a CA and its customers, I don't think you have a problem. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18369; 25 Feb 93 18:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18356; 25 Feb 93 18:02 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa25190; 25 Feb 93 18:02 EST Received: by TIS.COM (4.1/SUN-5.64) id AA05238; Thu, 25 Feb 93 18:00:39 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA05229; Thu, 25 Feb 93 18:00:34 EST Message-Id: <9302252300.AA05229@TIS.COM> To: pem-dev@tis.com Subject: Re: Unique DNs In-Reply-To: Your message of Thu, 25 Feb 93 09:16:40 -0800. <327.730660600@dbc.mtview.ca.us> Date: Thu, 25 Feb 93 17:59:46 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Folks: This discussion of the use of DNs in certificates used with PEM seems to have gotten very much off track. The central issues are not that complicated, although a lack of familiarity with the RFCs does seem to have contributed significanlty to this confusion. 1. I believe that the concern Peter Yee expressed in the message that triggered this sequence of messages is a valid one. The concern, if I paraphrase Peter, is that individuals and organizations who generate DNs in order to make use of X.509 certificates with PEM should exercise care. 2. Contrary to popular (but uninformed) belief, the PEM RFCs do not establish conventions for DN formats, allowed attributes, etc. The only restriciton on DNs is the one implied by the name subordination requirement which has been cited in previous messages. The RFCs point out that PCAs and CAs should follow appropriate schema when creating DNs (vs. merely issuing certificates for existing DNs). Given the global scope of PEM, I don't think there is one schema guideline we can point to, although we do point to guidelines for North America. Given this context, it is silly (at best) to argue that the PEM RFCs diverge from X.500 DN conventions. We are pointing people in the right direction and hoping for the best. I don't know that anyone encouraging very widespread DN adoption can do much more without usurping somebody's right to establish schema conventions somewhere in the world, but I'm open to concrete suggestions. 3. X.509 certificates are designed for authentication, not authorization. The verified DNs provided by such certificates can be used as inputs to identity-based access control decisions. However, there are many types of attributes one might wish to associate with an entity for input to authorization decisions and these attributes are often not appropriate in a DN. There is considerable literature on the topic of using certificates for authorization: ECMA documents, PKCS documents, and ANSI X9F1 documents, and papers published in various computer security conferences over the last 5 years. All of this literature distinguishes between certificates for authorization vs. identification, although there is not universal agreement on what form the former should take and how they should be related to the latter. PEM has requirements only for identification certificates, and has thus adopted the one certificate format generally recognized as a suitable basis for that function. Thus I don't think it is reasonable to criticize the one DN relationship constraint in the PEM RFCs because of a conflict with a desire to use certificates for authorization. 4. PCAs really should act responsibily. This means that a PCA should be aware of X.500 schema conventions applicable to any populations which the PCA serves, and it should be firm in inststing that CAs abide by those conventions with regard to certificates issued for PEM use. A PCA which is not prepared to exercise some judgement in this fashion is doing a disservice to the community as a whole. If I could have figured out a way to state that "backbone" and a sense of DN "good tatse" is a requirement for prospective PCAs, I would have put it in the RFCs. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19060; 25 Feb 93 18:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19053; 25 Feb 93 18:45 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa26738; 25 Feb 93 18:45 EST Received: by TIS.COM (4.1/SUN-5.64) id AA07102; Thu, 25 Feb 93 18:44:29 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA07096; Thu, 25 Feb 93 18:44:28 EST Received: from mwvm.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA25034; Thu, 25 Feb 1993 18:43:55 -0500 Received: from mwunix.mitre.org by mwvm.mitre.org (IBM VM SMTP V2R1) with TCP; Thu, 25 Feb 93 18:43:56 EST Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA25030; Thu, 25 Feb 1993 18:43:53 -0500 Message-Id: <199302252343.AA25030@mwunix.mitre.org> Date: Thu, 25 Feb 93 18:42:20 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: PostMast@mwmgate1.mitre.org To: "PEM-DEV at TIS.COM@MWUNIX" Subject: Undeliverable mail X-Orig-Sender: pem-dev-relay@tis.com Gateway MWMGATE1 could not deliver your mail to cc:Mail user w035_nw because of the error(s) cited below. Your undelivered message follows: - - - - - - - - - - - - - - - - - - - - - - - *** Unknown message recipient *** Subject: Re: Unique DNs Date: 25-FEB-1993 18:25:06 -------------- The following note was forwarded to you by AWAY... ------------- Received: from mwunix.mitre.org by mwvm.mitre.org (IBM VM SMTP V2R1) with TCP; Thu, 25 Feb 93 18:12:38 EST Return-Path: Received: from TIS.COM by mwunix.mitre.org (5.65c/SMI-2.2) id AA23854; Thu, 25 Feb 1993 18:12:35 -0500 Received: by TIS.COM (4.1/SUN-5.64) id AA26258; Thu, 25 Feb 93 16:55:02 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by TIS.COM (4.1/SUN-5.64) id AA26240; Thu, 25 Feb 93 16:54:58 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA03125; Thu, 25 Feb 93 13:52:51 -0800 To: vcerf@cnri.reston.va.us ("Vinton G. Cerf") Cc: pem-dev@TIS.COM, Carl Ellison , yee@atlas.arc.nasa.gov Reply-To: pem-dev@TIS.COM Subject: Re: Unique DNs In-Reply-To: Your message of "Thu, 25 Feb 1993 14:22:28 EST." <9302251422.aa13013@IETF.CNRI.Reston.VA.US> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Feb 1993 13:52:46 -0800 Message-Id: <3124.730677166@dbc.mtview.ca.us> From: Marshall Rose Sender: pem-dev-relay@TIS.COM I was purposefully vague in that part of my response, and I'm glad that you caught that. Once a DN has been assigned to an entity, then that entity gets to define the semantics associated with subordinate DNs. So, in the case of a CA and its customers, I don't think you have a problem. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19486; 25 Feb 93 19:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19479; 25 Feb 93 19:15 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa27843; 25 Feb 93 19:15 EST Received: by TIS.COM (4.1/SUN-5.64) id AA10496; Thu, 25 Feb 93 19:14:32 EST Received: from bells.cs.ucl.ac.uk by TIS.COM (4.1/SUN-5.64) id AA10486; Thu, 25 Feb 93 19:14:30 EST Message-Id: <9302260014.AA10486@TIS.COM> Received: from auchentoshan.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Feb 1993 00:13:52 +0000 To: pem-dev@tis.com Subject: Re: Unique DNs In-Reply-To: Your message of "Thu, 25 Feb 93 13:52:46 PST." <3124.730677166@dbc.mtview.ca.us> Date: Fri, 26 Feb 93 00:13:45 +0000 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Williams X-Orig-Sender: pem-dev-relay@tis.com >From: Marshall Rose >Subject: Re: Unique DNs >Date: Thu, 25 Feb 1993 13:52:46 -0800 > > Once a DN has been assigned to an entity, then that entity gets to > define the semantics associated with subordinate DNs. > Which semantics? It matters. Alot.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20194; 25 Feb 93 20:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20187; 25 Feb 93 20:09 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa29693; 25 Feb 93 20:09 EST Received: by TIS.COM (4.1/SUN-5.64) id AA14072; Thu, 25 Feb 93 20:08:12 EST Received: from MIT.EDU (MIT.MIT.EDU) by TIS.COM (4.1/SUN-5.64) id AA14066; Thu, 25 Feb 93 20:08:10 EST Received: from TMS-E19-PORT-7.MIT.EDU by MIT.EDU with SMTP id AA10368; Thu, 25 Feb 93 20:07:30 EST Message-Id: <9302260107.AA10368@MIT.EDU> Date: Thu, 25 Feb 93 20:07:29 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Raymond Lau To: pem-dev@tis.com Subject: Question on DNs X-Orig-Sender: pem-dev-relay@tis.com The entire DN discussion raises a question which pertains to implementation details rather than to naming conventions. The DN subordination requirement does not apply to the relationship betw. PCAs and CAs and betw. the ICIR and PCAs. But in an implementation, how is one to know when one has hit a PCA certificate? -Ray   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03506; 26 Feb 93 6:35 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03499; 26 Feb 93 6:35 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa05018; 26 Feb 93 6:35 EST Received: by TIS.COM (4.1/SUN-5.64) id AA02115; Fri, 26 Feb 93 06:35:28 EST Received: from relay2.UU.NET by TIS.COM (4.1/SUN-5.64) id AA02109; Fri, 26 Feb 93 06:35:27 EST Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25001; Fri, 26 Feb 93 06:34:52 -0500 Received: from localhost by toad.com id AA19341; Fri, 26 Feb 93 03:26:02 PST Message-Id: <9302261126.AA19341@toad.com> To: pem-dev@tis.com, gnu@toad.com Subject: Naming problem as a symptom Date: Fri, 26 Feb 93 03:25:59 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gnu@toad.com X-Orig-Sender: pem-dev-relay@tis.com Half of why PGP is now up and running all over the world, while PEM is still stumbling out of the starting gate, is that PGP completely eliminates two bottlenecks built into the PEM design: * you can't pick your own name * you have to register with an authority I tried to use PEM, but TIS would not give me the name I requested (O=gnu@cygnus.com). PEM's model is that somehow the naming conventions that everyone is already using (user@do.main) are ridiculous or inappropriate -- so let's invent a new kind of naming (DN's), and then introduce translations between them at every user. (E.g. I send mail to cerf@vint.net, it gets translated locally to c=xxx,o=yyy,foo=bar, then the key for that c=xxx,o=yyy,foo=bar is looked up locally, then the message is encrypted and sent. Why that first translation?) My model is that Internet domain email works *JUST FINE* for me, while every piece of mail I receive via an X.nnn gateway is full of screwiness. (E.g. MCI Mail from Esther Dyson now contains a 140-character return address.) I want a direct mapping between ordinary email names and names in PEM certificates. Someone suggested C=US,O=gnu@cygnus.com. But cygnus.com is valid in any country. I could move to Australia and keep gnu@cygnus.com. It's not tied to geography. The Domain Name System is up and running worldwide. Let's use it. Of course, there is no problem with duplicate assignments, since there is already a multi level registration of domain names and user names. Happily *that* system doesn't care what name you register -- it only rejects names if they are already in use. The main objection raised to this sort of easy and obvious name is, "When the X.500 revolution comes, your name will be lined up against the wall and shot". I'm perfectly willing to take that chance, given my own personal estimate of the usefulness of X.400 and X.500. Let me guess -- about twenty influential people on this list are unwilling for me to *have* that choice. And that's why PGP is winning, and will continue to win, though it is inferior technically. Because it doesn't impose arbitrary and inappropriate models on its users: it just encrypts, decrypts, hashes, certifies, looks up keys, and does key maintenance. Funny, that. It might even end up integrated into MIME before PEM does. John Gilmore   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04719; 26 Feb 93 8:57 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04712; 26 Feb 93 8:57 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa07961; 26 Feb 93 8:57 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06262; Fri, 26 Feb 93 08:57:59 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA06255; Fri, 26 Feb 93 08:57:57 EST Message-Id: <9302261357.AA06255@TIS.COM> Reply-To: James M Galvin To: Raymond Lau Cc: pem-dev@tis.com Subject: Re: Question on DNs In-Reply-To: 's message of Thu, 25 Feb 93 20:07:29 EST. <9302260107.AA10368@MIT.EDU> Date: Fri, 26 Feb 93 08:57:50 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin X-Orig-Sender: pem-dev-relay@tis.com -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,DZLk4MLUeil5XKhFUwWXkTt5WSxVNN2SGidQnKUK0/Z QFYHvAkF7RiceDum1BDLCmbD3psWcaJ/GS45ZG/5XZQ== The DN subordination requirement does not apply to the relationship betw. PCAs and CAs and betw. the ICIR and PCAs. But in an implementation, how is one to know when one has hit a PCA certificate? An implementation would know if it knew the IPRA public key (or certificate) a priori. (Yes, the name of the "root" has changed yet again. The previous acronym is being used -- IPRA -- but it now expands to Internet PCA Registration Authority.) Only PCAs are certified immediately under the "root". Jim -----END PRIVACY-ENHANCED MESSAGE-----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05295; 26 Feb 93 9:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05288; 26 Feb 93 9:45 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa09628; 26 Feb 93 9:44 EST Received: by TIS.COM (4.1/SUN-5.64) id AA08504; Fri, 26 Feb 93 09:44:58 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA08498; Fri, 26 Feb 93 09:44:57 EST Received: from smiley.mitre.org.sit (smiley.mitre.org) by mwunix.mitre.org (5.65c/SMI-2.2) id AA24299; Fri, 26 Feb 1993 09:44:24 -0500 Received: from [128.29.140.100] (shirey-mac.mitre.org) by smiley.mitre.org.sit (4.1/SMI-4.1) id AA04836; Fri, 26 Feb 93 09:44:07 EST Message-Id: <9302261444.AA04836@smiley.mitre.org.sit> Date: Fri, 26 Feb 1993 09:46:52 -0500 To: gnu@toad.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Robert W. Shirey" X-Sender: shirey@smiley.mitre.org Subject: Re: Naming problem as a symptom Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com John, Let's set the naming issue aside for a minute to explore another area. I know you have though about this at length, and I would like to hear your forecast. Just for the sake of argument, let me cast you in the role of PGP advocate trying to sell me on using PGP, possibly integrated with MIME, in my corporate environment. As an individual, I can go to a server (and I have) to get a copy of PGP to analyze from an academic viewpoint. Even if I exchange a few PGP messages with you, Jim Bidzos is unlike to take legal action against me. As the MITRE Corporation, though, I would be looking to deploy PGP on all employee workstations (several thousand of them). I don't want to do implementation and maintenance in-house for common office automation applications, so I want a well-supported COTS package that is integrated with my environment. In that case, aren't I going to get into considerable trouble using RSA without a license? It's bad enough that I have to worry about the Software Publishers Association raiding me because of tip from a disgruntled employee, even though I have stringent formal policies against software piracy. Why should I risk a patent suit? MITRE only has about 6,000 employees. Look at the risk that would be incurred by an GM or a Campbell's Soup. Doesn't this situation place a severe limit on PGP being able to scale to the world? Regards, -Rob- Robert W. Shirey, The MITRE Corporation, Mail Stop Z202 7525 Colshire Dr., McLean, Virginia 22102-3481 USA shirey@mitre.org * tel 703-883-7210 * fax 703-883-1397   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06925; 26 Feb 93 11:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06918; 26 Feb 93 11:26 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa12859; 26 Feb 93 11:26 EST Received: by TIS.COM (4.1/SUN-5.64) id AA13580; Fri, 26 Feb 93 11:26:44 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA13573; Fri, 26 Feb 93 11:26:42 EST Message-Id: <9302261626.AA13573@TIS.COM> To: gnu@toad.com Cc: pem-dev@tis.com Subject: Re: Naming problem as a symptom Date: Fri, 26 Feb 93 11:25:57 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com John, I'll address only the name issues, not the PGP patent infrigmenet issues. First, PEM didn not invent distinguished names for use in certificates, we adopted an international standard for certificates in which the form of names is defined. Second, althohgh DNS names, as cited in your message, are widely used and workable, they are deficient in many ways. First, many (most?) DNS names terribly US-centric. We really ought not have the top level domains for COM, EDU, ORG, GOV, MIL, etc. There are carryovers from the early days of the Internet. Top level domains as countries are more appropriate for a system, with internationl aspirations. Although there are lots of users registered under DNS, that does not mean that DNS will scale well into the commercial arena, where conflcits over who has rights to short names (often acronyms) will arise. We already are having problems with delegation of naming authority in the DNS in an increasingly fractious new world order. So, inductive logic applied to the success of DNS names to date is not persuasive when arguing about names for an ever growing system. Third, DNS names, because they tend to be short, are often not very descriptive. In general you cannot tell, a priori, whether my mailbox at BBN is STK, SKENT, STKENT, or KENT. In any large organization short name conflicts arise quickly as first or first and middle initial differentation leads to conflicts. What PEM wants are globally unique names which can easily be related to real world attributes, so that the likelihood of name collision errors do not permeate secure email exchanges. Fourth, PGP embodies the "Friends and Family" certification model, which requires out-of-band arangements and a potentially complex trust model to assign trust accuracy to name binding (not the the entities identified by the names) implied by this mesh certification model. While that may work well for modest numbers of users, there is considerable belief that it does not scale well for tens of millions of users on a worldwide basis, nor that it will support business demands for certification assurance. John, you cite the relative success of PGP deployment vs. PEM as indicative of user preference for a system which requires less of an infrastructure. That may be true, but I don't believe that the results are in yet. It is often easier to build and deploy a system with minimal infrastructure requirements and, perhaps, more modest goals for scaling, assurance ranges, etc. PEM has more agressive goals and, as a result, requires more infrastructure. Ultimately time will tell which strategy proves more successful. (Even that is not a certain indication of which is "better.") Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09379; 26 Feb 93 13:45 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09368; 26 Feb 93 13:45 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa17228; 26 Feb 93 13:45 EST Received: by TIS.COM (4.1/SUN-5.64) id AA20292; Fri, 26 Feb 93 13:45:38 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA20278; Fri, 26 Feb 93 13:45:35 EST Message-Id: <9302261845.AA20278@TIS.COM> To: Carl Ellison Cc: pem-dev@tis.com Subject: Re: Unique DNs In-Reply-To: Your message of Thu, 25 Feb 93 10:48:33 -0500. <9302251548.AA07369@ellisun.sw.stratus.com> Date: Fri, 26 Feb 93 13:44:48 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Carl, PEM makes use of certificates to provide sereval security services. The sender of a PEM message would like to be able to unabmigously identify each recipient. While unambiguous identification could be provided in a variety of ways, PEM uses the DNs bound into X.509 certificates to achieve this in a fashion which should be able to scale to encompass a very large (worldwide) system of users. It should be possible for a PEM user to send (encrypyed) mail to someone with whom he has never communicated via email, and thus for whom the sender does not have knowledge of the recipient's mailbox name, etc. Being able to determine the mailbox address for a user with whom you have nevert exchanged email is a goal of directory services such as X.500. Our intent with PEM is to extend this capability to the secure email domain. (Note that the names used in PEM for authentication are not used for routing decisions; these names are in addition to, not in lieu of, the exitsing DNS mailbox names.) Thus, we want identifiers for users which can be matched to various real world user attributes. This makes it likely that the identifier securely bound to the user's public key can be independently evaluated by a prospective sender as being the identifier for the "right" user. Also, we don not want to have to trust widely available databases (directories) to maintain bindings between keys and names, hence the use of certificates, signed key-name binding data structures. From a recipient's perspective, receipt of a signed message is not very useful if the identity of the sender cannot be established. It is technically feasible to send signed email to ANY recipient without ANY prior arrangement on the part of the recipient. In this situation, it is especially useful if the recipient can verify the signature and be able to determine the (unambiguous) identity of the sender simply by examining the sender's (cryptographically verified) identity, and relating this identiti to the sort of realworld attributes alluded to earlier. PEM originally dictated a high assurnace binding of DNs to keys, but there was considerable sentiment that this level of assurnace was not uniformly practical and that there were also personal privacy reasons for accommodating other forms of identity binding. Thus the current PEM certification scheme incorporates a layer of policy CAs to allow for varying levels of confidence in the name-key binding in a fashion which allows the user to make an informed value judgement about the binding. None of this disputes your observation that there are other ways to provide identifier-key bindings. However, schemes which do not ensure global uniqueness of identifiers, do not seem likely to scale well, or may make it easy for users to be confused by duplicate names are unsuitable. Schemes which do not provide a well defined means of allowing all users to make informed judgements about the quality of the name-key binding are likely to result in confusion for users and maybe some very nasty surprizes. Schemes which rely on users carefully examining a sequence of certificates to establish a sense of trust in the name-key binding seem unsuited to scaling and to a user population which has trouble programming VCRs. Thus PEM has adopted the X.500 model for naming and certification and imposed some constraints on that (very general) model to explicitly accommodate diverse certification policies. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09831; 26 Feb 93 13:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09822; 26 Feb 93 13:59 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa17646; 26 Feb 93 13:59 EST Received: by TIS.COM (4.1/SUN-5.64) id AA20926; Fri, 26 Feb 93 13:59:13 EST Received: from relay2.UU.NET by TIS.COM (4.1/SUN-5.64) id AA20920; Fri, 26 Feb 93 13:59:10 EST Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA02127; Fri, 26 Feb 93 13:58:36 -0500 Received: from localhost by toad.com id AA28440; Fri, 26 Feb 93 10:59:37 PST Message-Id: <9302261859.AA28440@toad.com> To: "Robert W. Shirey" Cc: pem-dev@tis.com, gnu@toad.com Subject: Re: PGP legality In-Reply-To: <9302261444.AA04836@smiley.mitre.org.sit> Date: Fri, 26 Feb 93 10:59:34 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gnu@toad.com X-Orig-Sender: pem-dev-relay@tis.com > Why should I risk a patent suit? Doesn't > this situation place a severe limit on PGP being able to scale to the > world? First, the world is much larger than the United States, and the patent is only enforceable in the U.S. And commercial PEM products can't leave the U.S, while PGP is already out there (and its developers are outside the U.S too). Second, there is no reason (other than bile between Jim Bidzos and Phil Zimmerman) that US users could not be licensed to use PGP. Indeed, I suspect that any company with an RSA license (Sun, IBM, Apple, Microsoft,...) is already licensed to run PGP, or any other program that makes use of RSA -- at least if they keep track of the number of inhouse users and pay the appropriate royalty. I once proposed to Jim Bidzos that RSADSI sell lifetime rights to their patents to individuals for $100. When a child reached the age where they needed cryptographic protection, a parent or godparent would gift them with this necessity of modern life. RSADSI would not suffer by eventually getting $100 from every person in the U.S... I bet there are more than a thousand users of PGP today, who would pay $100 for a lifetime license to use RSA's current and future patents. Then they'd be free to use whatever software they liked, for protecting their email, net connections, phone calls, or whatever -- without being stuck with less-workable software because of legal issues. John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10049; 26 Feb 93 14:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10042; 26 Feb 93 14:13 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa18198; 26 Feb 93 14:13 EST Received: by TIS.COM (4.1/SUN-5.64) id AA21591; Fri, 26 Feb 93 14:13:18 EST Received: from Athena.MIT.EDU (ATHENA-AS-WELL.MIT.EDU) by TIS.COM (4.1/SUN-5.64) id AA21584; Fri, 26 Feb 93 14:13:16 EST Received: from PESTO.MIT.EDU by Athena.MIT.EDU with SMTP id AA03778; Fri, 26 Feb 93 14:12:35 EST Received: by pesto (5.57/4.7) id AA22197; Fri, 26 Feb 93 14:12:32 -0500 Date: Fri, 26 Feb 93 14:12:32 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Sommerfeld Message-Id: <9302261912.AA22197@pesto> To: Steve Kent Cc: gnu@toad.com, pem-dev@tis.com In-Reply-To: Steve Kent's message of Fri, 26 Feb 93 11:25:57 -0500, <9302261626.AA13573@TIS.COM> Subject: Re: Naming problem as a symptom X-Orig-Sender: pem-dev-relay@tis.com Top level domains as countries are more appropriate for a system, with internationl aspirations. What do you do about *organizations* with international aspirations? Third, DNS names, because they tend to be short, are often not very descriptive. In general you cannot tell, a priori, whether my mailbox at BBN is STK, SKENT, STKENT, or KENT. So you use finger or netfind or X.500 or a similar distributed phonebook to look up your email address, then hang on to it and use it. (does x.500 have a "rfc822 mail address" field? If not, why not? :-) ) Think "email address == phone number." - Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10316; 26 Feb 93 14:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10309; 26 Feb 93 14:27 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa18999; 26 Feb 93 14:27 EST Received: by TIS.COM (4.1/SUN-5.64) id AA22528; Fri, 26 Feb 93 14:27:05 EST Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA22522; Fri, 26 Feb 93 14:27:03 EST Message-Id: <9302261927.AA22522@TIS.COM> To: pem-dev@tis.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: List Master (agent: David Balenson) Subject: FYI: Revised PEM-DEV announcement Date: Fri, 26 Feb 93 14:27:03 -0500 X-Orig-Sender: pem-dev-relay@tis.com The recent release of the PEM RFCs prompted me to revise the "official" PEM-DEV announcement, which I am attaching below, for your information. -DB ----- The PEM-DEV mailing list has been created for discussions related to the development and deployment of Privacy Enhanced Mail (PEM) systems. PEM is an IAB standards track protocol for the Internet community, and is now a Proposed Standard Protocol. PEM specifies protocol extensions and processing procedures for cryptographic-based message encipherment and authentication for electronic mail transferred using the Internet mail protocols. PEM includes the specification of a supporting key management architecture and infrastructure, based on public key certificates. The key management architecure is compatible with the authentication framework described in CCITT X.509, The Directory - Authentication Framework. PEM is defined in a series of four documents: RFC 1421: Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management RFC 1423: Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers RFC 1424: Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services Various organizations are jointly developing RFC-compliant software for deployment in the Internet in order to encourage the use and development of RFC-based privacy enhanced mail systems. The PEM-DEV mailing list is intended to cover a wide range of discussion including: o General discussion among the members of the Internet Engineering Task Force (IETF) PEM Working Group. o Issues related to the protocol extensions and message processing procedures and the key management architecture and infrastructure. o Issues related to the development and deployment of privacy enhanced mail systems, including technical issues, development status, availability, etc. Please send contributions to the list proper to "pem-dev@tis.com". Administrivia, e.g., additions to or deletions from the list, should be sent to "pem-dev-request@tis.com". The archives are available by sending a message to "pem-dev-request@tis.com". The message must contain two fields, a Subject field and a Reply-To field, which must be located and formatted as described below: (1) The Subject field of the message must be located in the headers of the message, and must be formatted as follows: Subject: get pem-dev archive volume VOL number NUM where "VOL" is the volume number of the digest and "NUM" is the number of that volume. Do NOT including leading zeroes. The volume number changes when it is convenient for the maintainer, not at specific intervals. (2) The Reply-To field can be located either in the body or in the headers of the message, and must be formatted as follows: Reply-To: ADDRESS where "ADDRESS" is your address AS IT WOULD LOOK TO MY HOST. I will help you determine that address if you need it. If you place the "reply-to" in the headers rather than the body, you must be certain that it will be altered properly along the path to me so that it reflects the proper return address. The third of three volumes is currently under construction. An index is available for each volume. It may be retrieved by requesting number 0 of the desired volume. The index consists of a collection of the subject lines of all messages in all the digests of the requested volume, preceded by the digest number in which that subject line appears. -David Balenson   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10850; 26 Feb 93 14:47 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10843; 26 Feb 93 14:47 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa19982; 26 Feb 93 14:47 EST Received: by TIS.COM (4.1/SUN-5.64) id AA23550; Fri, 26 Feb 93 14:47:25 EST Received: from RSA.COM (CHIRALITY.RSA.COM) by TIS.COM (4.1/SUN-5.64) id AA23542; Fri, 26 Feb 93 14:47:21 EST Received: by RSA.COM id AA01482; Fri, 26 Feb 93 11:44:14 PST Date: Fri, 26 Feb 93 11:44:14 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Dusse Message-Id: <9302261944.AA01482@RSA.COM> To: pem-dev@tis.com In-Reply-To: Steve Kent's message of Thu, 25 Feb 93 17:59:46 -0500 <9302252300.AA05229@TIS.COM> Subject: Unique DNs X-Orig-Sender: pem-dev-relay@tis.com Howdy GentlePemAndX.500Folks, Thanks to Steve Kent for refocusing the DN discussion. RSA Data Security, Inc. intends to become a PCA for some commercial and residential users. I have been following the X.500 DN discussion and have kept familiar with the NADF-175 and SD-5. As we will most likely be certifying a number or entities that have no prior experience with X.500, we will be in the unfortunate position of counseling people on their choice of Distinguished Names for their certificates. Because of the recent sentiment on this mailing list that we should align as much as possible to the SD-5, let's see if I have this all correct and throw out a few questions at the same time. An organization can have national standing if the organization is created and named by the U.S. Congress. 1. What form of proof of RTU (Right-To-Use) for a name might we expect to see from such an organization ? An organization might also have national standing conferred upon it by registering under ANSI. This sounds reasonable as we can ask for a copy of the resulting ANSI documentation (indeed RSA Data Security, Inc. has already performed this registration). An organization may have regional standing conferred upon it 'by registering with the "Secretary of State" (or similar entity) within that region - this is termed a "doing business as" (DBA) registration.' However, they may have DBA registration in several (perhaps all 50) states. Each such registration probably is embodied in some sort of business license and (at least in the state or states or incorporation) some incorporation papers, so proof of RTU is likely to be straightforward. An organization may have local standing conferred upon it by a DBA registration with a "County Clerk" (or similar entity) within that place. However, they may have DBA registration in several localities. Each such registration probably is embodied in some sort of business license so proof of RTU is likely to be straightforward. Now, all we have to do is help organizations decide on a DN for their PEM certificates. Let's see if the SD-5 can help me out here. 2.3 Listing Algorithm The final step is to define how entities are listed within the context of the civil naming infrastructure. Once again, Note that an entity may have several listings (DNs) in different parts of the Directory. YIKES ! Now I'm really stuck. It looks like an organization generally has the same Attribute-Value Assertions in each of their distinct DNs (depending on where they list), however, they appear on different levels. As you all know, even moving an attribute from one level to another affects the Distinguished Encoding of a name, hence, each certificate corresponds to exactly one DN. 2. Should we create a certificate for each DN that the organization has listed ? What if they haven't listed anywhere ? Should we make up a DN based on their standing ? What about the regional orgs. that have listed in multiple states or the local orgs. that have listed in multiple locales. How should they choose a DN ? OK, perhaps with enough people-time and careful counseling we can get through the Org. certification without too much bloodshed. Now let's move on to persons. "Listing organizational persons is a local matter to be decided by each organization." -Phew :-) 'Residential persons are identified by the place where they reside, usually with a multi-valued RDN consisting of a commonName attribute value, and some other distinguished attribute value. Although an obvious choice is to use something like postalCode or streetAddress, it shouldbe noted that this information may be considered private. Hence, some other, distinguishing attribute value may be used - possibly even a "serial number" attribute value (assigned b an ADDMD) which has no other purpose other than to give uniqueness.' We would really love to acommodate those hordes of users that have already listed. But what about those few that haven't. 3. Do we force individuals to list before they can get a certificate ? If we don't require listing, what DN should an individual use with their certificate ? Let's take a peek at Canada and see if any of the issues get any easier. In general, organizations achieve standing by registering an alphanumeric name value in accordance with the procedures in CSA Z243.110.1. "No existing registry of localities has been identified to date." 4. Is this the "existing" civil infrastructure that Canadian organizations have been utilizing to register names ? If not, should we require such registration before we certify them ? What form of proof of RTU might we expect from Canadian organizations ? "...an entity may have a single name or two names (one in each of the Canadian official languages). As such, the naming scheme allows dual-named entities to use either or both name when constructing listings." 5. Should a single DN have multiple attribute-value assuertions for the same attribute corresponding to "each of the Canadian official languages" ? In summary, the SD-5 provides some guidelines for listing entities in the DIT based on existing registration infrastructure. Now for the hard part, how does this help an entity choose a DN for their certificate ? Cheers, Steve Dusse p.s. The questions are not as facetious as they sound. We are really struggling with these issues. Positive input is appreciated.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11260; 26 Feb 93 15:07 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11251; 26 Feb 93 15:07 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa20796; 26 Feb 93 15:07 EST Received: by TIS.COM (4.1/SUN-5.64) id AA24074; Fri, 26 Feb 93 15:07:24 EST Received: from med3.minerva.com by TIS.COM (4.1/SUN-5.64) id AA24068; Fri, 26 Feb 93 15:07:20 EST Message-Id: <9302262007.AA24068@TIS.COM> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gvb@med3.minerva.com Date: Fri, 26 Feb 93 12:06 PST To: gnu@toad.com, pem-dev@tis.com Subject: Re: Naming problem as a symptom Content-Type: text Content-Length: 658 X-Orig-Sender: pem-dev-relay@tis.com It IS unfortunate that the politically transcendent modes of DNS use, irritate politicians. But that should surprise no one, and politicians rule global standardization, which should also surprise no one. As Stef reminded us, you can't create a global naming convention by fiat that will be accepted widely enough to take the next scaling steps. The lawyers will simply start litigating. It is strange that DNS was not globally chosen since it can easily be adapted to the limited geographic use such as NADF mechanized, while retaining the ability for organizations to overlap geographic boundaries. The horse is after all dead, isn't it? - Greg Bailey   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12293; 26 Feb 93 16:07 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12286; 26 Feb 93 16:07 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa22542; 26 Feb 93 16:07 EST Received: by TIS.COM (4.1/SUN-5.64) id AA26070; Fri, 26 Feb 93 16:07:27 EST Received: from inet-gw-1.pa.dec.com by TIS.COM (4.1/SUN-5.64) id AA26064; Fri, 26 Feb 93 16:07:25 EST Received: by inet-gw-1.pa.dec.com; id AA26362; Fri, 26 Feb 93 13:06:50 -0800 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA14700 for pem-dev@TIS.COM; Fri, 26 Feb 93 16:07:20 -0500 Message-Id: <9302262107.AA14700@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: gnu@toad.com Cc: pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of "Fri, 26 Feb 93 03:25:59 PST." <9302261126.AA19341@toad.com> Date: Fri, 26 Feb 93 16:07:20 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp X-Orig-Sender: pem-dev-relay@tis.com From: gnu@toad.com >Half of why PGP is now up and running all over the world, while PEM is >still stumbling out of the starting gate, is that PGP completely eliminates >two bottlenecks built into the PEM design: > * you can't pick your own name > * you have to register with an authority >I tried to use PEM, but TIS would not give me the name I requested >(O=gnu@cygnus.com). I have to agree the I am very umimpressed with all this X.500 complexity and huffing and puffing about "sovereign states" controlling naming, etc. X.500 strict hierarchial paralysis around countries is simply what you get from a political process rather than a techncial one (not that it is ever completely black or white). >PEM's model is that somehow the naming conventions that everyone is >already using (user@do.main) are ridiculous or inappropriate -- so >let's invent a new kind of naming (DN's), and then introduce >translations between them at every user. (E.g. I send mail to >cerf@vint.net, it gets translated locally to c=xxx,o=yyy,foo=bar, then >the key for that c=xxx,o=yyy,foo=bar is looked up locally, then the >message is encrypted and sent. Why that first translation?) >My model is that Internet domain email works *JUST FINE* for me, while >every piece of mail I receive via an X.nnn gateway is full of >screwiness. (E.g. MCI Mail from Esther Dyson now contains a >140-character return address.) I want a direct mapping between >ordinary email names and names in PEM certificates. I particularly like the habit many X.400 gateways have of either throwing away my mail without telling me or sometimes sending a bounce indication back with no hint of what message it was that bounced, other than the addressee. (no date, subject line, body copy, etc.) >Someone suggested C=US,O=gnu@cygnus.com. But cygnus.com is valid in any >country. I could move to Australia and keep gnu@cygnus.com. It's not tied >to geography. The Domain Name System is up and running worldwide. Let's >use it. Well, who knows, maybe there are people with that sort of name somewhere... but I don't see any problems at all with C=INTERNET,O=user@f.q.d.n. Someone should start a service issuing PEM certificates like and if the PEM hierarchy won't let they joint, they should just start their own hierarchy. >Of course, there is no problem with duplicate assignments, since there >is already a multi level registration of domain names and user names. >Happily *that* system doesn't care what name you register -- it only >rejects names if they are already in use. >The main objection raised to this sort of easy and obvious name is, >"When the X.500 revolution comes, your name will be lined up against >the wall and shot". I'm perfectly willing to take that chance, given >my own personal estimate of the usefulness of X.400 and X.500. >Let me guess -- about twenty influential people on this list are >unwilling for me to *have* that choice. And that's why PGP is >winning, and will continue to win, though it is inferior technically. >Because it doesn't impose arbitrary and inappropriate models on its >users: it just encrypts, decrypts, hashes, certifies, looks up keys, >and does key maintenance. Funny, that. It might even end up >integrated into MIME before PEM does. I waiting for the next round of PEM/MIME integration drafts to study and make sure they are usable with PGP. In fact, you should be able to send a message with both PEM and PGP and X-whatever signatures. If the proposed format won't allow that, it needs to be expanded to be able to do so. > John Gilmore Donald E. Eastlake, III   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12516; 26 Feb 93 16:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12509; 26 Feb 93 16:17 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa22914; 26 Feb 93 16:17 EST Received: by TIS.COM (4.1/SUN-5.64) id AA26553; Fri, 26 Feb 93 16:17:35 EST Received: from netcom2.netcom.com by TIS.COM (4.1/SUN-5.64) id AA26547; Fri, 26 Feb 93 16:17:33 EST Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) id AA02780; Fri, 26 Feb 93 13:16:37 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Sternlight Message-Id: <9302262116.AA02780@netcom2.netcom.com> Subject: Re: PGP legality To: gnu@toad.com Date: Fri, 26 Feb 1993 13:16:36 -0800 (PST) Cc: pem-dev@tis.com, shirey@mitre.org In-Reply-To: <9302261859.AA28440@toad.com> from "gnu@toad.com" at Feb 26, 93 10:59:34 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1755 X-Orig-Sender: pem-dev-relay@tis.com > > > Why should I risk a patent suit? Doesn't > > this situation place a severe limit on PGP being able to scale to the > > world? > > First, the world is much larger than the United States, and the patent > is only enforceable in the U.S. And commercial PEM products can't > leave the U.S, while PGP is already out there (and its developers are > outside the U.S too). Irrelevant. Cryptography in France requires the permission of the Prime Minister or his designee. In Australia it is forbidden. Thus there can be no universal solution and any proposed one must be legal in the U.S. Further, Ripem is legal in the U.S. and also "out there", and the public key list on the server is rapidly approaching the number of keys reported for PGP in some messages. > > Second, there is no reason (other than bile between Jim Bidzos and > Phil Zimmerman) that US users could not be licensed to use PGP. False. It's not personal between Bidzos and Zimmerman but that Bidzos, as the head of a firm with patents, wants his rights under his patents, and Zimmerman wanted a free license. To reduce this issue to an assertion of a personal quarrel is simply incorrect, and has no place in a group discussing formal standards. What prevents US users from being licensed to use PGP is that is infringes RSA's patents and further, there's no import license from the Government for IDEA. > Indeed, I suspect that any company with an RSA license (Sun, IBM, > Apple, Microsoft,...) is already licensed to run PGP, or any other > program that makes use of RSA -- at least if they keep track of the > number of inhouse users and pay the appropriate royalty. Questionable. Does the RSA license permit this? In any case there's no IDEA import license in the U.S. David   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12565; 26 Feb 93 16:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12558; 26 Feb 93 16:19 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa22965; 26 Feb 93 16:19 EST Received: by TIS.COM (4.1/SUN-5.64) id AA26721; Fri, 26 Feb 93 16:20:10 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA26713; Fri, 26 Feb 93 16:20:08 EST Message-Id: <9302262120.AA26713@TIS.COM> To: Bill Sommerfeld Cc: pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of Fri, 26 Feb 93 14:12:32 -0500. <9302261912.AA22197@pesto> Date: Fri, 26 Feb 93 16:19:34 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Bill, X.500 includes various provisions for registering multi-national corporations. I'll leave it as an exercise to the interested parties to read X.500 and the work of profiling groups to see how that is done. (Hint: alias entries are used.) And yes, there are X.500 directories with rfc-822 attributes in entries. I think you'll find that many (most?) of the users registered in the QUIPU X.500 directories have their DNS mailbox names in their entries. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12824; 26 Feb 93 16:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12817; 26 Feb 93 16:34 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa23416; 26 Feb 93 16:34 EST Received: by TIS.COM (4.1/SUN-5.64) id AA27236; Fri, 26 Feb 93 16:34:56 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA27230; Fri, 26 Feb 93 16:34:53 EST Message-Id: <9302262134.AA27230@TIS.COM> To: Bill Sommerfeld Cc: pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of Fri, 26 Feb 93 14:12:32 -0500. <9302261912.AA22197@pesto> Date: Fri, 26 Feb 93 16:34:14 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Bill, I looked more closely at your second comment and realized that I misunderstood your point. Using a directory with descriptive naming to fetch a certificate which contains a not very descriptive name reuires trust in directories and (integrity-) secure communication with directories. Given a very large directory system, this is not an especially confidence-inspiring model. (Note that DNS spoofing is already a source of attacks today.) Also, PEM allows message senders to pass along full certification paths with in PEM messages, minimizing the need for users to access directories to fetch certificates. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13308; 26 Feb 93 16:57 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13301; 26 Feb 93 16:57 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24360; 26 Feb 93 16:57 EST Received: by TIS.COM (4.1/SUN-5.64) id AA28356; Fri, 26 Feb 93 16:57:17 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA28350; Fri, 26 Feb 93 16:57:15 EST Message-Id: <9302262157.AA28350@TIS.COM> To: Raymond Lau Cc: pem-dev@tis.com Subject: Re: Question on DNs In-Reply-To: Your message of Thu, 25 Feb 93 20:07:29 -0500. <9302260107.AA10368@MIT.EDU> Date: Fri, 26 Feb 93 16:56:40 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Ray, As Jim pointed out, the IPRA is the root of the tree and it's public key is acquired through some out-of-band means. There is no entity to sign a certificate for the root (no entity is superior to it) so it's entry is special and can be appropriately tagged as such in the database. The IPRA certifies only PCAs, making them the second level of the tree. Their entries can be taged with an PCA marking, or it can be inferred by their direct relationship to the root (IPRA). CAs start at level 3, and may appear at lower layers as well. The name subordination rule applies to entries at level 4 and below, i.e., a level 4 (or lower) certificate must contain a subject name subordinate to its issuer name. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13738; 26 Feb 93 17:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13731; 26 Feb 93 17:12 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24829; 26 Feb 93 17:12 EST Received: by TIS.COM (4.1/SUN-5.64) id AA29082; Fri, 26 Feb 93 17:12:58 EST Received: from transfer.stratus.com by TIS.COM (4.1/SUN-5.64) id AA29076; Fri, 26 Feb 93 17:12:56 EST Received: from lectroid.sw.stratus.com by transfer.stratus.com (4.1/3.12-jjm) id AA07454; Fri, 26 Feb 93 17:12:22 EST Received: from ellisun.sw.stratus.com by lectroid.sw.stratus.com (4.1/3.8-jjm) id AA00723; Fri, 26 Feb 93 17:12:21 EST Received: by ellisun.sw.stratus.com (4.1/SMI-4.1) id AA10929; Fri, 26 Feb 93 17:12:20 EST Date: Fri, 26 Feb 93 17:12:20 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Carl Ellison Message-Id: <9302262212.AA10929@ellisun.sw.stratus.com> To: pem-dev@tis.com Subject: Re: Unique DNs X-Orig-Sender: pem-dev-relay@tis.com >Message-Id: <9302261844.AA00982@transfer.stratus.com> >Subject: Re: Unique DNs >Date: Fri, 26 Feb 93 13:44:48 -0500 Steve, I appreciate your desires with PEM and your absolute need for unique names. I understand that you chose the path of X.500 DNs to provide those unique names. I can understand X.500's desire to have unique names entirely apart from PEM and I would assume that it looked like a natural fit to just borrow their names. All I've been trying to point out is that if people want uniqueness of names, it already exists in keys. I bother to point this out only because it seems that X.500 name uniqueness is not a well-established fact. In fact, no one in Stratus is listed in an X.500 database, as far as I know, and I wonder when (and if) it will ever come to be. That's a side issue. The issue to me is only to point out that uniqueness is there already for PEM, given that every PEM user has a public key. You wrote: > None of this disputes your observation that there are other >ways to provide identifier-key bindings. However, schemes which do >not ensure global uniqueness of identifiers, do not seem likely to >scale well, or may make it easy for users to be confused by duplicate >names are unsuitable. My public key is a unique name. At 1024 bits, it doesn't need to scale any more. There's no chance of duplicate names to confuse users. Of course, for a human to make any sense of my n=pk (name = public key), he'd want something readable -- like my spoken name, my company, my e-mail address, my list of interests, .... These real-world attributes need to be bound to my n=pk and that binding calls for a database of signed messages declaring/certifying/claiming that those attributes are true. It's entirely possible that if you start with my n=pk as the unique element in this set of correlated records about me rather than demand that my DN be unique (or that I even have one assigned), you might end up with the same certification hierarchy which PEM has today. It might be a little different here and there. All I tried to say when I jumped into the discussion was that if n=pk were the unique name, then pem-dev would be free of the flame war which I see raging around X.500. I'm sorry if I've distracted any of pem-dev from useful work. - Carl   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13856; 26 Feb 93 17:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13849; 26 Feb 93 17:15 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa24963; 26 Feb 93 17:15 EST Received: by TIS.COM (4.1/SUN-5.64) id AA29267; Fri, 26 Feb 93 17:16:13 EST Received: from uswat.advtech.uswest.com by TIS.COM (4.1/SUN-5.64) id AA29261; Fri, 26 Feb 93 17:16:11 EST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA15215 (5.65c/IDA-1.4.4 for ); Fri, 26 Feb 1993 15:15:30 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA12382 (4.1/at-generic.11Feb92); Fri, 26 Feb 93 15:15:28 MST Message-Id: <9302262215.AA12382@futureworld.advtech.uswest.com> To: gnu@toad.com Cc: "Robert W. Shirey" , pem-dev@tis.com Subject: Re: PGP legality In-Reply-To: Your message of "Fri, 26 Feb 1993 10:59:34 PST." <9302261859.AA28440@toad.com> Date: Fri, 26 Feb 1993 15:15:28 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brad Huntting X-Orig-Sender: pem-dev-relay@tis.com > Second, there is no reason (other than bile between Jim Bidzos and > Phil Zimmerman) that US users could not be licensed to use PGP. > Indeed, I suspect that any company with an RSA license (Sun, IBM, > Apple, Microsoft,...) is already licensed to run PGP, or any other > program that makes use of RSA -- at least if they keep track of the > number of inhouse users and pay the appropriate royalty. There's really no reason why PGP couldn't be rewriten to use rsaref either. brad   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13958; 26 Feb 93 17:22 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13951; 26 Feb 93 17:22 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa25169; 26 Feb 93 17:22 EST Received: by TIS.COM (4.1/SUN-5.64) id AA29454; Fri, 26 Feb 93 17:22:16 EST Received: from uswat.advtech.uswest.com by TIS.COM (4.1/SUN-5.64) id AA29448; Fri, 26 Feb 93 17:22:14 EST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA15336 (5.65c/IDA-1.4.4 for ); Fri, 26 Feb 1993 15:21:40 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA12412 (4.1/at-generic.11Feb92); Fri, 26 Feb 93 15:21:43 MST Message-Id: <9302262221.AA12412@futureworld.advtech.uswest.com> To: Bill Sommerfeld Cc: Steve Kent , gnu@toad.com, pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of "Fri, 26 Feb 1993 14:12:32 EST." <9302261912.AA22197@pesto> Date: Fri, 26 Feb 1993 15:21:43 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brad Huntting X-Orig-Sender: pem-dev-relay@tis.com > Top level domains as > countries are more appropriate for a system, with internationl > aspirations. This is hog wash. Transnational corporations are here today in a big way. Furthermore, if you looks under o=Internet in the DIT you will see that there are hierarchies specificly aranged to mimic DNS nameed "domainComponent=com" etc. There is no reason why (at least some) DN's and their certificates could not be stored in both DNS and X.500. brad   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14787; 26 Feb 93 18:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14780; 26 Feb 93 18:04 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa26541; 26 Feb 93 18:04 EST Received: by TIS.COM (4.1/SUN-5.64) id AA01227; Fri, 26 Feb 93 18:05:06 EST Received: from MIT.EDU (MIT.MIT.EDU) by TIS.COM (4.1/SUN-5.64) id AA01221; Fri, 26 Feb 93 18:05:03 EST Received: from toxicwaste.media.mit.edu by MIT.EDU with SMTP id AA01496; Fri, 26 Feb 93 18:04:27 EST Received: by toxicwaste.MEDIA.MIT.EDU (5.61/4.7) id AA00788; Fri, 26 Feb 93 18:04:25 -0500 Message-Id: <9302262304.AA00788@toxicwaste.MEDIA.MIT.EDU> To: Steve Kent Cc: gnu@toad.com, pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of Fri, 26 Feb 93 11:25:57 -0500. <9302261626.AA13573@TIS.COM> Date: Fri, 26 Feb 93 18:04:23 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Derek Atkins X-Orig-Sender: pem-dev-relay@tis.com > Fourth, PGP embodies the "Friends and Family" certification > model, which requires out-of-band arangements and a potentially > complex trust model to assign trust accuracy to name binding (not the > the entities identified by the names) implied by this mesh > certification model. While that may work well for modest numbers of > users, there is considerable belief that it does not scale well for > tens of millions of users on a worldwide basis, nor that it will > support business demands for certification assurance. > > John, you cite the relative success of PGP deployment vs. PEM > as indicative of user preference for a system which requires less of > an infrastructure. That may be true, but I don't believe that the > results are in yet. It is often easier to build and deploy a system > with minimal infrastructure requirements and, perhaps, more modest > goals for scaling, assurance ranges, etc. PEM has more agressive > goals and, as a result, requires more infrastructure. Ultimately time > will tell which strategy proves more successful. (Even that is not a > certain indication of which is "better.") I just want to point something out at this point. The PGP trust model, while based upon a "web of trust" model, does not rule out the ability to impose a rigorous hierarchy on top of it. For example, there is nothing stopping me from converting the ISOC root public key to a PGP-readable certificate, and then, assuming I trust that key, I now have the trust model that PEM imposes. The difference between PEM and PGP, and why I think that PGP is doing so well, is that PEM imposes this structure, and doesn't work without it, which PGP *allows* this structure, but doesn't require it, and works just as well with it as without it! Yes, it is easier to make a system without an infrastructure, but there is nothing that says that the infrastructure MUST exist, and if a system *needs* the infrastructure in order to work, then something is wrong with that system (IMHO). Someone mentioned the need for naming? What's wrong with an e-mail address? For example, how many "warlord@MIT.EDU"'s are there in the world? I understand the need to a non US-centric internet (notice the lower-case 'i'), but when the domain names change, then so will my e-mail address. > Being able to determine the mailbox address for a user with > whom you have nevert exchanged email is a goal of directory services > such as X.500. Why? If I've never spoken to someone, why would I *want* to send them e-mail? Because someone gave me their name? Well, then, I ask them for the e-mail address as well, at the same time. > Think "email address == phone number." I *USE* my e-mail address like my phone number... In fact, I think I give people my e-mail address *MORE* than I give them my phone number. Now, this may be a result of the crowd I'm in, but I don't tend to agree with that. The point of PEM is to provide Privacy Enhanced Mail, not Secure Personal Assurance of Identity, Electronic or Otherwise, isn't it? -derek   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14957; 26 Feb 93 18:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14950; 26 Feb 93 18:17 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa26796; 26 Feb 93 18:17 EST Received: by TIS.COM (4.1/SUN-5.64) id AA01717; Fri, 26 Feb 93 18:18:25 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA01711; Fri, 26 Feb 93 18:18:24 EST Message-Id: <9302262318.AA01711@TIS.COM> To: Brad Huntting Cc: pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of Fri, 26 Feb 93 15:21:43 -0700. <9302262221.AA12412@futureworld.advtech.uswest.com> Date: Fri, 26 Feb 93 18:17:49 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Brad, I believe an Internet arc in QUIPU directories would be present primarily to allow folks to make use of X.500 with DNS names as indices. It does not represent a substantive deviation from the structure described in previous messages. Also, no one should confuse DNs with O/R names, the names used for mailboxes in X.400. These latter names are used for email routing and have a variety of peculiar features not relevant to DNs. As for your comment about multinational corporations, I think you'll find that countries have definitie ideas about what corporate entities are located where, e.g., for tax purposes and for legal jurisdiction. I believe Marshall Rose once provided a rule of thumb for distinguishing between a multinational and an international organization: the latter can raise armies. Ross Perot's exploits not withstanding, I think we would agree that multinational organizations (IBM, Toyota, Siemens, Sony, ...) fail that test, if we rule out armies of sales and marketing folks ;-). Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15092; 26 Feb 93 18:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15085; 26 Feb 93 18:29 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa27159; 26 Feb 93 18:29 EST Received: by TIS.COM (4.1/SUN-5.64) id AA02032; Fri, 26 Feb 93 18:30:02 EST Received: from MIT.EDU (MIT.MIT.EDU) by TIS.COM (4.1/SUN-5.64) id AA02026; Fri, 26 Feb 93 18:30:01 EST Received: from toxicwaste.media.mit.edu by MIT.EDU with SMTP id AA01875; Fri, 26 Feb 93 18:29:19 EST Received: by toxicwaste.MEDIA.MIT.EDU (5.61/4.7) id AA01003; Fri, 26 Feb 93 18:29:17 -0500 Message-Id: <9302262329.AA01003@toxicwaste.MEDIA.MIT.EDU> To: Brad Huntting Cc: gnu@toad.com, "Robert W. Shirey" , pem-dev@tis.com Subject: Re: PGP legality In-Reply-To: Your message of Fri, 26 Feb 93 15:15:28 -0700. <9302262215.AA12382@futureworld.advtech.uswest.com> Date: Fri, 26 Feb 93 18:29:15 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Derek Atkins X-Orig-Sender: pem-dev-relay@tis.com > There's really no reason why PGP couldn't be rewriten to use rsaref > either. Yes, there is. RSAREF, as the License stands, does not allow you the granularity to touch the RSA routines themselves, without prior approval of RSADSI. Given that approval, it MIGHT be possible to use RSAREF. I haven't had the time to explore this possibility, however another thing to note is that PGP currently uses IDEA as its secret-key encryption algorithm, not DES. -derek   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15169; 26 Feb 93 18:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15162; 26 Feb 93 18:43 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa27776; 26 Feb 93 18:43 EST Received: by TIS.COM (4.1/SUN-5.64) id AA02537; Fri, 26 Feb 93 18:44:09 EST Received: from CCV1.BBN.COM by TIS.COM (4.1/SUN-5.64) id AA02531; Fri, 26 Feb 93 18:44:07 EST Message-Id: <9302262344.AA02531@TIS.COM> To: Derek Atkins Cc: pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of Fri, 26 Feb 93 18:04:23 -0500. <9302262304.AA00788@toxicwaste.MEDIA.MIT.EDU> Date: Fri, 26 Feb 93 18:43:33 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kent X-Orig-Sender: pem-dev-relay@tis.com Derek, If you placed the IPRA public key into a PGP database you would NOT have the functionality of the PEM hierarchy. For example, there would be no checking for DN subordination. CRL management would not magically appear, etc. So, while you may argue in favor of the flexibility of the PGP "web of trust," it is not accurate to say that it subsumes the PEM functionality as a special case. This list has endured substantial discussion about why DNs are used, so I don't believe reprating this explanation again is useful. The goals of PEM were established long ago. Security services are closely related to naming issues, in email, general network security and computer security. Quite a bit of literature addressing various aspects of this relationship has been publsihed over the last 15-20 years. Perhaps your model of what services PEM should provide differs from those which are identified in RFC 1421 and which have lead the development of the RFCs for several years. Finally, I suspect, from the tone of your message, that you may be a new subscriber to this list. You may wish to avail yourself of the archives maintained at TIS to review the progress of discussions of many topics which are now being raised again. It seems that some number of subscribers have become active as a result of the publication of the RFCs. Note that these RFCs are completed and the current focus of the PEM WG, for which this is the discussion list, is the integration of PEM and MIME. That will be the topic of the next WG meeting, in Columbus OH, at the end of March. I urge WG members to read the current I-D proposal for PEM-MIME integration in preparation for the meeting. Discussion of unresolved issues about DN guidelines and other loose ends with regard to the RFCs are still are appropriate topics for this list. However, discussion of the form "why do we have to use DNs with PEM" or "how is PGP different/better than PEM" or "why I think the RIPEM user community will overtake PGP in 6 months" does not seem appropriate at this stage in the process. Steve Kent PEM WG Chair   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15224; 26 Feb 93 18:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15217; 26 Feb 93 18:53 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa28007; 26 Feb 93 18:53 EST Received: by TIS.COM (4.1/SUN-5.64) id AA03197; Fri, 26 Feb 93 18:54:17 EST Received: from inet-gw-1.pa.dec.com by TIS.COM (4.1/SUN-5.64) id AA03191; Fri, 26 Feb 93 18:54:16 EST Received: by inet-gw-1.pa.dec.com; id AA07013; Fri, 26 Feb 93 15:53:38 -0800 Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA15349 for pem-dev@tis.com; Fri, 26 Feb 93 18:54:48 -0500 Message-Id: <9302262354.AA15349@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: pem-dev@tis.com Cc: Beast (Donald E. Eastlake,III) Subject: X.400 bounce example Date: Fri, 26 Feb 93 18:54:48 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp X-Orig-Sender: pem-dev-relay@tis.com Amazing. Not very many minutes after sending out my message complaining about X.400 bounces, I get one, probably due to an entry on the pem-dev list! Donald *+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+- Donald E. Eastlake, III 1-508-486-2358(w) dee@skidrow.ljo.dec.com PO Box N, MIT Branch PO dee@ranger.enet.dec.com Cambridge, MA 02139 USA 1-617-244-2679(h) ------- Forwarded Message Return-Path: uucp@attmail.com Received: by skidrow.ljo.dec.com (5.57/fma-100391/rcb-930105) id AA15115 for /usr/new/lib/mh/slocal; Fri, 26 Feb 93 17:55:00 -0500 Received: by inet-gw-1.pa.dec.com; id AA03450; Fri, 26 Feb 93 14:53:32 -0800 Message-Id: <9302262253.AA03450@inet-gw-1.pa.dec.com> From: uucp@attmail.com Date: 26 Feb 93 22:38:27 GMT To: dee@skidrow.ljo.dec.com Report-Version: 2 Received: by /C=US/AD=ATTMAIL;Fri Feb 26 22:38:29 -0000 1993 Received: by /C=US/AD=ATTMAIL/PD=UNISYS;Fri Feb 26 16:38:27 -0600 1993 Confirming-Mts-Message-Id: Not-Delivered-To: mhs!unisys/G=stephen/I=j/S=semen/O=comm/OU=corphq due to 10 Invalid Parameters Content-Type: text ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15825; 26 Feb 93 20:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15818; 26 Feb 93 20:44 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa00213; 26 Feb 93 20:44 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06198; Fri, 26 Feb 93 20:45:03 EST Received: from MIT.EDU (MIT.MIT.EDU) by TIS.COM (4.1/SUN-5.64) id AA06179; Fri, 26 Feb 93 20:45:02 EST Received: from TMS-E40-PORT-7.MIT.EDU by MIT.EDU with SMTP id AA03220; Fri, 26 Feb 93 20:44:19 EST Message-Id: <9302270144.AA03220@MIT.EDU> Date: Fri, 26 Feb 93 20:44:21 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Raymond Lau To: Derek Atkins Subject: Re: Naming problem as a symptom Cc: pem-dev@tis.com X-Orig-Sender: pem-dev-relay@tis.com > The difference between PEM and PGP, and why I think that PGP is doing > so well, is that PEM imposes this structure, and doesn't work without > it, which PGP *allows* this structure, but doesn't require it, and > works just as well with it as without it! The only structure that PEM imposes is one of strict trust rather than partial trust which is summed up if many people sign a key, etc. It is possible to not join the Internet certification hierarchy and have multiple trees. > Why? If I've never spoken to someone, why would I *want* to send them > e-mail? Because someone gave me their name? Well, then, I ask them > for the e-mail address as well, at the same time. Suppose someone says "Person X at company Y is responsible for this -- you may want to contact her." -Ray   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04898; 27 Feb 93 16:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04891; 27 Feb 93 16:03 EST Received: from [192.33.112.100] by CNRI.Reston.VA.US id aa10586; 27 Feb 93 16:03 EST Received: by TIS.COM (4.1/SUN-5.64) id AA04517; Sat, 27 Feb 93 16:01:50 EST Received: from relay2.UU.NET by TIS.COM (4.1/SUN-5.64) id AA04488; Sat, 27 Feb 93 16:01:46 EST Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA26719; Sat, 27 Feb 93 16:01:16 -0500 Received: from localhost by toad.com id AA28199; Sat, 27 Feb 93 13:02:16 PST Message-Id: <9302272102.AA28199@toad.com> To: pem-dev@tis.com, gnu@toad.com Subject: Re: Naming problem as a symptom In-Reply-To: <9302270144.AA03220@MIT.EDU> Date: Sat, 27 Feb 93 13:02:12 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gnu@toad.com X-Orig-Sender: pem-dev-relay@tis.com > > If I've never spoken to someone, why would I *want* to send them > > e-mail? Because someone gave me their name? Well, then, I ask them > > for the e-mail address as well, at the same time. > Suppose someone says "Person X at company Y is responsible for this -- you > may want to contact her." It's already impossible to "finger" people at large companies to discern their email addresses; and phone directories of most large companies are not available. Some are concerned with having their employees recruited by other companies; others want to impose a particular chain-of-command on interactions with the outside world. (Then there's the NSA, which won't even transfer you to a person even if you know their name.) Why would such companies or organizations make a publicly readable X.500 database available that lists every employee's name, email address, and public key? John Gilmore   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04967; 27 Feb 93 17:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04960; 27 Feb 93 17:15 EST Received: from [192.33.112.100] by CNRI.Reston.VA.US id aa11380; 27 Feb 93 17:15 EST Received: by TIS.COM (4.1/SUN-5.64) id AA06340; Sat, 27 Feb 93 17:13:53 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by TIS.COM (4.1/SUN-5.64) id AA06334; Sat, 27 Feb 93 17:13:50 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA22054; Sat, 27 Feb 93 14:11:40 -0800 To: gnu@toad.com Reply-To: pem-dev@tis.com Cc: pem-dev@tis.com Subject: Re: Naming problem as a symptom In-Reply-To: Your message of "Sat, 27 Feb 1993 13:02:12 PST." <9302272102.AA28199@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Feb 1993 14:11:38 -0800 Message-Id: <22053.730851098@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose X-Orig-Sender: pem-dev-relay@tis.com If there are well-reasoned questions regarding the use of DNs and certificates with respect to PEM, that discussion on those topics should remain on this list. Otherwise, in the interests of world peace, please direct further discussion on X.500 concepts, such as DNs, to one of: mhs-ds@mercury.udev.cdc.com - X.400/X.500 issues ietf-osi-ds@cs.ucl.ac.uk - X.500 issues iso@nic.ddn.mil - OSI issues If, in fact, you address your generic X.500 question to either of the two last lists, I will be happy to answer it there. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05275; 27 Feb 93 18:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05268; 27 Feb 93 18:51 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa12759; 27 Feb 93 18:51 EST Received: by TIS.COM (4.1/SUN-5.64) id AA09055; Sat, 27 Feb 93 18:51:38 EST Received: from mwunix.mitre.org by TIS.COM (4.1/SUN-5.64) id AA09049; Sat, 27 Feb 93 18:51:37 EST Received: from mwvm.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA24792; Sat, 27 Feb 1993 18:51:04 -0500 Received: from mwunix.mitre.org by mwvm.mitre.org (IBM VM SMTP V2R1) with TCP; Sat, 27 Feb 93 18:51:05 EST Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA24788; Sat, 27 Feb 1993 18:51:02 -0500 Message-Id: <199302272351.AA24788@mwunix.mitre.org> Date: Sat, 27 Feb 93 18:49:33 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: PostMast@mwmgate1.mitre.org To: "PEM-DEV at TIS.COM@MWUNIX" Subject: Undeliverable mail X-Orig-Sender: pem-dev-relay@tis.com Gateway MWMGATE1 could not deliver your mail to cc:Mail user w035_nw because of the error(s) cited below. Your undelivered message follows: - - - - - - - - - - - - - - - - - - - - - - - *** Unknown message recipient *** Subject: Re: Naming problem as a symptom Date: 27-FEB-1993 18:46:16 -------------- The following note was forwarded to you by AWAY... ------------- Received: from mwunix.mitre.org by mwvm.mitre.org (IBM VM SMTP V2R1) with TCP; Sat, 27 Feb 93 18:38:06 EST Return-Path: Received: from TIS.COM by mwunix.mitre.org (5.65c/SMI-2.2) id AA24601; Sat, 27 Feb 1993 18:38:03 -0500 Received: by TIS.COM (4.1/SUN-5.64) id AA06340; Sat, 27 Feb 93 17:13:53 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by TIS.COM (4.1/SUN-5.64) id AA06334; Sat, 27 Feb 93 17:13:50 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA22054; Sat, 27 Feb 93 14:11:40 -0800 To: gnu@toad.com Reply-To: pem-dev@TIS.COM Cc: pem-dev@TIS.COM Subject: Re: Naming problem as a symptom In-Reply-To: Your message of "Sat, 27 Feb 1993 13:02:12 PST." <9302272102.AA28199@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Feb 1993 14:11:38 -0800 Message-Id: <22053.730851098@dbc.mtview.ca.us> From: Marshall Rose Sender: pem-dev-relay@TIS.COM If there are well-reasoned questions regarding the use of DNs and certificates with respect to PEM, that discussion on those topics should remain on this list. Otherwise, in the interests of world peace, please direct further discussion on X.500 concepts, such as DNs, to one of: mhs-ds@mercury.udev.cdc.com - X.400/X.500 issues ietf-osi-ds@cs.ucl.ac.uk - X.500 issues iso@nic.ddn.mil - OSI issues If, in fact, you address your generic X.500 question to either of the two last lists, I will be happy to answer it there. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08292; 28 Feb 93 15:31 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08285; 28 Feb 93 15:31 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa04563; 28 Feb 93 15:31 EST Received: by TIS.COM (4.1/SUN-5.64) id AA08355; Sun, 28 Feb 93 15:31:43 EST Received: from intercon.com by TIS.COM (4.1/SUN-5.64) id AA08349; Sun, 28 Feb 93 15:31:41 EST Received: from amanda.dial.intercon.com by intercon.com via SMTP (911016.SGI/920928.RS) for pem-dev@tis.com id AA15363; Sun, 28 Feb 93 15:31:05 -0500 X-Mailer: InterCon TCP/Connect II 1.1 Message-Id: <9302281530.AA51040@amanda.dial.intercon.com> Date: Sun, 28 Feb 1993 15:30:51 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Amanda Walker To: pem-dev@tis.com Subject: Re: Naming problem as a symptom X-Orig-Sender: pem-dev-relay@tis.com warlord@MIT.EDU (Derek Atkins) writes: > The point of PEM is to provide Privacy Enhanced Mail, not Secure > Personal Assurance of Identity, Electronic or Otherwise, isn't it? The point is to provide both, since without the latter, the former degrades into "Shh... Don't Tell Anyone" Mail.