I have never trusted public/private keys, simply because how private can you make a key private. Government level security agencies can simply say give us your private keys and BOOM nothing is secure. Thanks for the video.
Hi, Frank. You bring up a fairly complicated but important topic. I believe we can trust private keys (as a technology). There are risks related to the security of private keys, however, I believe those risks exist with any technology, and even with data itself. For example, even if I could prevent a government agency from getting access to the TLS private key(s) I use to protect my data, the government can simple tell me to give them the data. If I store the private key(s) in a FIPS hardware device, I may be able to protect them better but then the thing I need to protect is the credentials I use to access the device. I’m providing a bit of an abbreviated response but hope that helps. Thanks a bunch for your comment.
Sorry for the slow response. The actual CA at CA1 can’t be called an RA because it is signing certificates. RAs do not sign certs. However, the RA function is often performed as part of the CA organization. For example, if CA1, Inc. is running a CA, they will perform the RA function to validate that all requesters are authorized to request certs for their domains. CA1, Inc. acts as both the CA and RA. The most common case where the RA function is separate is when a corporation is requesting certs for their sub domains. For example, Corp1 goes to CA1, Inc. and says they want to issue certs for a bunch of severs under corp1.com. CA1 acts as the RA to confirm that Corp1 owns corp1.com. Then, if a user at Corp1 requests a cert for finance.corp1.com, an admin at Corp1 will review and approve the request in the CA1 console. In this case, CA1, Inc is the CA and Corp1 is the RA. Hope that helps.
@@PaulTurnerChannel Thanks Paul. The drawing in the RFC stated that the RA "publishes cert" so I assumed wrongly its function or intent. All clear now. I'm studying ISAKMP now for CCNP and came upon your excellent videos (which helped on the certificate aspect). Reall appreciate your time with this. Do you know by chance where I can get more details on COOKIES in IKEv1 Phase 1? Way off topic but at the end of Phase 1 IKEv1 there's SKEYID and SKEYID_e,d,a. It's generated using DH(secret) and then it says CKY_I and CKY_R (cookie initiator and responder). I can't seem to find an "English" explanation on what the cookies consist of lol.
Hi, Umer. I'm not aware of a way to attach the file to UA-cam video for download. Since this is technically Venafi content, I'm checking with them to see how it can be made available. I'm glad that it is useful enough that you'd like the PDF. Thanks for reaching out.
Umer, sorry for the delay in getting back to you. The PDF has been uploaded to following address (updated with the newer Venafi PPT template :): www.venafi.com/resource/pki-bootcamp-basics-of-certificate-issuance-presentation Please confirm that you are able to access it.
So far, I have not seen a single video that explains so far up the trust chain. Thanks!
I’m glad you found it helpful!
Echo what everyone else has mentioned here . Extremely useful . Thanks much Paul for your time in creating these videos
Thank you for taking the time to give your positive feedback, Chandan. I really appreciate it.
Excellent explanation, clear, detailed, and covering many open questions that had been bothering me for a long time.
Thank you very much for the feedback, Jose. I really appreciate it.
Explained very well, loved your way of teaching .. please add more videos. Appreciate for your effort Paul.
Thanks for taking the time to provide your feedback, Indranil. I hope yo do a few more videos soon.
Excellent master for PKI
Glad you liked it, Jesus. Thanks for the feedback.
Fantastic work Paul.. really appreciated
I'm glad you like it, Irfan. Thanks for taking the time to write a comment!
Thank you so much. Great explanation.
I have never trusted public/private keys, simply because how private can you make a key private. Government level security agencies can simply say give us your private keys and BOOM nothing is secure. Thanks for the video.
Hi, Frank. You bring up a fairly complicated but important topic. I believe we can trust private keys (as a technology). There are risks related to the security of private keys, however, I believe those risks exist with any technology, and even with data itself. For example, even if I could prevent a government agency from getting access to the TLS private key(s) I use to protect my data, the government can simple tell me to give them the data. If I store the private key(s) in a FIPS hardware device, I may be able to protect them better but then the thing I need to protect is the credentials I use to access the device. I’m providing a bit of an abbreviated response but hope that helps. Thanks a bunch for your comment.
Hi Paul and everyone. I was looking at the X509 RFC (5280) and was wondering if your CA1 can be called the Registration Authority?
Sorry for the slow response. The actual CA at CA1 can’t be called an RA because it is signing certificates. RAs do not sign certs. However, the RA function is often performed as part of the CA organization. For example, if CA1, Inc. is running a CA, they will perform the RA function to validate that all requesters are authorized to request certs for their domains. CA1, Inc. acts as both the CA and RA.
The most common case where the RA function is separate is when a corporation is requesting certs for their sub domains. For example, Corp1 goes to CA1, Inc. and says they want to issue certs for a bunch of severs under corp1.com. CA1 acts as the RA to confirm that Corp1 owns corp1.com. Then, if a user at Corp1 requests a cert for finance.corp1.com, an admin at Corp1 will review and approve the request in the CA1 console. In this case, CA1, Inc is the CA and Corp1 is the RA. Hope that helps.
@@PaulTurnerChannel Thanks Paul. The drawing in the RFC stated that the RA "publishes cert" so I assumed wrongly its function or intent. All clear now. I'm studying ISAKMP now for CCNP and came upon your excellent videos (which helped on the certificate aspect). Reall appreciate your time with this.
Do you know by chance where I can get more details on COOKIES in IKEv1 Phase 1? Way off topic but at the end of Phase 1 IKEv1 there's SKEYID and SKEYID_e,d,a. It's generated using DH(secret) and then it says CKY_I and CKY_R (cookie initiator and responder). I can't seem to find an "English" explanation on what the cookies consist of lol.
THANK YOU!!!!! thank you very much!
Thank you for the feedback, Mauro.
thank you for your effort, really cool; how has you made the animations?
Thanks for your feedback. I use PowerPoint.
Paul Turner nice than we have the same Approach to explain thinge, but you habe the cooler pp
very well explained, Paul!
Thanks for your feedback
Thanks again Paul..well explained
Thank you very much, Abhishek. I hope to get more videos out soon (been too busy with the day job :)
Could you share the PDf of the slide
Hi, Umer. I'm not aware of a way to attach the file to UA-cam video for download. Since this is technically Venafi content, I'm checking with them to see how it can be made available. I'm glad that it is useful enough that you'd like the PDF. Thanks for reaching out.
Umer, sorry for the delay in getting back to you. The PDF has been uploaded to following address (updated with the newer Venafi PPT template :):
www.venafi.com/resource/pki-bootcamp-basics-of-certificate-issuance-presentation
Please confirm that you are able to access it.
@@PaulTurnerChannel thanks for sharing the slides , but the access to it is denied via your link :(
Umer, the slides were shared with you three years ago. I am no longer with Venafi and I assume they’ve taken that link down. Sorry.
that's fine, no matter.
its a great series videos by the way
3/13/37 I see what you did there
;-). Thanks!
Guys with guns? Please...
Haha. I guess I do have a flair for the dramatic every once in a while. Good catch 😀
@@PaulTurnerChannel great vid though, thanks
Thanks, Chris. I’m glad you liked it.