On 09/26/2013 10:25 PM, ?? wrote: It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK

On 10/04/2013 11:08 AM, Oleg Antonenko wrote: Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

On 10/04/2013 11:48 AM, Oleg Antonenko wrote: It is not "a part" it is a stand alone product and not free. Correct and same is true for RHEL7.x Correct RHCS is a layered product and can be acquired separately. We do not ship a version of RHCS on top of RHEL6. It is a big product and takes a lot of time to deliver. We decided to skip a major RHEL version. Correct. Ok let us have one. I am sorry, I have not been following the whole thread, just this mail caught my eye so what kind of functionality we are looking for? Can you formulate a "wish list" for your use case assuming the CA is a part of IPA? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

On 10/04/2013 12:12 PM, Oleg Antonenko wrote: Can you define workflows and actors? Who does what when to the certs? Are certs associated to users or to devices? Do you track devices in the CA or somewhere else? Are users enterprise users (belong to one company) or internet users (any user from the street)? Dogtag supports both. First as a protocol the second one is the component that can be installed and turned on. For SCEP do you actually need a SCEP client ? What do you use a SEP client? Are there any specific features of the SCEP protocol that are required that are currently natively not supported by the Dogtag CA? The product can be given a keytab and authenticate kerberos to the IPA. It is very simple and would be easier to accomplish. API for managing serts for hosts and services already available in IPA so the question is what the certs are associated with is very important. Also certmonger can be used for fetching certs and storing them in the files or DBs you need. Are you aware of certmonger? It can be effectively a whole alternative solution. From your portal you call Certmonger on the local system via CLI or D-BUS interface and it gets a cert for you. But I need to understand the workflow better. If you generate he PKI pair on you portal and deliver them to a device it is a perfect solution. If you use client side software on the mobile platform to send the signing request then it is a different workflow and you need to send such request to CA. When and where? During issuance or ability to later export it from the back end store? I am sorry I am not familiar with the details of the workflow in this case. Can you describe the chain of communication between mobile device, your portal and CA and what protocols used where? Yes this is a clear winner keeping in mind that we had some distant plans about the use case you are describing. Unfortunately we were not able to get a good understanding of the details of the use case in the past thus so many questions. Sorry. Thanks Dmitri -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

On 10/04/2013 02:06 PM, Nathan Kinder wrote: This is very helpful. So it seems that IPA CA might be used for this as is. The certs would just not be associeted with any specific entry and leave in the CA storage. Do I get it right? The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Since with Dogtag 10 you have REST API and CLI to add and manage those profiles and the data is sort of orthogonal to IPA data I do not see a reason why portal can't integrate those and use them directly. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

Hi Nathan, Dmitri, Thanks for the info and your comments. Please see my answers inline in red… From: Nathan Kinder [mailto:nkinder@redhat.com] Sent: 04 October 2013 20:53 To: dpal(a)redhat.com Cc: Oleg Antonenko; Ciaran Bradley; pki-users(a)redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:37 AM, Dmitri Pal wrote: On 10/04/2013 02:06 PM, Nathan Kinder wrote: On 10/04/2013 10:44 AM, Dmitri Pal wrote: On 10/04/2013 12:12 PM, Oleg Antonenko wrote: That’s all clear now, thank you Dmitri! Regarding our wish list :) Basically we just have evaluated ejbCA, so we want something similar but without EJB and heavy weight app server… i.e. - UI for managing certs Can you define workflows and actors? [OA] Workflow for iOS devices is well defined in the Apple’s guide referenced below. We will be building similar for Android - but simpler without a Profile Server. We use an MDM system for distributing SCEP profile/configuration to devices… Who does what when to the certs? [OA] Device itself plays a role of a SCEP client. After obtaining a cert devices would you use for setting up a VPN channel. Normally we are not planning actively manage certs for devices, except revocation. But for SSL servers we would have to issue certs manually, and then export full keysotre for manual deployment. Are certs associated to users or to devices? [OA] To devices, so the CN will contain a device ID. At the same time subjectAltName will be set to user’s email. So in theory it would be good to manage users but that is for the future… Do you track devices in the CA or somewhere else? [OA] No, we will track them in our application, which will be integrated with MDM for device enrolment and configuration (e.g. installing our VPN Client App & setting up SCEP Profile). So we will need the CA API only for revoking certs. Are users enterprise users (belong to one company) or internet users (any user from the street)? [OA] Enterprise Support SCEP & OCSP Dogtag supports both. First as a protocol the second one is the component that can be installed and turned on. [OA] Those are reasons for selecting it For SCEP do you actually need a SCEP client ? What do you use a SEP client? [OA] For iOS I presume there is an embedded client? For Android we’re developing our own. Are there any specific features of the SCEP protocol that are required that are currently natively not supported by the Dogtag CA? [OA] There is one area I still don’t have full understanding of. In the SCEP specs they say that a request for a cert is a PKCS#7 structure signed by either - * A cert issued earlier by the requested CA (re-issuance) * Self-signed cert * A 3rd party cert signed by a trusted CA (e.g. a generic transport cert) The P7 structure contains a P10 request encrypted with the requested CA pub key. When testing issuing certs for iOS devices in dogtag our developers had an impression that the P10 is not encrypted, and the P7 is not signed. I’m frankly not convinced by their words. Could you confirm please that the SCEP cert request is processed in dogtag as above? API for issuing and revoking certs (cert-based request auth is preferrable) - as we want to integrate out product for revoking certs The product can be given a keytab and authenticate kerberos to the IPA. It is very simple and would be easier to accomplish. API for managing serts for hosts and services already available in IPA so the question is what the certs are associated with is very important. Also certmonger can be used for fetching certs and storing them in the files or DBs you need. Are you aware of certmonger? [OA] No, did not hear before. As I understand it has a command line / d-bus interfaces? We need something like a WS or REST. It can be effectively a whole alternative solution. From your portal you call Certmonger on the local system via CLI or D-BUS interface and it gets a cert for you. But I need to understand the workflow better. If you generate he PKI pair on you portal and deliver them to a device it is a perfect solution. If you use client side software on the mobile platform to send the signing request then it is a different workflow and you need to send such request to CA. [OA] Yes, the latter… Desirable - Export a key store (including cert) as PKCS#12, PEM (for manual deployment of certs on e.g. SSL servers). When and where? During issuance or ability to later export it from the back end store? [OA] For SSL serves terminating VPN connection from mobile devices. So we would create them before and parallel to issuing to devices… I think it’s going to be like an admin would login into the UI, enter machine details for the cert & key store. In response the CA would generate a keypair and issue a cert. Then we would need to export the keystore either as p12 or PEM file… As mentioned earlier we are planning to use a CA for issuing and delivering certs to mobile devices via SCEP. I am sorry I am not familiar with the details of the workflow in this case. Can you describe the chain of communication between mobile device, your portal and CA and what protocols used where? iOS devices uses SCEP to enroll for certificates. The basic flow is that you have a "Profile Server", which is responsible for delivering a XML profile onto the authenticated iOS device. This XML profile contains details on how the iOS device should contact the CA via SCEP. When the profile is installed, the SCEP request is made and the returned certificate is installed. There is a good visual workflow of this process in this document: https://developer.apple.com/library/ios/documentation/networkinginternet/... This is very helpful. So it seems that IPA CA might be used for this as is. The certs would just not be associeted with any specific entry and leave in the CA storage. Do I get it right? I think so. [OA] Yes, correct. Btw, what storage the CA is using? Ldap? The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Yes, getting the profile set up would be then main thing to tackle. [OA] Could you give me a bit more insight what is advantage/why to use an additional SCEP profile? Since with Dogtag 10 you have REST API and CLI to add and manage those profiles and the data is sort of orthogonal to IPA data I do not see a reason why portal can't integrate those and use them directly. To clarify, profile management REST interfaces are in Dogag 10.1 (not 10.0). Regardless, profiles can be configured without the REST interfaces and be used directly with IPA being none the wiser. [OA] We would configure the CA manually. API is needed for cert revocation only. Does dogtag 9 supports REST for revocation? -NGK So far we managed to issue certs for iphones via SCEP in ejbCA and Dogtag (pki-ca 9.0.3-30 package). Dogtag wins provided we can carry on using standalone CA services in the future for free as a part of RHEL IPA… Yes this is a clear winner keeping in mind that we had some distant plans about the use case you are describing. Unfortunately we were not able to get a good understanding of the details of the use case in the past thus so many questions. Sorry. [OA] That’s cool, it seems you’ve got it right… Thanks Dmitri Thanks, Oleg From: Dmitri Pal [mailto:dpal@redhat.com] Sent: 04 October 2013 16:54 To: Oleg Antonenko Cc: Nathan Kinder (nkinder@redhat.com<mailto:nkinder@redhat.com>); Ciaran Bradley; pki-users@redhat.com<mailto:pki-users@redhat.com> Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:48 AM, Oleg Antonenko wrote: Hi Dmitri, Nathan, Thank you for speedy responses. Could you please confirm my understanding? RHCS is going to be shipped as a part of RHEL7.x in the foreseeable future; It is not "a part" it is a stand alone product and not free. IPA is a free part of RHEL 6.x and will remain as such in the foreseeable future; Correct and same is true for RHEL7.x RHEL 6.x does not ship RHCS, but includes only pki-ca packages in order to support IPA. Correct Could you also clarify your point here ? The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 RHCS is a layered product and can be acquired separately. We do not ship a version of RHCS on top of RHEL6. It is a big product and takes a lot of time to deliver. We decided to skip a major RHEL version. Does it mean RHCS is not free? Correct. Regarding this - We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Yes, we’d love to. Ok let us have one. I am sorry, I have not been following the whole thread, just this mail caught my eye so what kind of functionality we are looking for? Can you formulate a "wish list" for your use case assuming the CA is a part of IPA? Many thanks, Oleg From: pki-users-bounces@redhat.com<mailto:pki-users-bounces@redhat.com> [mailto:pki-users-bounces@redhat.com] On Behalf Of Dmitri Pal Sent: 04 October 2013 16:21 To: pki-users@redhat.com<mailto:pki-users@redhat.com> Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:08 AM, Oleg Antonenko wrote: Hi Nathan, Could you please shed some light on the future plans for the pki-ca portion of RHEL? Will it be included in the standard RHEL distribution in the future? Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri I’m asking because we’re planning to use the CA bit only for issuing certificates to mobile devices via SCEP. We do not require any other services or the full blown IPA… With thanks, Oleg From: pki-users-bounces@redhat.com<mailto:pki-users-bounces@redhat.com> [mailto:pki-users-bounces@redhat.com] On Behalf Of Nathan Kinder Sent: 27 September 2013 20:03 To: pki-users@redhat.com<mailto:pki-users@redhat.com> Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 09/26/2013 10:25 PM, 安 泱 wrote: Hi all, I'm a beginner of the dogtag certificate system, dogtag（RHCS）is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons？ It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK Regards. An Yang _______________________________________________ Pki-users mailing list Pki-users@redhat.com<mailto:Pki-users@redhat.com> https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users@redhat.com<mailto:Pki-users@redhat.com> https://www.redhat.com/mailman/listinfo/pki-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/> -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/> -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/> -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>

Thanks Dmitri. It would be nice to get a confirmation from Nathan regarding p7/p10 signing/encryption when dogtag processes SCEP requests. Here I just wanted to clarify some pointers on Cert Profiles. The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Yes, getting the profile set up would be then main thing to tackle. [OA] Could you give me a bit more insight what is advantage/why to use an additional SCEP profile? Cert profile is a template for issuing certs. Dogtag allows you to have more than a single template. This makes possible to issue certs containing different contents and used for different purposes: VPN, authentication, message signing etc. IPA installs just one profile. I suspect that mobile devices would need to have certs with specific attributes in them. For that you would need to either modify the existing profile or add another one. Latest versions of Dogtag CA have REST API to manage these profiles programmatically but this capability is not integrated into IPA yet. So with existing IPA version you would need to either modify existing profile or add a new one manually. [OA-2] This is a desirable option. We did not explore the current dogtag 9.0 UI much, so I’m sorry if this is trivial. Does this UI provide a function for creating/setting up new Cert Profiles? If you start with latest Dogtag and version in Fedora 19 that will be a part of RHEL7 you can probably use REST API directly and add/modify profiles as you need. In future IPA will provide API/CLI/UI that would wrap this REST API and allow you to mange this consistently with the rest of the IPA objects. From: Dmitri Pal [mailto:dpal@redhat.com] Sent: 07 October 2013 14:31 To: Oleg Antonenko Cc: Nathan Kinder; Ciaran Bradley; pki-users(a)redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/07/2013 05:19 AM, Oleg Antonenko wrote: Hi Nathan, Dmitri, Thanks for the info and your comments. Please see my answers inline in red… From: Nathan Kinder [mailto:nkinder@redhat.com] Sent: 04 October 2013 20:53 To: dpal@redhat.com<mailto:dpal@redhat.com> Cc: Oleg Antonenko; Ciaran Bradley; pki-users@redhat.com<mailto:pki-users@redhat.com> Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:37 AM, Dmitri Pal wrote: On 10/04/2013 02:06 PM, Nathan Kinder wrote: On 10/04/2013 10:44 AM, Dmitri Pal wrote: On 10/04/2013 12:12 PM, Oleg Antonenko wrote: That’s all clear now, thank you Dmitri! Regarding our wish list :) Basically we just have evaluated ejbCA, so we want something similar but without EJB and heavy weight app server… i.e. - UI for managing certs Can you define workflows and actors? [OA] Workflow for iOS devices is well defined in the Apple’s guide referenced below. We will be building similar for Android - but simpler without a Profile Server. We use an MDM system for distributing SCEP profile/configuration to devices… Who does what when to the certs? [OA] Device itself plays a role of a SCEP client. After obtaining a cert devices would you use for setting up a VPN channel. Normally we are not planning actively manage certs for devices, except revocation. But for SSL servers we would have to issue certs manually, and then export full keysotre for manual deployment. Are certs associated to users or to devices? [OA] To devices, so the CN will contain a device ID. At the same time subjectAltName will be set to user’s email. So in theory it would be good to manage users but that is for the future… Do you track devices in the CA or somewhere else? [OA] No, we will track them in our application, which will be integrated with MDM for device enrolment and configuration (e.g. installing our VPN Client App & setting up SCEP Profile). So we will need the CA API only for revoking certs. Are users enterprise users (belong to one company) or internet users (any user from the street)? [OA] Enterprise Support SCEP & OCSP Dogtag supports both. First as a protocol the second one is the component that can be installed and turned on. [OA] Those are reasons for selecting it For SCEP do you actually need a SCEP client ? What do you use a SEP client? [OA] For iOS I presume there is an embedded client? For Android we’re developing our own. Are there any specific features of the SCEP protocol that are required that are currently natively not supported by the Dogtag CA? [OA] There is one area I still don’t have full understanding of. In the SCEP specs they say that a request for a cert is a PKCS#7 structure signed by either - * A cert issued earlier by the requested CA (re-issuance) * Self-signed cert * A 3rd party cert signed by a trusted CA (e.g. a generic transport cert) The P7 structure contains a P10 request encrypted with the requested CA pub key. When testing issuing certs for iOS devices in dogtag our developers had an impression that the P10 is not encrypted, and the P7 is not signed. I’m frankly not convinced by their words. Could you confirm please that the SCEP cert request is processed in dogtag as above? I would leave this to Nathan to confirm. API for issuing and revoking certs (cert-based request auth is preferrable) - as we want to integrate out product for revoking certs The product can be given a keytab and authenticate kerberos to the IPA. It is very simple and would be easier to accomplish. API for managing serts for hosts and services already available in IPA so the question is what the certs are associated with is very important. Also certmonger can be used for fetching certs and storing them in the files or DBs you need. Are you aware of certmonger? [OA] No, did not hear before. As I understand it has a command line / d-bus interfaces? We need something like a WS or REST. The point is that you can create a simple WS or REST server around it very easily. It can be effectively a whole alternative solution. From your portal you call Certmonger on the local system via CLI or D-BUS interface and it gets a cert for you. But I need to understand the workflow better. If you generate he PKI pair on you portal and deliver them to a device it is a perfect solution. If you use client side software on the mobile platform to send the signing request then it is a different workflow and you need to send such request to CA.[OA] Yes, the latter… I see. Desirable - Export a key store (including cert) as PKCS#12, PEM (for manual deployment of certs on e.g. SSL servers). When and where? During issuance or ability to later export it from the back end store? [OA] For SSL serves terminating VPN connection from mobile devices. So we would create them before and parallel to issuing to devices… I think it’s going to be like an admin would login into the UI, enter machine details for the cert & key store. In response the CA would generate a keypair and issue a cert. Then we would need to export the keystore either as p12 or PEM file… You might want to consider using IPA to mange servers and their certs. AFAIR IPA allows you to save certs in a PEM file. Then for the devices you will use Dogtag directly but for servers you will leverage all the advantages of IPA. Seems like a double win. As mentioned earlier we are planning to use a CA for issuing and delivering certs to mobile devices via SCEP. I am sorry I am not familiar with the details of the workflow in this case. Can you describe the chain of communication between mobile device, your portal and CA and what protocols used where? iOS devices uses SCEP to enroll for certificates. The basic flow is that you have a "Profile Server", which is responsible for delivering a XML profile onto the authenticated iOS device. This XML profile contains details on how the iOS device should contact the CA via SCEP. When the profile is installed, the SCEP request is made and the returned certificate is installed. There is a good visual workflow of this process in this document: https://developer.apple.com/library/ios/documentation/networkinginternet/... This is very helpful. So it seems that IPA CA might be used for this as is. The certs would just not be associeted with any specific entry and leave in the CA storage. Do I get it right? I think so.[OA] Yes, correct. Btw, what storage the CA is using? Ldap? Yes. The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Yes, getting the profile set up would be then main thing to tackle. [OA] Could you give me a bit more insight what is advantage/why to use an additional SCEP profile? Cert profile is a template for issuing certs. Dogtag allows you to have more than a single template. This makes possible to issue certs containing different contents and used for different purposes: VPN, authentication, message signing etc. IPA installs just one profile. I suspect that mobile devices would need to have certs with specific attributes in them. For that you would need to either modify the existing profile or add another one. Latest versions of Dogtag CA have REST API to manage these profiles programmatically but this capability is not integrated into IPA yet. So with existing IPA version you would need to either modify existing profile or add a new one manually. If you start with latest Dogtag and version in Fedora 19 that will be a part of RHEL7 you can probably use REST API directly and add/modify profiles as you need. In future IPA will provide API/CLI/UI that would wrap this REST API and allow you to mange this consistently with the rest of the IPA objects. Since with Dogtag 10 you have REST API and CLI to add and manage those profiles and the data is sort of orthogonal to IPA data I do not see a reason why portal can't integrate those and use them directly. To clarify, profile management REST interfaces are in Dogag 10.1 (not 10.0). Regardless, profiles can be configured without the REST interfaces and be used directly with IPA being none the wiser. [OA] We would configure the CA manually. API is needed for cert revocation only. Does dogtag 9 supports REST for revocation? Dogtag 9 does not support any REST API. -NGK So far we managed to issue certs for iphones via SCEP in ejbCA and Dogtag (pki-ca 9.0.3-30 package). Dogtag wins provided we can carry on using standalone CA services in the future for free as a part of RHEL IPA… Yes this is a clear winner keeping in mind that we had some distant plans about the use case you are describing. Unfortunately we were not able to get a good understanding of the details of the use case in the past thus so many questions. Sorry. [OA] That’s cool, it seems you’ve got it right… We would like to help you as much as possible with what we have now and give you a clear migration path for the solutions we are building. This is why Dogtag 10+ and IPA 3.2+ is probably the best starting point. Thanks Dmitri Thanks, Oleg From: Dmitri Pal [mailto:dpal@redhat.com] Sent: 04 October 2013 16:54 To: Oleg Antonenko Cc: Nathan Kinder (nkinder@redhat.com<mailto:nkinder@redhat.com>); Ciaran Bradley; pki-users@redhat.com<mailto:pki-users@redhat.com> Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:48 AM, Oleg Antonenko wrote: Hi Dmitri, Nathan, Thank you for speedy responses. Could you please confirm my understanding? RHCS is going to be shipped as a part of RHEL7.x in the foreseeable future; It is not "a part" it is a stand alone product and not free. IPA is a free part of RHEL 6.x and will remain as such in the foreseeable future; Correct and same is true for RHEL7.x RHEL 6.x does not ship RHCS, but includes only pki-ca packages in order to support IPA. Correct Could you also clarify your point here ? The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 RHCS is a layered product and can be acquired separately. We do not ship a version of RHCS on top of RHEL6. It is a big product and takes a lot of time to deliver. We decided to skip a major RHEL version. Does it mean RHCS is not free? Correct. Regarding this - We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Yes, we’d love to. Ok let us have one. I am sorry, I have not been following the whole thread, just this mail caught my eye so what kind of functionality we are looking for? Can you formulate a "wish list" for your use case assuming the CA is a part of IPA? Many thanks, Oleg From: pki-users-bounces@redhat.com<mailto:pki-users-bounces@redhat.com> [mailto:pki-users-bounces@redhat.com] On Behalf Of Dmitri Pal Sent: 04 October 2013 16:21 To: pki-users@redhat.com<mailto:pki-users@redhat.com> Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:08 AM, Oleg Antonenko wrote: Hi Nathan, Could you please shed some light on the future plans for the pki-ca portion of RHEL? Will it be included in the standard RHEL distribution in the future? Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri I’m asking because we’re planning to use the CA bit only for issuing certificates to mobile devices via SCEP. We do not require any other services or the full blown IPA… With thanks, Oleg From: pki-users-bounces@redhat.com<mailto:pki-users-bounces@redhat.com> [mailto:pki-users-bounces@redhat.com] On Behalf Of Nathan Kinder Sent: 27 September 2013 20:03 To: pki-users@redhat.com<mailto:pki-users@redhat.com> Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 09/26/2013 10:25 PM, 安 泱 wrote: Hi all, I'm a beginner of the dogtag certificate system, dogtag（RHCS）is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons？ It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK Regards. An Yang _______________________________________________ Pki-users mailing list Pki-users@redhat.com<mailto:Pki-users@redhat.com> https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users@redhat.com<mailto:Pki-users@redhat.com> https://www.redhat.com/mailman/listinfo/pki-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/> -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/> -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/> -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/> -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/<http://www.redhat.com/carveoutcosts/>

On 10/04/2013 08:08 AM, Oleg Antonenko wrote: The CA potion is included in RHEL for use by IPA. There are no plans to change this. The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 (but will be at some point in the future). Thanks, -NGK