Re: [Freeipa-devel] my remaining 4.2 tickets
On Fri, Jul 03, 2015 at 08:23:45AM +0200, Martin Kosek wrote: On 07/02/2015 05:58 PM, Jan Cholasta wrote: Hi, Dne 2.7.2015 v 17:18 Fraser Tweedale napsal(a): On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote: On 06/30/2015 03:03 PM, Fraser Tweedale wrote: #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. Ok. I was not involved when the ticket was filed, but it does not seem to me as something that should get much priority and your time at this stage. I haven't looked at this yet. FYI getcert supports setting EKU in the CSR using the -U option for a long time. It also correctly passes the profile to IPA since 0.78. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. I investigated this. My comments are on the ticket: https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief: the way our current SAN support is implemented makes this a non-trivial ticket. On a related note, I think we should also always include kerberos principal name SAN. That would be nice, how difficult is to enable this with certificates FreeIPA issues? It would also let us make easier principal-based queries for Dogtag certificates. Right? We could do it with a new ProfileInput class in Dogtag, possibly (probably) also requiring a new ProfileDefault class, and of course and update of the included profile(s) where we want this behaviour. I have a bolder vision for the future of Dogtag/IPA integration. I have had a some thoughts brewing in my mind for a while, ready to unleash after rhel72 crunch, but oh well, now you are making me reveal my ideas, hopefully not too prematurely :) In the medium-term we want to connect Dogtag (components thereof) to the IPA directory to read and enforce caacls. We also wish to use s4u2proxy to avoid all-powerful RA Agent cert and have Dogtag act with authenticated principal's authority. Since we will be talking to the IPA directory, we can create new profile components that read information directly out of the IPA directory. This will make it much simpler to pull fancy extension data or other information into certificates issued by Dogtag, all defined by profiles. These components can even be shipped as part of FreeIPA, as only FreeIPA-provided profiles would use them, and I believe it is fairly straightforward to tell Dogtag about 3rd-party classes. This gives us agility to include support for pulling data from IPA directory into certificates without depending on Dogtag release cycle. This sort of regime may also make it easier to tackle the desired profile builder feature. Finally, since it is JVM .class files we will be shipping we can write it using FP in Scala ^_^ Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] my remaining 4.2 tickets
On 07/02/2015 05:58 PM, Jan Cholasta wrote: Hi, Dne 2.7.2015 v 17:18 Fraser Tweedale napsal(a): On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote: On 06/30/2015 03:03 PM, Fraser Tweedale wrote: #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. Ok. I was not involved when the ticket was filed, but it does not seem to me as something that should get much priority and your time at this stage. I haven't looked at this yet. FYI getcert supports setting EKU in the CSR using the -U option for a long time. It also correctly passes the profile to IPA since 0.78. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. I investigated this. My comments are on the ticket: https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief: the way our current SAN support is implemented makes this a non-trivial ticket. On a related note, I think we should also always include kerberos principal name SAN. That would be nice, how difficult is to enable this with certificates FreeIPA issues? It would also let us make easier principal-based queries for Dogtag certificates. Right? Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] my remaining 4.2 tickets
On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote: On 06/30/2015 03:03 PM, Fraser Tweedale wrote: Hi Martin, #4559 [RFE] Support lightweight sub-CAs Remaining work is not huge but may be more than can be done this week even with Christian's help; the largest remaning concern being Custodia. As per discussion in team meeting, I'm going to liaise with Simo and determine a plan for the key replication. #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. Ok. I was not involved when the ticket was filed, but it does not seem to me as something that should get much priority and your time at this stage. I haven't looked at this yet. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. I investigated this. My comments are on the ticket: https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief: the way our current SAN support is implemented makes this a non-trivial ticket. Thanks, Fraser #4752 Provide an IEC 62351-8 / DNP3 ID certificate profile We can provide a profile that supports DNP3 extension now if it is included in a CSR extension request. The patches for IEC 62351-8 extension is in review. Once that is in Dogtag we will be able to provide a profile that supports it with an extensionRequest in CSR. Ok (can be FreeIP 4.2.x IMO). #3473 Switch to using RESTful interface in dogtag CA interface Postpone; there is not an urgent need. Right, already did :-) -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] my remaining 4.2 tickets
On 07/02/2015 05:18 PM, Fraser Tweedale wrote: On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote: On 06/30/2015 03:03 PM, Fraser Tweedale wrote: ... #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. I investigated this. My comments are on the ticket: https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief: the way our current SAN support is implemented makes this a non-trivial ticket. Thanks. What we need to do now (in the couple days left before 4.2 GA is to think if there is any problem that we would prevent us from adding this functionality later. If there is no problem, we are mostly done as won't be able to do the Dogtag changes before 4.2 GA I suppose. If yes, that's another story and we would need to plan what can be done before GA. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] my remaining 4.2 tickets
Hi, Dne 2.7.2015 v 17:18 Fraser Tweedale napsal(a): On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote: On 06/30/2015 03:03 PM, Fraser Tweedale wrote: #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. Ok. I was not involved when the ticket was filed, but it does not seem to me as something that should get much priority and your time at this stage. I haven't looked at this yet. FYI getcert supports setting EKU in the CSR using the -U option for a long time. It also correctly passes the profile to IPA since 0.78. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. I investigated this. My comments are on the ticket: https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief: the way our current SAN support is implemented makes this a non-trivial ticket. On a related note, I think we should also always include kerberos principal name SAN. Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] my remaining 4.2 tickets
Hi Martin, #4559 [RFE] Support lightweight sub-CAs Remaining work is not huge but may be more than can be done this week even with Christian's help; the largest remaning concern being Custodia. As per discussion in team meeting, I'm going to liaise with Simo and determine a plan for the key replication. #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. #4752 Provide an IEC 62351-8 / DNP3 ID certificate profile We can provide a profile that supports DNP3 extension now if it is included in a CSR extension request. The patches for IEC 62351-8 extension is in review. Once that is in Dogtag we will be able to provide a profile that supports it with an extensionRequest in CSR. #3473 Switch to using RESTful interface in dogtag CA interface Postpone; there is not an urgent need. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] my remaining 4.2 tickets
On 06/30/2015 03:03 PM, Fraser Tweedale wrote: Hi Martin, #4559 [RFE] Support lightweight sub-CAs Remaining work is not huge but may be more than can be done this week even with Christian's help; the largest remaning concern being Custodia. As per discussion in team meeting, I'm going to liaise with Simo and determine a plan for the key replication. #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. Ok. I was not involved when the ticket was filed, but it does not seem to me as something that should get much priority and your time at this stage. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. #4752 Provide an IEC 62351-8 / DNP3 ID certificate profile We can provide a profile that supports DNP3 extension now if it is included in a CSR extension request. The patches for IEC 62351-8 extension is in review. Once that is in Dogtag we will be able to provide a profile that supports it with an extensionRequest in CSR. Ok (can be FreeIP 4.2.x IMO). #3473 Switch to using RESTful interface in dogtag CA interface Postpone; there is not an urgent need. Right, already did :-) -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
