The time has come to embark on a new project. Although a different project on its own, it is closely related to the P3 project I was working on previously. The P3 application authenticates users through client certificates, but how and where are they gonna get the certificates? This is where this project comes in. From here on, I would be referring to this project as 4k.
The project was already in development since 2 years ago, done by previous interns. Things need to change now, however, but at least there’s some code that already implements some of the basic functionality, such as creating a certificate. The C++ library being used is the Botan C++ library. As of now, the application would need to interface with a WordPress e-commerce website. Using the WooCommerce plugin, the web store will be responsible for selling the certificates to all kinds of users, be it hobbyists, students or even industrial professionals. The 4k project would be a backend application, that listens for incoming webhook requests from the WooCommerce store, which is very similar to the project I did for my internship, i.e the Competition Registration System (CRS). There would definitely be a few common things shared with CRS, therefore Dr Shawn expects this project to be rather convenient for me, since I already have some experience integrating WooCommerce with CRS.
The main difference this time around, is that we would be using the WooCommerce Subscription extension, which enables us to sell the products with recurring payments at specific time intervals (e.g: 1 month, 6 months, 1 year, etc). This is suitable for selling certificates as each certificate would have a validity period. Thus, the validity period for a particular certificate is determined by the type of subscription the users are paying for. A certificate would be created for the user in 4k’s backend after he or she has make the necessary payments and the order is COMPLETED in the store. 4k backend would also subsequently send an email to the user, either with the certificate attached or put a download link to the certificate.
The Certificate Hierarchy
However, not all certificates created would be the same. Dr Shawn’s target users involves ordinary individuals like hobbyists, and organizations like schools or universities as well as other businesses. There would be a hierarchy of certificates, where a parent and children relationship would be established. The hierarchy starts off with a root certificate, followed by intermediary certificates and finally the end entity certificates, which are the client certificates to be used by the users.
The root certificate would be the root Certificate Authority (CA), whereby it issues the intermediary certificates. Each intermediary certificate would contain the root certificate’s signature, as proof that the root certificate is the issuer. Then, an intermediary certificate would act as an intermediary CA, in which it signs newly created certificates with its signature, and is thus identified as the issuer of the new certificate as well. In our case, the intermediary CAs would correspond to the class of the users, for example, an Individuals CA would be responsible for issuing certificates for individual users (i.e hobbyists, or professionals), the Schools CA would be responsible for issuing certificates to various schools each, and so forth.
The hierarchy would actually get more complicated than that. Each organization (i.e a school or a company) would have its own intermediary CA certificate, so that its members (students or employees) would receive certificates that is issued by their corresponding CA. As an example, Monash University would receive a certificate issued by the Schools CA, and that certificate would act as a CA for issuing client certificates to its students. All in all, the hierarchy is necessary for authentication purposes. When the user presents the certificate to the application, the certificate needs to be validated, and this is done by verifying each certificate in its certificate chain. This is known as establishing a chain of trust. When traversing from the client certificate to its parent certificate and so forth, at the end the root certificate must be our root certificate. This would show that the certificate is indeed issued by our certificate hierarchy.
With that being said, we would need to structure our products in the store in a way in the simplest and most effective way possible. It has yet to be confirmed how this is gonna be done, but it would be much clearer later on. I wish to talk more about how this project would work, however, I’ll save it for the next blog.
0 Comments