Re: [Freeipa-devel] [PATCH] 306 selinux policy for assets
On Tue, 2009-11-03 at 15:29 -0500, Rob Crittenden wrote: This adds some SELinux policy for /var/cache/ipa/assets and /var/cache/ipa/sessions. I've also disabled Indexing on /ipa-assets and removed the deprecated IPADebug option. This effectively removes ipa_webgui too. I've left the directory there for now (mostly for reference). rob ack. I pushed this and my 026 patch to master. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On 11/04/09 16:16, Nalin Dahyabhai wrote: On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote: Alternatively you can specify which host(s) can request a certificate for a given service. Use the service-add-member command to add hosts that can request certs for it. That sounds reasonable. Is this new post-1.9.0? I can add members to various groups, but there's no service-add-member command yet. A couple of tidbits: - In 1.9.0 we'll issue a certificate for any subject requested. dogtag has a fix that we will be able to use once it's released that will let us pull the CN from the request and use just that with the subject and use a fixed value for the rest. That sounds good -- the default request subject is just 'CN=hostname' unless it's told different. - The management framework doesn't do anything to the CSR right now, it literally just passes it onto the CA for processing. - The whole ugly client IP thing has been ripped out post 1.9.0. - I still compare the hostname in the subject with the hostname of the service. This is unfortunately currently broken in python 2.4-based systems. If we're requiring that every certificate has an associated principal name, then ensuring it agrees with the hostname in the subject field makes a lot of sense. I'd kind of like to see both a dnsName and a Kerberos principal name added to the subjectAltName fields in the issued certificate, but that's as much because we can as anything else. - I'm not opposed to including more stuff into the CSR itself we just need to be sure the average admin who doesn't want to use certmonger can still make a request too. NSS's certutil can trivially add dns and email subjectAltName (SAN) values and extendedKeyUsage (EKU) values. I don't see a flag for adding a Kerberos principal name. OpenSSL's req command doesn't do most of that by default, but the configuration file can be used to tell it to do any of that. It could be scripted, for sure. Right now the bar is pretty low to understanding what is required IMHO with the exception of pasting in the ugly one-line CSR :-( Yeah, it took me a while to figure out that that was how we were supposed to pass it in. Passing entire CSR as a parameter to ipa command could avoided if XML-RPC framework would provide pre and post processing callbacks on the client side. Parameters could be used to describe CSR (instead of passing entire CSR), pre-processing callback could generate CSR based on provided description, then XML-RPC call could submit generated CSR and finally post-processing callback could properly place obtained certificate. Regards, Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] GeneralizedTime v.s datetime.datetime in XMLRPC
Rob, is it a big problem to do it right? It seems like we are cutting corners a bit and I understand why but my general experience tells me that these things are just time bombs waiting to explode. Do we really want to leave them there or we should clean it up before we release? I know it is more work but these things just do not smell right... Is there any argument against following XMLRPC standards? How much would it take to make the changes and who would be the right person to do them? John Dennis wrote: On 11/04/2009 03:52 PM, Rob Crittenden wrote: John Dennis wrote: In parameters.py we define a GeneralizedTime object to be used as an XMLRPC parameter. Why? GeneralizedTime isn't defined as an XML-RPC paramter, just an IPA one and XML-RPC just comes along for the ride. We only needed support for RFC 4517. Exactly, that's the problem. GeneralizedTime is not known to anybody who speaks XMLRPC, but iso8601 is known to anybody who does speak XMLRPC, and since GeneralizedTime is a subset of iso8601 anybody requiring GeneralizeTime can convert to GeneralizedTime from iso8601. Whenever possible we should stay within the definitions of the specifications, since XMLRPC already has a type for iso8601 there is no need to introduce a private type into XMLRPC which would be known only to select parties. * XMLRPC defines the dateTime.iso8601 parameter value type for passing date/time information * Python has good support for date/time processing in it's datetime module * Python's xmlrpclib supports both xmlrpclib.DateTime and datetime.datetime objects. * Python's xmlrpclib can be configured to use datetime.datetime objects intead of xmlrpclib.DateTime objects if you pass use_datetime=True when invoking xmlrpclib.loads(), however we don't do that. Why? Never needed dates. This has nothing to do with needing dates, rather it's an issue of which date/time object xmlrpclib will use. xmlrpclib apparently was written prior to the introduction of datetime.datetime so it created its own date/time type called DateTime. The introduction of datetime.datetime should supersede xmlrpclib.DateTime but it was left as the default for backwards compatibility. We have no need for that backward compatibility, we should be representing date/time information in Python's native datetime.datetime object. * ISO 8601 is an internet standard for passing date time information between cooperating network entities. However GeneralizedTime is only valid in a subset of binary protocols (primarily LDAP and PKI) And it is LDAP we end up speaking. No, our API is not speaking native LDAP, we're providing an abstraction layer over LDAP. Given that ISO 8601 is the preferred standard, that's it is directly supported by XMLRPC, is compatible with datetime.datetime and the fact datetime.datetime has excellent support in Python shouldn't we be using datetime.datetime for all our date/time information and only convert to and from GeneralizedTime for the subset of interfaces which require GeneralizedTime? This could always be revisited but at the time we didn't need full-blown support and in fact don't want timezone information. datetime.datetime can be use with and without timezone information. We probably want to establish a convention that all date/time information is exchanged in UTC (effectively the same thing as omitting timezone information, if that's what you meant). datetime.datetime handles UTC trivially. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
Andrew Wnuk wrote: On 11/04/09 16:16, Nalin Dahyabhai wrote: On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote: Alternatively you can specify which host(s) can request a certificate for a given service. Use the service-add-member command to add hosts that can request certs for it. That sounds reasonable. Is this new post-1.9.0? I can add members to various groups, but there's no service-add-member command yet. A couple of tidbits: - In 1.9.0 we'll issue a certificate for any subject requested. dogtag has a fix that we will be able to use once it's released that will let us pull the CN from the request and use just that with the subject and use a fixed value for the rest. That sounds good -- the default request subject is just 'CN=hostname' unless it's told different. - The management framework doesn't do anything to the CSR right now, it literally just passes it onto the CA for processing. - The whole ugly client IP thing has been ripped out post 1.9.0. - I still compare the hostname in the subject with the hostname of the service. This is unfortunately currently broken in python 2.4-based systems. If we're requiring that every certificate has an associated principal name, then ensuring it agrees with the hostname in the subject field makes a lot of sense. I'd kind of like to see both a dnsName and a Kerberos principal name added to the subjectAltName fields in the issued certificate, but that's as much because we can as anything else. - I'm not opposed to including more stuff into the CSR itself we just need to be sure the average admin who doesn't want to use certmonger can still make a request too. NSS's certutil can trivially add dns and email subjectAltName (SAN) values and extendedKeyUsage (EKU) values. I don't see a flag for adding a Kerberos principal name. OpenSSL's req command doesn't do most of that by default, but the configuration file can be used to tell it to do any of that. It could be scripted, for sure. Right now the bar is pretty low to understanding what is required IMHO with the exception of pasting in the ugly one-line CSR :-( Yeah, it took me a while to figure out that that was how we were supposed to pass it in. Passing entire CSR as a parameter to ipa command could avoided if XML-RPC framework would provide pre and post processing callbacks on the client side. Parameters could be used to describe CSR (instead of passing entire CSR), pre-processing callback could generate CSR based on provided description, then XML-RPC call could submit generated CSR and finally post-processing callback could properly place obtained certificate. I though we talked about these callbacks a year ago and planned to do them. Was this work ever finished? Regards, Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
