Re: [Freeipa-devel] V4/RFC 2818 review
Greetings! I've received the information from Milan who was UQE reviewer for this design document - ACK on the current version. Have a nice day, - alich - - Original Message - > From: "Fraser Tweedale" <ftwee...@redhat.com> > To: "Alexander Bokovoy" <aboko...@redhat.com> > Cc: "freeipa-devel" <freeipa-devel@redhat.com> > Sent: Thursday, April 21, 2016 9:34:51 AM > Subject: Re: [Freeipa-devel] V4/RFC 2818 review > > On Thu, Apr 21, 2016 at 10:22:33AM +0300, Alexander Bokovoy wrote: > > On Thu, 21 Apr 2016, Fraser Tweedale wrote: > > >On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: > > >>Christian Heimes wrote: > > >>>Hi Fraser, > > >>> > > >>>and now to the review of your design doc for RFC 2818-compliant subject > > >>>alternative names in certs, > > >>>http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > >>> > > >>> > > >>>1) RFC 2818 vs. RFC 6125 > > >>> > > >>>First I like to address a more general topic. Your design mentions RFC > > >>>6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > > >>>verification and we should follow the rules in RFC 6125, whenever 2818 > > >>>lacks specification or there is a conflict between both RFCs. I can tell > > >>>you some horror stories from Python's ssl module related to both RFCs. > > >>> > > >>>https://tools.ietf.org/html/rfc2818, HTTP Over TLS > > >>> > > >>>https://tools.ietf.org/html/rfc6125, Representation and Verification of > > >>>Domain-Based Application Service Identity within Internet Public Key > > >>>Infrastructure Using X.509 (PKIX) Certificates in the Context of > > >>>Transport Layer Security (TLS) > > >>> > > >>>As far as I'm familiar with RFC 6125, your proposal doesn't conflict > > >>>with the more modern RFC. It also makes sense to name the design after > > >>>the RFC, which has deprecated CN. I still like to check your design > > >>>against RFC 6125. > > >>> > > >>>Fraser, do you agree? > > >>> > > >>> > > >>>2) SAN validation in ipa cert-request > > >>> > > >>>In the paragraph "ipa cert-request changes" you write that the plugin > > >>>"[...] ensure that one element of the DNS names list matches the > > >>>principal name". Shouldn't the plugin validate *all* DNS names and > > >>>verify that the principal is allowed to request a cert for all fields in > > >>>SAN? > > >> > > >>Are there plans for any other SAN types? IP address or other oddball > > >>types > > >>like MS UPN? > > >> > > >We support almost all of them in Dogtag, and only support a few > > >types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). > > > > > >We should work out what we can do with IP address; I recall it is > > >needed (or wanted) for some cloud/IaaS use cases. > > Yes, some of Openstack code expects IP address in the certificates. > > > > >DirectoryName would be simple to support (just check that it matches > > >DN of target principal). I wonder if there is a use case for it, or > > >for any other SAN types... > > dNSName and id-pkinit-san are used by Kerberos PKINIT support in MIT > > Kerberos for host-based principals. id-pkinit-san is also in use for > > mapping of the principal in general. > > > > In fact, Kerberos PKINIT retrieves all SANs and UPNs from the certificate > > and > > allows to match them by the matching rules -- id-pkinit-san goes to list > > of principals, id-ms-san-upn goes to the list of UPNs which are then > > merged together and can be addressed with keyword in the matching > > rule. > > > > This allows very flexible matching: > >pkinit_cert_match = ||.*DoE.*.*@EXAMPLE.COM > >pkinit_cert_match = > >&&msScLogin,clientAuth.*DoE.* > >pkinit_cert_match = > >msScLogin,clientAuthdigitalSignature > > > Thank you for the information! > > > > > > > >>> > > >>>3) Should FreeIPA deprecate cert request without SAN or at least warn > > >>>the user? > > >>> > > >>>IMHO it makes sense to deprecate CN on
Re: [Freeipa-devel] V4/RFC 2818 review
On Thu, Apr 21, 2016 at 10:22:33AM +0300, Alexander Bokovoy wrote: > On Thu, 21 Apr 2016, Fraser Tweedale wrote: > >On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: > >>Christian Heimes wrote: > >>>Hi Fraser, > >>> > >>>and now to the review of your design doc for RFC 2818-compliant subject > >>>alternative names in certs, > >>>http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > >>> > >>> > >>>1) RFC 2818 vs. RFC 6125 > >>> > >>>First I like to address a more general topic. Your design mentions RFC > >>>6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > >>>verification and we should follow the rules in RFC 6125, whenever 2818 > >>>lacks specification or there is a conflict between both RFCs. I can tell > >>>you some horror stories from Python's ssl module related to both RFCs. > >>> > >>>https://tools.ietf.org/html/rfc2818, HTTP Over TLS > >>> > >>>https://tools.ietf.org/html/rfc6125, Representation and Verification of > >>>Domain-Based Application Service Identity within Internet Public Key > >>>Infrastructure Using X.509 (PKIX) Certificates in the Context of > >>>Transport Layer Security (TLS) > >>> > >>>As far as I'm familiar with RFC 6125, your proposal doesn't conflict > >>>with the more modern RFC. It also makes sense to name the design after > >>>the RFC, which has deprecated CN. I still like to check your design > >>>against RFC 6125. > >>> > >>>Fraser, do you agree? > >>> > >>> > >>>2) SAN validation in ipa cert-request > >>> > >>>In the paragraph "ipa cert-request changes" you write that the plugin > >>>"[...] ensure that one element of the DNS names list matches the > >>>principal name". Shouldn't the plugin validate *all* DNS names and > >>>verify that the principal is allowed to request a cert for all fields in > >>>SAN? > >> > >>Are there plans for any other SAN types? IP address or other oddball types > >>like MS UPN? > >> > >We support almost all of them in Dogtag, and only support a few > >types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). > > > >We should work out what we can do with IP address; I recall it is > >needed (or wanted) for some cloud/IaaS use cases. > Yes, some of Openstack code expects IP address in the certificates. > > >DirectoryName would be simple to support (just check that it matches > >DN of target principal). I wonder if there is a use case for it, or > >for any other SAN types... > dNSName and id-pkinit-san are used by Kerberos PKINIT support in MIT > Kerberos for host-based principals. id-pkinit-san is also in use for > mapping of the principal in general. > > In fact, Kerberos PKINIT retrieves all SANs and UPNs from the certificate and > allows to match them by the matching rules -- id-pkinit-san goes to list > of principals, id-ms-san-upn goes to the list of UPNs which are then > merged together and can be addressed with keyword in the matching > rule. > > This allows very flexible matching: >pkinit_cert_match = ||.*DoE.*.*@EXAMPLE.COM >pkinit_cert_match = &&msScLogin,clientAuth.*DoE.* >pkinit_cert_match = > msScLogin,clientAuthdigitalSignature > Thank you for the information! > > > >>> > >>>3) Should FreeIPA deprecate cert request without SAN or at least warn > >>>the user? > >>> > >>>IMHO it makes sense to deprecate CN only cert requests. > >> > >>I'd mark it as deprecated over at least a major release in order to handle > >>older versions that may still make requests without a SAN. > >> > >We have to be careful here. CN is depreated for DNS name checking > >in HTTP (or other network protocols using TLS). Fine - but there > >could be other certificate use cases that require CN, e.g. user > >certs where Subject DN corresponds to a directory name. > Yes. pkinit_cert_match's rule is using Subject DN for checks. > > > >We can deprecate it and eventually reject requests that include CN - > >but only for service cert profile(s). (This would require a new > >profile component designed for this purpose). > Please do not do it. There are known uses for it at least with Kerberos. > Of course, most of them are rather for user certificates but in reality > Kerberos does not require you to have service principals always as DNS > names. > There is the option of implementing the component that prohibits CN. I was by no means suggesting it should be used for all profiles. Customers can use it on a custom profile if they want. We could use it on the default service cert profile if we want. 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] V4/RFC 2818 review
On Thu, 21 Apr 2016, Fraser Tweedale wrote: On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: Christian Heimes wrote: >Hi Fraser, > >and now to the review of your design doc for RFC 2818-compliant subject >alternative names in certs, >http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > >1) RFC 2818 vs. RFC 6125 > >First I like to address a more general topic. Your design mentions RFC >6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname >verification and we should follow the rules in RFC 6125, whenever 2818 >lacks specification or there is a conflict between both RFCs. I can tell >you some horror stories from Python's ssl module related to both RFCs. > >https://tools.ietf.org/html/rfc2818, HTTP Over TLS > >https://tools.ietf.org/html/rfc6125, Representation and Verification of >Domain-Based Application Service Identity within Internet Public Key >Infrastructure Using X.509 (PKIX) Certificates in the Context of >Transport Layer Security (TLS) > >As far as I'm familiar with RFC 6125, your proposal doesn't conflict >with the more modern RFC. It also makes sense to name the design after >the RFC, which has deprecated CN. I still like to check your design >against RFC 6125. > >Fraser, do you agree? > > >2) SAN validation in ipa cert-request > >In the paragraph "ipa cert-request changes" you write that the plugin >"[...] ensure that one element of the DNS names list matches the >principal name". Shouldn't the plugin validate *all* DNS names and >verify that the principal is allowed to request a cert for all fields in >SAN? Are there plans for any other SAN types? IP address or other oddball types like MS UPN? We support almost all of them in Dogtag, and only support a few types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). We should work out what we can do with IP address; I recall it is needed (or wanted) for some cloud/IaaS use cases. Yes, some of Openstack code expects IP address in the certificates. DirectoryName would be simple to support (just check that it matches DN of target principal). I wonder if there is a use case for it, or for any other SAN types... dNSName and id-pkinit-san are used by Kerberos PKINIT support in MIT Kerberos for host-based principals. id-pkinit-san is also in use for mapping of the principal in general. In fact, Kerberos PKINIT retrieves all SANs and UPNs from the certificate and allows to match them by the matching rules -- id-pkinit-san goes to list of principals, id-ms-san-upn goes to the list of UPNs which are then merged together and can be addressed with keyword in the matching rule. This allows very flexible matching: pkinit_cert_match = ||.*DoE.*.*@EXAMPLE.COM pkinit_cert_match = &&msScLogin,clientAuth.*DoE.* pkinit_cert_match = msScLogin,clientAuthdigitalSignature > >3) Should FreeIPA deprecate cert request without SAN or at least warn >the user? > >IMHO it makes sense to deprecate CN only cert requests. I'd mark it as deprecated over at least a major release in order to handle older versions that may still make requests without a SAN. We have to be careful here. CN is depreated for DNS name checking in HTTP (or other network protocols using TLS). Fine - but there could be other certificate use cases that require CN, e.g. user certs where Subject DN corresponds to a directory name. Yes. pkinit_cert_match's rule is using Subject DN for checks. We can deprecate it and eventually reject requests that include CN - but only for service cert profile(s). (This would require a new profile component designed for this purpose). Please do not do it. There are known uses for it at least with Kerberos. Of course, most of them are rather for user certificates but in reality Kerberos does not require you to have service principals always as DNS names. -- / Alexander Bokovoy -- 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] V4/RFC 2818 review
On Tue, Apr 19, 2016 at 04:14:01PM +0200, Christian Heimes wrote: > Hi Fraser, > > and now to the review of your design doc for RFC 2818-compliant subject > alternative names in certs, > http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > > 1) RFC 2818 vs. RFC 6125 > > First I like to address a more general topic. Your design mentions RFC > 6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > verification and we should follow the rules in RFC 6125, whenever 2818 > lacks specification or there is a conflict between both RFCs. I can tell > you some horror stories from Python's ssl module related to both RFCs. > > https://tools.ietf.org/html/rfc2818, HTTP Over TLS > > https://tools.ietf.org/html/rfc6125, Representation and Verification of > Domain-Based Application Service Identity within Internet Public Key > Infrastructure Using X.509 (PKIX) Certificates in the Context of > Transport Layer Security (TLS) > > As far as I'm familiar with RFC 6125, your proposal doesn't conflict > with the more modern RFC. It also makes sense to name the design after > the RFC, which has deprecated CN. I still like to check your design > against RFC 6125. > > Fraser, do you agree? > The scope of RFC 6125 seems much larger than RFC 2818, e.g. moving toward support for SRVName and uniformResourceIdentifier, and deprecating wildcard certs. It absolutely makes sense to check my design against RFC 6125 but I don't think it makes sense to indicate that the design aspires to "RFC 6125 compliance" (it does not). I think I will leave the design name and scope as-is but I will update the design to mention RFC 6125 and the need to comply with relevant aspects thereof. > > 2) SAN validation in ipa cert-request > > In the paragraph "ipa cert-request changes" you write that the plugin > "[...] ensure that one element of the DNS names list matches the > principal name". Shouldn't the plugin validate *all* DNS names and > verify that the principal is allowed to request a cert for all fields in > SAN? > The preceding point states: For each dNSName in the subjectAltName extension, in addition to the existing checks, append the value to the list of DNS names. These existing checks ensure that each dnsName matches a principal that is "managed by" the nominated subject principal (nb: each host/service manages itself). The final point ensure that one of the dnsNames does actually correspond to the subject principal. i.e. you can't issue containing dnsNames managed by the subject principal, yet omit a dnsName for the subject principal itself. I will expand the wording of the design to (try to) clarify this. > > 3) Should FreeIPA deprecate cert request without SAN or at least warn > the user? > > IMHO it makes sense to deprecate CN only cert requests. > See my response to Rob's reply. > > 4) update "Issue New Certificate for Host" dialog and documentation > > The web UI has an update "Issue New Certificate for Host" dialog which > explains how to create a CSR with certutil. This dialog should be > updated to explain how to add a SAN DNS field. The option for SAN DNS is > '-8 fqdn' or '--extSAN dns:fqdn', e.g. > > Create a CSR with subject CN=,O=, for example: > # certutil -R -d -a -g -s > 'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' > Yes, good idea. Thanks for the review! 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] V4/RFC 2818 review
On Tue, Apr 19, 2016 at 11:06:15AM -0400, Rob Crittenden wrote: > Christian Heimes wrote: > >Hi Fraser, > > > >and now to the review of your design doc for RFC 2818-compliant subject > >alternative names in certs, > >http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance > > > > > >1) RFC 2818 vs. RFC 6125 > > > >First I like to address a more general topic. Your design mentions RFC > >6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname > >verification and we should follow the rules in RFC 6125, whenever 2818 > >lacks specification or there is a conflict between both RFCs. I can tell > >you some horror stories from Python's ssl module related to both RFCs. > > > >https://tools.ietf.org/html/rfc2818, HTTP Over TLS > > > >https://tools.ietf.org/html/rfc6125, Representation and Verification of > >Domain-Based Application Service Identity within Internet Public Key > >Infrastructure Using X.509 (PKIX) Certificates in the Context of > >Transport Layer Security (TLS) > > > >As far as I'm familiar with RFC 6125, your proposal doesn't conflict > >with the more modern RFC. It also makes sense to name the design after > >the RFC, which has deprecated CN. I still like to check your design > >against RFC 6125. > > > >Fraser, do you agree? > > > > > >2) SAN validation in ipa cert-request > > > >In the paragraph "ipa cert-request changes" you write that the plugin > >"[...] ensure that one element of the DNS names list matches the > >principal name". Shouldn't the plugin validate *all* DNS names and > >verify that the principal is allowed to request a cert for all fields in > >SAN? > > Are there plans for any other SAN types? IP address or other oddball types > like MS UPN? > We support almost all of them in Dogtag, and only support a few types in FreeIPA (dnsName, rfc822Name, KRB5PrincipalName, UPN). We should work out what we can do with IP address; I recall it is needed (or wanted) for some cloud/IaaS use cases. DirectoryName would be simple to support (just check that it matches DN of target principal). I wonder if there is a use case for it, or for any other SAN types... > > > >3) Should FreeIPA deprecate cert request without SAN or at least warn > >the user? > > > >IMHO it makes sense to deprecate CN only cert requests. > > I'd mark it as deprecated over at least a major release in order to handle > older versions that may still make requests without a SAN. > We have to be careful here. CN is depreated for DNS name checking in HTTP (or other network protocols using TLS). Fine - but there could be other certificate use cases that require CN, e.g. user certs where Subject DN corresponds to a directory name. We can deprecate it and eventually reject requests that include CN - but only for service cert profile(s). (This would require a new profile component designed for this purpose). > > > >4) update "Issue New Certificate for Host" dialog and documentation > > > >The web UI has an update "Issue New Certificate for Host" dialog which > >explains how to create a CSR with certutil. This dialog should be > >updated to explain how to add a SAN DNS field. The option for SAN DNS is > >'-8 fqdn' or '--extSAN dns:fqdn', e.g. > > > >Create a CSR with subject CN=,O=, for example: > ># certutil -R -d -a -g -s > >'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' > > rob > -- 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] V4/RFC 2818 review
Christian Heimes wrote: Hi Fraser, and now to the review of your design doc for RFC 2818-compliant subject alternative names in certs, http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance 1) RFC 2818 vs. RFC 6125 First I like to address a more general topic. Your design mentions RFC 6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname verification and we should follow the rules in RFC 6125, whenever 2818 lacks specification or there is a conflict between both RFCs. I can tell you some horror stories from Python's ssl module related to both RFCs. https://tools.ietf.org/html/rfc2818, HTTP Over TLS https://tools.ietf.org/html/rfc6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) As far as I'm familiar with RFC 6125, your proposal doesn't conflict with the more modern RFC. It also makes sense to name the design after the RFC, which has deprecated CN. I still like to check your design against RFC 6125. Fraser, do you agree? 2) SAN validation in ipa cert-request In the paragraph "ipa cert-request changes" you write that the plugin "[...] ensure that one element of the DNS names list matches the principal name". Shouldn't the plugin validate *all* DNS names and verify that the principal is allowed to request a cert for all fields in SAN? Are there plans for any other SAN types? IP address or other oddball types like MS UPN? 3) Should FreeIPA deprecate cert request without SAN or at least warn the user? IMHO it makes sense to deprecate CN only cert requests. I'd mark it as deprecated over at least a major release in order to handle older versions that may still make requests without a SAN. 4) update "Issue New Certificate for Host" dialog and documentation The web UI has an update "Issue New Certificate for Host" dialog which explains how to create a CSR with certutil. This dialog should be updated to explain how to add a SAN DNS field. The option for SAN DNS is '-8 fqdn' or '--extSAN dns:fqdn', e.g. Create a CSR with subject CN=,O=, for example: # certutil -R -d -a -g -s 'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' rob -- 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] V4/RFC 2818 review
Hi Fraser, and now to the review of your design doc for RFC 2818-compliant subject alternative names in certs, http://www.freeipa.org/page/V4/RFC_2818_certificate_compliance 1) RFC 2818 vs. RFC 6125 First I like to address a more general topic. Your design mentions RFC 6125 shortly. IMHO RFC 6125 supersedes 2818 for CN/SAN hostname verification and we should follow the rules in RFC 6125, whenever 2818 lacks specification or there is a conflict between both RFCs. I can tell you some horror stories from Python's ssl module related to both RFCs. https://tools.ietf.org/html/rfc2818, HTTP Over TLS https://tools.ietf.org/html/rfc6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) As far as I'm familiar with RFC 6125, your proposal doesn't conflict with the more modern RFC. It also makes sense to name the design after the RFC, which has deprecated CN. I still like to check your design against RFC 6125. Fraser, do you agree? 2) SAN validation in ipa cert-request In the paragraph "ipa cert-request changes" you write that the plugin "[...] ensure that one element of the DNS names list matches the principal name". Shouldn't the plugin validate *all* DNS names and verify that the principal is allowed to request a cert for all fields in SAN? 3) Should FreeIPA deprecate cert request without SAN or at least warn the user? IMHO it makes sense to deprecate CN only cert requests. 4) update "Issue New Certificate for Host" dialog and documentation The web UI has an update "Issue New Certificate for Host" dialog which explains how to create a CSR with certutil. This dialog should be updated to explain how to add a SAN DNS field. The option for SAN DNS is '-8 fqdn' or '--extSAN dns:fqdn', e.g. Create a CSR with subject CN=,O=, for example: # certutil -R -d -a -g -s 'CN=client1.ipa.example,O=IPA.EXAMPLE' -8 'client1.ipa.example' Christian signature.asc Description: OpenPGP digital signature -- 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
