Hide Forgot
(Procedure 3.1) Either provide complete documentation on CA and cert creation or suggest user do so on their own (3.1) Clarify why the recommendation of 2 different CA's (in the Important block)? (Procedure 3.2) Suggest moving default qpid directory away from /tmp Minimize requirement for root account where possible (3.3) Remove this section, all it says is read sec 12.
Another one: (3.2) (answers.sample) example command syntax does not include "--answers"
(In reply to comment #0) > (Procedure 3.1) Either provide complete documentation on CA > and cert creation or suggest user do so on their own Jay and I have discussed this. We don't want to include full documentation for CA and certs, as it's outside the scope of the document. However, we felt it was necessary to include some guidance with regard to certs specifically for RHUI. I'm not sure that there's a happy balance in here, other than what we already have. If you feel a note is worthwhile, though, feel free to suggest wording. > > (3.1) Clarify why the recommendation of 2 different CA's (in the Important > block)? I don't know the background behind this recommendation. Jay? > > (Procedure 3.2) Suggest moving default qpid directory away from /tmp > > Minimize requirement for root account where possible This is an engineering change, not a documentation one. > > (3.3) Remove this section, all it says is read sec 12. It is there as a cross-reference, as readers will frequently look to the installation chapter for this information, even though it logically belongs at the end of the book, not the beginning.
>> >> (3.1) Clarify why the recommendation of 2 different CA's (in the Important >> block)? > > I don't know the background behind this recommendation. Jay? This is a tricky one to explain. I feel like most security-related things are like that; there's a certain amount of gut-feeling that goes into them. There's also not a single reason that leads you to think "Oh ya, I'd totally want to do it this way." Let me throw out a few ideas and Lana can figure out what she wants to use. Typically, web site SSL certificates are signed by one of the big name trusted sources like VeriSign. To be more precise, a company buys a CA that is down the chain from VeriSign's root CA. From there, practices vary wildly, but the idea is that you set up a chain of trust to prevent just how badly screwed you are if one of the CAs gets compromised. So say Jdob Corp. buys a CA from VeriSign. I'd then create my own child CAs depending on... well, a ton of factors: expected usage, organizational, level of OCD in the security team, etc. For now, let's just say I create A, B, and C from the Jdob Corp. root CA. For some reason, A gets compromised. That means any SSL certificates signed by A are now suspect. Thankfully, any SSL certificates signed by B and C are both safe. So the amount of panic and running around I have to do to minimize the impact is restricted to the certificates signed by A. The purpose of going to VeriSign in the first place is that they are trusted by everyone. So really particular clients will follow up the chain of trust to make sure Jdob Corp eventually leads back to a trusted third party (rather than taking Jdob Corp at its word). But that's not required. It's also a bit more relevant in the case where Jdob Corp was, say, an online store front. In our case, the whole RHUI infrastructure is a bit more self-contained and opaque to the user. So if the RHUI deployer doesn't want to go through the hassle or cost of getting a VeriSign child CA, it's probably not a deal breaker. The other aspect is that the entitlement signing CA and its private key are used by RHUI Manager. Typically, CA private keys are stored in a vault somewhere. For example, Red Hat has a hard copy print out of theirs split across two sheets of paper, both of which are stored in separate lock boxes. True story, I forget where I heard it, but it shows just how important that key is. It's basically the identity of the company that bought it. That's fine for the rare times you generate a new web site SSL certificate, but entitlement certificates are much more fluid. Since that key is needed on a much more regular basis, it'd put the web site SSL certificates at risk as well. Not sure how much of that is useful or helps, but when talking to the docs team I'd rather explain the situation and let you guys use your skills to determine how much is relevant. Ping me if you have any more questions. >> >> (Procedure 3.2) Suggest moving default qpid directory away from /tmp >> >> Minimize requirement for root account where possible > > This is an engineering change, not a documentation one. Root is not required to write to /tmp. In this case, that's exactly what the files are: temporary for use in the installation and then they go away.
(In reply to comment #3) > >> > >> (3.1) Clarify why the recommendation of 2 different CA's (in the Important > >> block)? > > > > I don't know the background behind this recommendation. Jay? > > This is a tricky one to explain. I feel like most security-related things are > like that; there's a certain amount of gut-feeling that goes into them. There's > also not a single reason that leads you to think "Oh ya, I'd totally want to do > it this way." Let me throw out a few ideas and Lana can figure out what she > wants to use. > > Typically, web site SSL certificates are signed by one of the big name trusted > sources like VeriSign. To be more precise, a company buys a CA that is down the > chain from VeriSign's root CA. From there, practices vary wildly, but the idea > is that you set up a chain of trust to prevent just how badly screwed you are > if one of the CAs gets compromised. > > So say Jdob Corp. buys a CA from VeriSign. I'd then create my own child CAs > depending on... well, a ton of factors: expected usage, organizational, level > of OCD in the security team, etc. For now, let's just say I create A, B, and C > from the Jdob Corp. root CA. > > For some reason, A gets compromised. That means any SSL certificates signed by > A are now suspect. Thankfully, any SSL certificates signed by B and C are both > safe. So the amount of panic and running around I have to do to minimize the > impact is restricted to the certificates signed by A. > > The purpose of going to VeriSign in the first place is that they are trusted by > everyone. So really particular clients will follow up the chain of trust to > make sure Jdob Corp eventually leads back to a trusted third party (rather than > taking Jdob Corp at its word). > > But that's not required. It's also a bit more relevant in the case where Jdob > Corp was, say, an online store front. In our case, the whole RHUI > infrastructure is a bit more self-contained and opaque to the user. So if the > RHUI deployer doesn't want to go through the hassle or cost of getting a > VeriSign child CA, it's probably not a deal breaker. > > The other aspect is that the entitlement signing CA and its private key are > used by RHUI Manager. Typically, CA private keys are stored in a vault > somewhere. For example, Red Hat has a hard copy print out of theirs split > across two sheets of paper, both of which are stored in separate lock boxes. > True story, I forget where I heard it, but it shows just how important that key > is. It's basically the identity of the company that bought it. > > That's fine for the rare times you generate a new web site SSL certificate, but > entitlement certificates are much more fluid. Since that key is needed on a > much more regular basis, it'd put the web site SSL certificates at risk as > well. > > Not sure how much of that is useful or helps, but when talking to the docs team > I'd rather explain the situation and let you guys use your skills to determine > how much is relevant. Ping me if you have any more questions. Thanks for the explanation, it helps a lot! I've added a short explanation: <important> <title>Important</title> <para> It is recommended that you sign the SSL certificates and the client entitlement certificates with different certificate authorities (CAs), in order to help mitigate any security risk should one of the certificates become compromised. However, if you choose to use the same CA to sign both certificates, ensure the serial numbers for all server-side SSL certificates are below <parameter>0100</parameter> to avoid conflicts within &RHUI;. </para> </important> I don't think the purpose of this document requires us to go in depth with security practises. Considering our audience is primarily sysadmins, we can assume a certain level of pre-existing security knowledge. Explaining that we recommend two CAs in order to mitigate security risk gives them enough information that they could then go and research the topic further to make an informed decision. Happy to tweak wording here, though, if you would prefer something different. Revision 2-16. Karthik, please raise bugs for engineering as requested in Comment 3. LKB
Released in RHUI 2.0.2