Improved Secure Communication for Registration Services (RS) Mailboxes
All, The RIPE NCC is nearing completion of the database phase of the "Improved Secure Communications for RIPE NCC Members" project. The next phase will focus on e-mail communication between RIPE NCC members and the Registration Services Department. The attached document presents our ideas regarding this, and also raises some questions for the membership. Please have a look, and comment. There will also be a presentation and discussion at the NCC Services Working Group next week at RIPE 47, for those interested in voicing their opinions in person. -- Shane Kerr Software Engineering Department Manager RIPE NCC Filiz Yilmaz Bican Senior Hostmaster RIPE NCC Improved Secure Communication for Registration Services (RS) Mailboxes 0. Overview ----------- This is a discussion document with the aim of obtaining members point's of view on the usage of PKI for RS mailboxes. It may result in a proposal document after such feedback is gathered. There is a need for secure communication between the RIPE NCC and its members due to the following: - discussions should be avoided with unauthorised persons representing the member organisation. - members should be able to ensure that they are communicating with the RIPE NCC. - communication with the RIPE NCC contains confidential information for the members. Accordingly, it was decided that the RIPE NCC would work on the implementation of a secure system. More information can be found at: RIPE NCC Activities, Expenditures, and Charging Scheme 2003 http://www.ripe.net/ripe/docs/ap2003.html Therefore the RIPE NCC is currently working on a "Secure Communications" project that can be found at: Draft: Improved Secure Communication System for RIPE NCC Members http://www.ripe.net/ripe/draft-documents/archive/pki-20030429.html The secure communications project has several phases as areas of communication with the RIPE NCC to implement security. Securing the communication with the RIPE NCC Registration Services (RS) is the third phase of the project. (A full description of the phases can be found at the above URL.) 1. Introduction --------------- Secure communication between a member and the RIPE NCC requires authentication, non-repudiation and data confidentiality. Most of the interaction between a member contact and a RIPE NCC Hostmaster is via e-mail. Currently, the RIPE NCC authenticates a received mail based on the "Full Name" of the member contact. This is either found in the mail headers or in the body of the mail. This is a very weak form of authentication and can sometimes result in repudiation (not accepting the sender as an authorised contact). Currently, authentication and non-repudiation requirements are only supported from the RIPE NCC by signing all outgoing mail sent to a member contact with the RIPE NCC's PGP key. It is not possible to authenticate a member through a digital signature or to send information in encrypted format. The system discussed below will meet the "authentication" and "non-repudiation" requirements for the communication between RS and member contacts (if desired). However, this is not a solution to the requirement "data confidentiality". This requirement and a possible solution to it are discussed in Section 3. 2. Discussion: Integration of X.509 PKI technology for RS Mailboxes ------------------------------------------------------------------- In order to secure the communication for "authentication" and "non-repudiation" between a member contact and a RIPE NCC Hostmaster X.509 Public Key Infrastructure will be used. The member-only mailboxes for this kind of communication are: - <hostmaster@ripe.net> (Internet Resource Requests mailbox) - <lir-help@ripe.net> (Help mailbox) The level of security can be chosen by the member contact, the options are the following: Mails from Member Contact to RIPE NCC (Incoming mails to RS mailboxes): ----------------------------------------------------------- I1. Nothing (This corresponds to the current system). I2. X.509 PKI Signed mail from the member contact is required. Mails from RIPE NCC to Member Contact (Outgoing mails from RS Mailboxes): ------------------------------------------------------------- O1. PGP Key (mail sent PGP signed with the RIPE NCC's PGP Key which is the current system). O2. X.509 PKI Signed mail from the RIPE NCC is required. The system will work in the following manner: 2.1 Initialisation of the system on the member side --------------------------------------------------- 1. The member (registry) should have an LIR Portal "admin" account. For registries without an "admin" account, the following link can be used to activate one: https://lirportal.ripe.net/lirportal/activation/activation_request.html 2. Within the "admin" account, "Administrative Preferences" (corresponding to I1 or I2 and O1 or O2 described above) should be configured. These "Administrative Preferences" will describe the preferences of the organisation so they can override the "User Preferences" (described in point 4 below) if preferred. 3. Through the "admin" account users should be created for staff members needing to contact the RIPE NCC Hostmasters. 4. Users should configure their "User Preferences" (corresponding to I1 or I2 and O1 or O2 described above) through their LIR Portal accounts. The user will only be given the list of options that match the "Administrative Preferences" set by the "admin". 5. If the user chooses O2 they should install the RIPE NCC's CA Root Certificate[1]. 2.2 Communication Flow ---------------------- 2.2.1 Incoming Mails to RIPE NCC RS Mailboxes --------------------------------------------- 1. The sender's e-mail address on the mail headers (From) will be checked against the "User Preferences" stored in the LIR Portal for the user. 2. If the "User Preferences" require I2 (X.509 PKI Signed mail from the member contact) 2.1 AND the signature is valid, the RIPE NCC RS Robot will accept the mail. 2.2 AND the signature is NOT valid OR the mail is not signed at all, the mail will be bounced back to the sender. Help information will be provided in the bounce message (see Section 2.3 HELP). 3. If the "User Preferences" require I1 (Nothing), the RIPE NCC RS Robot will process the mail (this is identical to the current situation). 4. If there is no user in the LIR Portal corresponding to the sender's e-mail address 4.1 AND the "Admin Preferences" is set to I1 (Nothing), the RIPE NCC RS Robot will process the mail (this is identical to the current situation). 4.2 AND the "Admin Preferences" is set to I2 (X.509 PKI Signed mail from the member contact), the mail will be bounced back to the sender. Help information will be provided in the bounce message (see Section 2.3 HELP). 2.2.2 Outgoing Mails from RIPE NCC RS Mailboxes ----------------------------------------------- 1. The recipient's e-mail address on the mail headers (To) will be checked against the "User Preferences" stored in the LIR Portal for the user. 2. If the "User Preferences" require O2 (X.509 PKI Signed mail from the RIPE NCC) the mail will be signed with the RIPE NCC's certificate (On the user's end, this signature can be validated through the installed CA Root Certificate of the RIPE NCC). 3. If the "User Preferences" requires O1 (PGP Key), the mail will be signed with the RIPE NCC's PGP key (this is identical to the current situation). 4. If there is no user in the LIR Portal corresponding to the recipient's e-mail address 4.1 AND the "Admin Preferences" is set to O1 (PGP Key), the mail will be signed with the RIPE NCC's PGP key (this is identical to the current situation). 4.2 AND the "Admin Preferences" is set to O2 (X.509 PKI Signed mail from the RIPE NCC), the mail will be signed with the RIPE NCC's certificate (On the user's end, this signature can be validated through the installed CA Root Certificate of the RIPE NCC). 5. If there are multiple recipients (multiple addresses in To and/or Cc), the mail will be sent containing multiple MIME parts. Each of these MIME parts will contain specific security according to each recipient's case as described above. In summary, there will be flexible options for those members willing to deploy more security in their communication with the RIPE NCC RS. There will be no implications to members who are not willing to deploy such a security system. There will also be no implications to members who do not have an LIR Portal "admin" account activated. 2.3 HELP -------- In case a mail is bounced back due to the failure in verification of the signature, the mail will contain instructions explaining possible reasons for the problem and pointers on how to solve it. It will also provide an e-mail address to contact about the problem. 3. Future Developments/Phases ----------------------------- The system discussed above is open to changes in accordance to member feedback. One of the possible future developments could be the integration of this system to other RIPE NCC RS mailboxes, e.g. <inaddr@ripe.net>, <reg-review@ripe.net> etc. As mentioned earlier, the system discussed above is only a solution to the "authentication" and "non-repudiation" requirements. It is not a solution to the "data confidentiality" requirement. Data confidentiality can only be met once the communication is in an encrypted format. This can be achieved with the usage of X.509 PKI technology. Once this is implemented other security options for "Admin Preferences" and/or "User Preferences" can be added as follows: Mails from Member Contact to RIPE NCC (Incoming mails to RS Mailboxes): ----------------------------------------------------------- X.509 PKI encrypted mail from the member contact is required X.509 PKI signed and encrypted mail from the member contact is required. Mails from RIPE NCC to Member Contact (Outgoing mails from RS Mailboxes): ------------------------------------------------------------- X.509 PKI encrypted mail from the RIPE NCC is required The encryption process requires a more detailed set of definitions and rules to be clarified before any technical implementation can take place. For such a set of definitions and rules to be outlined, the RIPE NCC needs input from the members. Some pointer questions regarding encryption are listed below that require feedback from the community: - Do members' security concerns in communication with the RIPE NCC require this type of security? - Should all mails to the RIPE NCC RS mailboxes be encrypted? - Should all mails from the RIPE NCC RS mailboxes be encrypted? - Should there be different levels of security for different mailboxes? - Should there be different levels of security for incoming and outgoing mails to/from the RIPE NCC RS mailboxes? - Should there be different levels of security depending on the content of the messages. (For example to indicate sensitive content, every ticket initiated with an encrypted message should carry on as encrypted.) - If all the keys expired for a registry which "prefers" an encrypted communication and the RIPE NCC needed to contact the registry, how should this communication be initialised by the RIPE NCC? - How should the encryption be done when there are multiple recipients, or where "User Preferences" do not match? - How should the encryption be done when there are different registries involved in communication in specific cases, for example mergers and takeovers? - How/what should be the back-up system if the encrypted format cannot be processed by the member contact or by the RIPE NCC for some reason? Please provide your feedback to the following: - <pki-suggestions@ripe.net> or - <ncc-services-wg@ripe.net> Feedback can also be given during the RIPE NCC Services Working Group at RIPE 47, 26-30 January 2004, Amsterdam. [1] CA Root Certificate: Certification Authority Certificate. The RIPE NCC will be the Certification Authority (CA) in this system.
Hi!
The attached document presents our ideas regarding this, and also raises some questions for the membership. Please have a look, and comment. There will also be a presentation and discussion at the NCC Services Working Group next week at RIPE 47, for those interested in voicing their opinions in person. [...] http://www.ripe.net/ripe/draft-documents/archive/pki-20030429.html
I object on making x.509 the sole method of authenticated communication with RIPE. There's GPG, and it works, now. X.509 is not the way to go. It's just a (needless) duplication of effort. And wading forever in the mess of "do we use this protocol/format or that" and so on. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372
--On Monday, February 23, 2004 20:58:42 +0100 Kurt Jaeger <lists@complx.LF.net> wrote:
I object on making x.509 the sole method of authenticated communication with RIPE.
There's GPG, and it works, now.
X.509 is not the way to go. It's just a (needless) duplication of effort. And wading forever in the mess of "do we use this protocol/format or that" and so on.
I would have to concur with this objection. PGP/GPG works, it is well suited to workflow, requires few special tools (bar pgp software) on the client side, and is an established method. Forcing certificate handling onto the LIR community is NOT good service, it is IMNSHO overcomplication. PKIen have their uses, but this is not one. I say NO to X.509. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
--On Monday, February 23, 2004 20:58:42 +0100 Kurt Jaeger <lists@complx.LF.net> wrote:
I object on making x.509 the sole method of authenticated communication with RIPE.
There's GPG, and it works, now.
X.509 is not the way to go. It's just a (needless) duplication of effort. And wading forever in the mess of "do we use this protocol/format or that" and so on.
I would have to concur with this objection. PGP/GPG works, it is well suited to workflow, requires few special tools (bar pgp software) on the client side, and is an established method.
Forcing certificate handling onto the LIR community is NOT good service, it is IMNSHO overcomplication. PKIen have their uses, but this is not one.
I say NO to X.509.
I completely disagree. You can say no all you like but frankly for many organisations PGP/GPG is simply not an option because there are a number of issues related to management of keys and users. I suspect an audit of many organisations using PGP/GPG would find alarming issues with the way these are deployed and used. X.509 maybe somewhat overcomplicated [and I don't agree with that fully anyway] for this specific application but if you already have a platform and many organisations do, then its a trivial expansion. Rolling out GPG/PGP across large organisations is just as much of an issue as deploying a PKI system. Whether you like or not X.509 is here and its likely to be here to stay and it works pretty well in my experience. So I welcome the RIPE NCC's direction on this. Regards, Neil.
X.509 is not the way to go. It's just a (needless) duplication of effort. And wading forever in the mess of "do we use this protocol/format or that" and so on.
I would have to concur with this objection. PGP/GPG works, it is well suited to workflow, requires few special tools (bar pgp software) on the client side, and is an established method.
Forcing certificate handling onto the LIR community is NOT good service, it is IMNSHO overcomplication. PKIen have their uses, but this is not one.
I say NO to X.509.
i would ammend slightly. the rirs provide us service. some of us find pgp easier to deploy and use. some will provide x.509 easier. so the rirs accepting *both* would be good. randy, a pgp kinda guy who also uses x.509 occasionally
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, On 2004-02-25, at 10.01, Randy Bush wrote:
X.509 is not the way to go. It's just a (needless) duplication of effort. And wading forever in the mess of "do we use this protocol/format or that" and so on.
I would have to concur with this objection. PGP/GPG works, it is well suited to workflow, requires few special tools (bar pgp software) on the client side, and is an established method.
Forcing certificate handling onto the LIR community is NOT good service, it is IMNSHO overcomplication. PKIen have their uses, but this is not one.
I say NO to X.509.
i would ammend slightly. the rirs provide us service. some of us find pgp easier to deploy and use. some will provide x.509 easier. so the rirs accepting *both* would be good.
randy, a pgp kinda guy who also uses x.509 occasionally
I am kind of puzzled here. The X.509 scheme was proposed there way before two RIPE meetings ago, when the NCC Services WG was new. I was also then voicing criticism, as was a few others. Not much discussion was raised though. Shawn then made a good presentation at the NCC Services WG meeting two RIPE meetings ago. We also had Dirk-Wilhelm van Gulik come in and explain X.509 and certificates in general. After the presentation, from what I remember most people thought this was a good idea, and a good add-on. So the NCC proceeded. So, I am bit surprised that people are start having views -now-. But I must agree with Randy, I have a hard time seeing what the problem is catering for multiple needs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDx0CqarNKXTPFCVEQJP9wCg/Fry0R1u6CcjJKVhBJd7hZUCb60AoMOj 2FyShsugqEROrYTrg8ZFsBSN =jzi+ -----END PGP SIGNATURE-----
Hi!
X.509 is not the way to go. [...]
find pgp easier to deploy and use. some will provide x.509 easier. so the rirs accepting *both* would be good.
randy, a pgp kinda guy who also uses x.509 occasionally
I am kind of puzzled here. [...] So, I am bit surprised that people are start having views -now-.
Sorry for this. It's just that there are so many discussions to have in parallel that it's difficult to follow up in time to some of them. I already raised my voice the last time x.509 came up, that's why I raised it again. We're only a small LIR, and we already see the burden of having to many "standards" to chose from. As of know, RIPE was steering the course with a clean (sub-)set, and it was OK for us. We do not have the time to attend RIPE meetings more than once every few years, if at all. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-25, at 13.34, Kurt Jaeger wrote:
Hi!
X.509 is not the way to go. [...]
find pgp easier to deploy and use. some will provide x.509 easier. so the rirs accepting *both* would be good.
randy, a pgp kinda guy who also uses x.509 occasionally
I am kind of puzzled here. [...] So, I am bit surprised that people are start having views -now-.
Sorry for this. It's just that there are so many discussions to have in parallel that it's difficult to follow up in time to some of them. I already raised my voice the last time x.509 came up, that's why I raised it again.
We're only a small LIR, and we already see the burden of having to many "standards" to chose from. As of know, RIPE was steering the course with a clean (sub-)set, and it was OK for us.
I am not really following you here. What is the problem for you with the option of either using PGP or X.509? Some of the LIRs want X.509, some PGP. Isn't it good that the NCC tried to cater for both needs? As Shawn pointed out, the proposal is not to remove the PGP option.
We do not have the time to attend RIPE meetings more than once every few years, if at all.
this is why we have this WG and why this WG have a mailinglist. That is why this WG publishes minutes of the meetings that take place in person. I understand that a big issue with the RIRs (not only RIPE NCC) is that a minority of the members decide the policy for the majority. Problem is that I don't see a way around this. The "we all have day jobs" argument doesn't really apply. Life must still go on as well. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQD2WNqarNKXTPFCVEQJfvQCfZ1nRQVhU6yhaGbcb3HCsOqOXfUsAoObu eGFtj6u+8aH0dnY0SsZukoiq =paO/ -----END PGP SIGNATURE-----
Hi!
We're only a small LIR, and we already see the burden of having to many "standards" to chose from. As of know, RIPE was steering the course with a clean (sub-)set, and it was OK for us.
I am not really following you here. What is the problem for you with the option of either using PGP or X.509?
From what I understand, some RIPE things can already only be done using lir-portal. Is that correct ?
So, for the foreseeable future, we have to train the staff using the right tool for the right matter, which is just additional workload.
Some of the LIRs want X.509, some PGP. Isn't it good that the NCC tried to cater for both needs? As Shawn pointed out, the proposal is not to remove the PGP option.
I've seen too many such "Oh, we cover both" schemes in the past to know where it's heading, shortterm gain, longterm pain 8-}
We do not have the time to attend RIPE meetings more than once every few years, if at all.
this is why we have this WG and why this WG have a mailinglist. That is why this WG publishes minutes of the meetings that take place in person.
Yes, and as I already mentioned, I questioned the x.509 way when the last paper was published. Our LIR was just not also present to question it at the meeting, as well. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We're only a small LIR, and we already see the burden of having to many "standards" to chose from. As of know, RIPE was steering the course with a clean (sub-)set, and it was OK for us.
I am not really following you here. What is the problem for you with the option of either using PGP or X.509?
From what I understand, some RIPE things can already only be done using lir-portal. Is that correct ?
Yes....but for all I know, all that can be done with PGP and email to hostmaster@ripe.net or equivalent mail address as well.
So, for the foreseeable future, we have to train the staff using the right tool for the right matter, which is just additional workload.
Well, you will have to train them to use ANY tool. Be it email+PGP or LIR-portal+X.509...
Some of the LIRs want X.509, some PGP. Isn't it good that the NCC tried to cater for both needs? As Shawn pointed out, the proposal is not to remove the PGP option.
I've seen too many such "Oh, we cover both" schemes in the past to know where it's heading, shortterm gain, longterm pain 8-}
I would be really interested in examples here... I will admit that I have concerns about the X.509 stuff, like the authorization chain to the mirrors (that I did a poor job of explaining in Amsterdam). but I am not sure there is that much issue with using both systems. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQD4H7KarNKXTPFCVEQLKCgCeMWrmQaopyJacVnFQEsTdjthz/aAAmgK6 JUAuPU+SBgD6e2ggsJMFMSv4 =Uzze -----END PGP SIGNATURE-----
I am kind of puzzled here.
The X.509 scheme was proposed there way before two RIPE meetings ago, when the NCC Services WG was new. I was also then voicing criticism, as was a few others. Not much discussion was raised though. Shawn then made a good presentation at the NCC Services WG meeting two RIPE meetings ago. We also had Dirk-Wilhelm van Gulik come in and explain X.509 and certificates in general. After the presentation, from what I remember most people thought this was a good idea, and a good add-on. So the NCC proceeded.
So, I am bit surprised that people are start having views -now-.
Some of us were not at the RIPE meeting two RIPE meetings ago, so if this was the only venue where the "design discussion" was held and where justification for the intended choices were presented, it's perhaps no surprise that some of us react when a baked proposal arrives with no further background information. BTW, I'm not certain if this is really something to make a big fuzz about... Regards, - Håvard
On Wed, 25 Feb 2004, Randy Bush wrote: [snip] RB> > I say NO to X.509. RB> RB> i would ammend slightly. the rirs provide us service. some of us RB> find pgp easier to deploy and use. some will provide x.509 easier. RB> so the rirs accepting *both* would be good. RB> RB> randy, a pgp kinda guy who also uses x.509 occasionally I could not agree more! ;-) /me, biased the same ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Hi, I'll have to agree with Måns; forcing X.509 handling and software as the only option for securing e-mail with the registration services mailboxes onto the LIR community is not something I see as particularly welcome. Today the LIRs have the option of securing communication with auto-dbm using PGP. This means that there is some deployment in the LIR community for using PGP already. Thus, I'm puzzled why the option of continuing to use PGP with the registration services mailboxes (hostmaster@ripe.net etc.) is not on the table as options. Yes, I can see there would be problems, but I have not seen any discussion which makes it clear why these problems are insurmountable (and I doubt they are). I'll admit that I'm not familiar with usage of S/MIME in e-mail, so I don't know how invasive usage of that is going to be. However, it seems clear to me that if introduction of S/MIME and X.509 will impose restrictions on what e-mail clients can be used, one is intruding on an area where there may be emotional reactions, and the proposal as it stands does not really address those issues. I'll concede, though, that on the WEB, it would seem that X.509 usage in the form of https is the only viable option, but then again, that's not what we're discussing here, right? Regards, - Håvard
I'll admit that I'm not familiar with usage of S/MIME in e-mail, so I don't know how invasive usage of that is going to be. However, it seems clear to me that if introduction of S/MIME and X.509 will impose restrictions on what e-mail clients can be used, one is intruding on an area where there may be emotional reactions, and the proposal as it stands does not really address those issues.
How useful that emotions are used to define what the best solution might be rather than carefully thought out analysis of what the best option rather is :-) You don't add any weight to the argument with this point.
I'll concede, though, that on the WEB, it would seem that X.509 usage in the form of https is the only viable option, but then again, that's not what we're discussing here, right?
No but it highlights one of the reasons why X.509 might be the better choice. Neil.
No but it highlights one of the reasons why X.509 might be the better choice.
to repeat myself, why is there a choice at all? why one xor the other, as opposed to one or the other?
HI!
No but it highlights one of the reasons why X.509 might be the better choice.
to repeat myself, why is there a choice at all? why one xor the other, as opposed to one or the other?
Because in the long run, providing both ways will cost more than consolidating into one. So, sometime in the future, we will be asked: Does someone still use the GPG way ? Aha, only a minority. So: We will close that down, to save costs. Frankly, if the cost in implementing the x.509 way had been invested in the GPG way, we would have exactly one and better solution than having now to run/use both. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372
to repeat myself, why is there a choice at all? why one xor the other, as opposed to one or the other? Because in the long run, providing both ways will cost more than consolidating into one.
thank you henry ford ("you can have any color you want, as long as it is black") :-). it will cost the ncc a bit more. not doing both will cost many of us a bit more. who is the customer and what are we optimizing? randy
thank you henry ford ("you can have any color you want, as long as it is black") :-).
it will cost the ncc a bit more. not doing both will cost many of us a bit more. who is the customer and what are we optimizing?
how very mutual of you Randy :-) Neil.
to repeat myself, why is there a choice at all? why one xor the other, as opposed to one or the other?
Agreed, both could be supported easily.
Randy Bush wrote:
No but it highlights one of the reasons why X.509 might be the better choice.
to repeat myself, why is there a choice at all? why one xor the other, as opposed to one or the other?
Based on the general discussion here, the RIPE NCC will undertake to implement support for PGP and S/MIME in Hostmaster to LIR e-mail communications. Thank you all for the feedback! -- Shane
Based on the general discussion here, the RIPE NCC will undertake to implement support for PGP and S/MIME in Hostmaster to LIR e-mail communications.
thank you, sir randy
On Mon, 1 Mar 2004, Shane Kerr wrote: SK> Based on the general discussion here, the RIPE NCC will undertake to SK> implement support for PGP and S/MIME in Hostmaster to LIR e-mail SK> communications. Thanks a lot! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the record: The RIPE NCC has no plans to stop supporting existing use of PGP. Havard Eidnes wrote: | | I'll have to agree with Måns; forcing X.509 handling and software | as the only option for securing e-mail with the registration | services mailboxes onto the LIR community is not something I see | as particularly welcome. | | Today the LIRs have the option of securing communication with | auto-dbm using PGP. This means that there is some deployment in | the LIR community for using PGP already. Thus, I'm puzzled why | the option of continuing to use PGP with the registration | services mailboxes (hostmaster@ripe.net etc.) is not on the table | as options. Yes, I can see there would be problems, but I have | not seen any discussion which makes it clear why these problems | are insurmountable (and I doubt they are). The basic reasons to choose X.509 for e-mail are: 1. We don't have to develop key management tools. Such technology isn't rocket science - a public key upload form on the LIR Portal for instance - but security is hard to get right, and people who are experts in it have done the hard work for us if we use X.509. 2. Having the same authentication for all communication would be nice. This is not (easily) possible with PGP. You'd need a password for the LIR Portal and a PGP key for e-mail communication. | I'll admit that I'm not familiar with usage of S/MIME in e-mail, | so I don't know how invasive usage of that is going to be. | However, it seems clear to me that if introduction of S/MIME and | X.509 will impose restrictions on what e-mail clients can be | used, one is intruding on an area where there may be emotional | reactions, and the proposal as it stands does not really address | those issues. Any technology for securing e-mail restricts client choice. Among the e-mail clients that members use, there is superior "out of the box" support for X.509 than PGP. I say this based on the research that we did in response to concerns about S/MIME compatibility. As others have noted, we can support both X.509 and PGP. We can also support *only* PGP, although I think because of #2, above, this is not a good solution. Although the basic question of "do we need this at all" still seems open to me. In some ways, security is like insurance: it is only a problem if you don't have it after you should have. Ignoring the "PGP versus X.509" question, does the membership want us to support signed e-mail at all? What about encrypted e-mail? - -- Shane Kerr RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAPNVHAO5deE6kXkcRAn74AKCZ3RM/r1Qw+6/lwK7vnNVVgnlNTACdEox/ OlOQcmhwJD1Zqql0aJ5gtdU= =wWNp -----END PGP SIGNATURE-----
--On Wednesday, February 25, 2004 18:03:04 +0100 Shane Kerr <shane@ripe.net> wrote:
Any technology for securing e-mail restricts client choice. Among the e-mail clients that members use, there is superior "out of the box" support for X.509 than PGP. I say this based on the research that we did in response to concerns about S/MIME compatibility.
Please elaborate, because I have a hard time to find an email client not supporting an ASCII-armored PGP message, but there are tons of them frowning on x.509 attachments. Some of us actually do the equivalent of: $EDITOR ripe-template.txt gpg --clearsign ripe-template.txt | /bin/mail <somebody@ripe.net> for our RIPE communications.
As others have noted, we can support both X.509 and PGP. We can also support *only* PGP, although I think because of #2, above, this is not a good solution.
I would argue that it is the other way around; given the forced choice of "only one" the broadest support exists for PGP.
Although the basic question of "do we need this at all" still seems open to me. In some ways, security is like insurance: it is only a problem if you don't have it after you should have.
Ignoring the "PGP versus X.509" question, does the membership want us to support signed e-mail at all? What about encrypted e-mail?
Given the mess an evil person can do by creatively adjusting records in the routing database, I suggest that RIRen must actively promote the use of technologies that protect our infrastructure; thus, signing should be more or less mandatory, and encryption should be available for secure out-of-band communications -- this then more human-to-human, to solve strange issues, send sensitive data, and so forth. rgds, -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE
Hi, On Fri, Feb 27, 2004 at 11:22:37AM +0100, Måns Nilsson KTHNOC wrote:
As others have noted, we can support both X.509 and PGP. We can also support *only* PGP, although I think because of #2, above, this is not a good solution.
I would argue that it is the other way around; given the forced choice of "only one" the broadest support exists for PGP.
I don't see anyone talking about "only one". Why are you worried? (If someone proposed abandoning PGP, I would be one of the loudest voices opposing it) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
I would argue that it is the other way around; given the forced choice of "only one" the broadest support exists for PGP.
I don't see anyone talking about "only one". Why are you worried?
Well, that's not quite precise. The document under discussion talks about securing communication to and from RIPE NCC registration services mailboxes, e.g. hostmaster@ripe.net etc. -- typically functions where humans at the RIPE NCC are involved in resolving the matter (yes?). Therefore, I perceive this as explicitly excluding auto-dbm@ripe.net. Add to that that Shane Kerr has explicitly said in this discussion that none of the current PGP support will be removed. However, the document under discussion appears to offer X.509 as the only method for securing communication with RS mailboxes, the alternative is continue as today, where this communication is going unsigned and in the clear in both directions. Regards, - Håvard
Teilnehmer (9)
-
Dmitry Morozovsky -
Gert Doering -
Havard Eidnes -
Kurt Erik Lindqvist -
Kurt Jaeger -
Måns Nilsson KTHNOC -
Neil J. McRae -
Randy Bush -
Shane Kerr