3A: Issuing the Campus Certificate: What are the steps?

Why isn&#t this section done?

There are two reasons for this, but the primary one is that time ran out. Here are some of the questions that will be answered. Input and volunteers to write this up and generate more questions are solicited.

1. What do I do first?

2. What decisions do I have to make for my campus certificate profile?

The HE-PKI TAG group has greatly simplified the task of determining the campus certificate profile. See the other sections for the generic higher education PKI-Lite certificate profile. Some of the decisions that a campus must make are as follows:

• Choose a name for the campus CA.
• Decide upon the validity length of the campus certificate
• Decide on the default validity length of any issued certificates.
• Decide on any extensions to be included in the certificates.

3. I am clueless about extensions. Which ones are recommended for the pilot?

4. What FERPA issues, if any, do I need to be concerned about when selecting extensions?

5. Can I use the rudimentary Higher Ed certificate policy for my campus implementation for the pilot?

Yes, you can use the rudimentary, Higher Ed Certificate Policy. It was developed by the hepki-tag and hepki-pag groups in an effort to create a document that is easy to adopt for low level of assurance uses. This pilot project is actually what it was written for and PKI Lite is exactly the right use for the rudimentary policy. The current version is located at: https://middleware.internet2.edu/hepki-tag/pki-lite/pkilite-policy-current.doc

(A version as of the printing of this guide is formatted and included in this guide as well)

6. Where is the generic CPS for the pilot?

This is being drafted by Jeff Schiller.

7. Describe a sample key generation ceremony for the Campus certificate.

To be done.

8. How do I apply for the CREN CA to sign my campus CA public key?

This is at the CREN site at https://www.cren.net.

Top

Please send comments/suggestions to cren@cren.net

CREN Strategic and Practical FAQ – Certificate Authorities

3B: Having my campus ca key signed by the CREN CA: What are the Steps?

This document provides background the process of having the CREN CA sign a campus key. It does not replace the CPS or Step-by-Step guide in any way.

1. How many people will this involve?

Three people from your institution must be involved. The person who is listed as the official CREN member representative completes the application. The Certificate Authority Executive Officer (CAEO) approves and signs the application. The Institution Certificate Authority Technical Contact (ICATC) sends the Certificate Signing Request (CSR) to CREN and will accept the campus certificate back after signing.

Three people from CREN will also be involved. Your primary communications will be with the Administrative contact at CREN and this is whom you should call for questions and problems. The CREN Registration Technical Contact will sign the campus CA key. The CREN Monitor will oversee the process.

2. How much time will this take?

The most time-consuming process is normally that of filling out the application and having it signed by the institution’s officer. After that, in a normal scenario, the remainder of the process can take as little as 2 weeks depending upon availability of the parties involved.

3. What is the cost?

There is no cost for the CREN signing of a campus ca key. It is a CREN membership service. If a non-member institution would like to have their CA signed by CREN, arrangements can be made for the non-member fee, which will be approximately equivalent to CREN membership fee.

4. What are the steps?

There are two main phases in getting a CREN signed certificate. The first includes applying and being validated for a certificate, and so that a secure mode of communication (such as PGP) can be established. The second phase is the Request, issuance and acceptance of the Institutional Certificate.

5. What can I expect in phase one?

Phase one is the ‘getting to know you stage‘. After the application has been filled out and submitted, the process begins. During this first phase, the CREN Admin will contact the three institutional representatives through the main telephone switchboard to verify that all of the individuals are known representatives of the institution. After the application is approved, the CREN Admin contacts the campus Technical Contact to establish secure communication via PGP and for the intro to the CREN technical contact. This ensures that all parties can communicate securely.

6. What will I need to know for phase two?

At the start of the second phase, the technical contact from your institution must issues a request for an institutional certificate via signed email to the Registration Contact. The email must include the following information:

1. Message requesting that CREN sign the campus certificate
2. Name of the institution in the following X.500 format: /c=Country/sp=State/o=Institution Name Spelled Out. Note: the DC naming may want to be used. See the certificate profile from HEPKI.
3. The institution’s public key.
4. A pointer to the CREN Certification Practices Statement https://www.cren.net/crenca/docs/cren_practices.doc

The CREN Technical Contact verifies the completeness and correctness of the request, and if it is valid, signs the certificate with the CREN CA key and sends it to the institution’s technical contact for acceptance.

The technical contact must then send an email to CREN’s Registration Contact acknowledging the validity of the certificate and accepting it on behalf of the institution.

Once this is done, the certificate will be added to the CREN repository, and institutions issue certificates with the CREN CA signature as the trusted third party, verifying that certificates issued do indeed originate from the campus ca.

Top
Please send comments/suggestions to cren@cren.net

CREN Strategic and Practical FAQ – CA Launching

3C: PGP: Pretty Good Privacy

1. What is PGP?

Pretty Good Privacy was originally developed by Phillip Zimmerman to provide a means of secure communication in an insecure electronic environment. "Pretty Good" is an understatement. The framework that it is based on, the PKI (Public Key Infrastructure) and its encryption standards (such as Diffie-Helman or RSA algorithms of varying strengths) have been subjected to rigorous cryptanalysis.

PGP has since grown into a more versatile application under the direction of its current owner, Network Associates (www.nai.com). Until the most recent release PGP has been completely open source, allowing anyone to review the code and suggest improvements.

2. Why Do I Want to Use PGP?

PGP is another security tool similar to digital certificates. One advantage of PGP is that individuals and small groups can begin using PGP for securing their email with little overhead. At CREN, we use PGP to set up a secure communication channel with institutions applying to have the CREN CA sign their institutional certificate.

Part of the process is that a validated Technical Contact send the official CSR Certificate Signing Request) to the CREN contact. PGP is used to establish the secure communication channel that supports this part of the application process. It is also important that the Technical contact retain this "out-of-band" communication channel for communications.

Getting PGP is easy. Here are the ways to do this.

The freeware version of PGP can be downloaded from any of the following sites:

From MIT:
https://web.mit.edu/network/pgp.html
(Windows, Macintosh, AIX/HP-UX/Linux/Solaris)

PGP international:
https://www.pgpi.org
(Many versions, with translations into many languages, PGP news.)

3. How does PGP work?

The first step in using PGP after installing the software onto your systems, is to generate a key for yourself. In generating a key, the software generates a key pair. These are simply text files that look like gibberish to a human. The keys can be created at various levels of strength, such as 512, 1024, or 2048 bit strengths. The higher the number, the stronger the encryption values are of the key. One key of the pair is the Private key – this key should always be kept safe and never given to anyone. The other key is the public key – this key should be given to as many people as possible.

4. What are the uses of PGP?

The most commonly used aspect of PGP is the signing and encryption of email or files. "Signing" a document is a way of verifying the integrity of the original work. The steps that PGP implements are as follows:

1. Makes a digest or "hash" of the file or email. A hash is an algorithm that produces (theoretically) a unique output (the hash) from a given input (the message).
2. Adds the hash to the end of the message.
3. When someone wants to verify that the message has not been modified, they run the hash algorithm on the message and compare it to the hash at the end of the message. If the signatures match, the message has not been altered.

This is demonstrated in the following example:

The hash algorithm: take every third letter of the message (ignore punctuation), and convert the letter to a number (a=1, b=2…z=26). Add the numbers together.

The message: Hello, This is a sample message to demonstrate signatures.

The hash algorithm in progress:

Hello, This is a sample message to demonstrate signatures.
12 +20+19 + 1 +13 +5 +19 +7 +15 +13+19 +1 +19+14+21+19 = 217
The message after adding the hash:
Hello, This is a sample message to demonstrate signatures.
Hash value: 217

If the message is altered, the hash value will not be the same.
Altered message:
Hello, This is an altered message to demonstrate signatures. - Creates a new hash:
Hello, This is an altered message to demonstrate signatures.
12 +20+19 +1 +12+18 +13+19 +5 +4+ 15 +20 +20 +9 +1 +18 = 206
Since the hashes are not equal, the message has been altered.

Actual hashing algorithms are much more complex. Additionally, the hashing algorithm is used in conjunction with the user’s private key in such a way that the signature is unique. That is, if different people (thus different private keys) signed the same email, the signatures would be different. Then the public key of the key pair is used to compare the hash created by the private key, and if the hashes match, then two things are assured: 1) The message has not been modified since signing and 2) the signature was not forged.

5. How is encryption used with digital signatures?

Encryption is a method of changing plaintext (text that is readable by humans) into ciphertext (text that is meaningless to humans). There are many different ways of encryption, some stronger than others. Two main categories of encryption are symmetric and asymmetric. In symmetric cryptography, the same key that encrypts a file also decrypts it. In asymmetric cryptography, which is what PGP uses, one key (the public key) encrypts the file, and the other key (the private key) decrypts it. So, if user A wants to send an encrypted message to user B, user A would first obtain user B’s public key. This is possible because public keys are meant to be widely distributed. Then user A encrypts the message using user B’s public key. The encrypted message can now only be decrypted with B’s private key, which only he possesses. Not even user A, who wrote the message, can decrypt what he has encrypted, because he does not possess user B’s private key. This ensures that the message is unreadable by anyone other than user A.

Encryption and signing are often combined. In this scenario, user A would use user B’s public key to encrypt the message, then use his own private key to sign the message. This will ensure that no one but user B can read the message, and when user B receives it, he can be assured that the message was not altered. To read the message, user B would first use user A’s public key to verify that the signature matches. Then user B would use his private key to decrypt the message that user A wrote.

For more information on PGP, visit www.pgp.com.

Top
Please send comments/suggestions to cren@cren.net