RFC 1875

UNINETT PCA Policy Statements 🎀

Okay bestie, this is RFC 1875 💖 and it's called "UNINETT PCA Policy Statements." It was written by N. Berge from the Norwegian Computing Center, it's dated December 1995, and it's categorised as Informational 📚. The header doesn't list anything it obsoletes or updates 🙈.

Status of this Memo 🌈

This memo gives info to the Internet community. It does not specify an Internet standard of any kind 🙅‍♀️. Distribution of this memo is unlimited 🦋.

Table of Contents 📑

   1.   Introduction.......................................2
   2.   PCA Identity.......................................2
   3.   UNINETT - a brief overview.........................2
   4.   PCA Scope..........................................2
   4.1  The certification tree.............................3
   4.2  Use of Registration Authorities (RAs)..............3
   5.   PCA Security & Privacy.............................3
   5.1  Security requirements imposed on the PCA...........3
   5.2  Security requirements imposed on CAs...............4
   5.3  Security requirements imposed on RAs...............4
   5.4  Measures taken to protect the privacy of any
        information collected in the course of certifying
        CAs and (for CAs) users............................4
   6.   Certification Policy...............................5
   6.1  Policy and procedures when certifying CAs..........5
   6.2  Policy and procedures when certifying RAs..........5
   6.3  Policy and procedures when certifying users........5
   6.4  Validity interval for issued certificates..........6
   6.5  The CAs right to a DN and procedures to resolve DN
        conflicts..........................................6
   6.6  The users right to a DN and procedures to resolve
        DN conflicts.......................................6
   7.   Certificate Management.............................7
   8.   CRL Management.....................................7
   9.   Naming Conventions.................................8
   10.  Business Issues....................................9
   10.1 Legal agreement concerning CAs.....................9
   10.2 Legal agreement concerning RAs.....................9
   10.3 Fees...............................................9
   11.  Other..............................................9
   11.1 Distribution of software needed by CAs, RAs and
        users..............................................9
   12.  Security Considerations............................9
   13.  References........................................10
   14.  Author's Address..................................10

1. Introduction 💫

This doc tells you about the policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA) 💅. Its purpose is to help members of the Internet community figure out how much trust they can place in a certification path that includes a certificate issued by the UNINETT PCA 🔐. It also helps anyone who wants to set up a CA that the UNINETT PCA will certify ✨.

2. PCA Identity 🪪

Distinguished Name (DN): C=no, O=uninett, OU=pca 💜

The UNINETT PCA will be run by:

Norwegian Computing Center
Gaustadallien 23
P.O.Box 114 Blindern,
N-0314 Oslo, Norway

Here's who to contact:

Contact person:
Nils Harald Berge
Email: Nils.Harald.Berge@nr.no
Tel.: (+47) 22 85 25 00
Fax : (+47) 22 69 76 60

Duration: this policy is valid from Oct 1, 1995 to Jan 1, 1998 ⏳

Info about this PCA is available at: http://www.uninett.no/pca/ 🌸

3. UNINETT - a brief overview 🌐

UNINETT is a Limited Company (AS) that runs the Norwegian network for academics and research 🎓. It's incorporated under Norwegian law, and its company number is 968100211 🇳🇴.

More info is available from the UNINETT web server at: http://www.uninett.no/ ✨

4. PCA Scope 🎯

The scope of the UNINETT PCA is decided by UNINETT Policy. It will mostly certify CAs that run on behalf of legal entities like schools and companies 🏫.

4.1 The certification tree 🌳

The certification tree beneath the UNINETT PCA has three distinct entities: Certification Authorities (CAs), Registration Authorities (RAs) and users 👑. CAs are described in the PEM documents [1,2,3,4]. RAs are explained below 🙌.

There will be one CA per UNINETT member organization, and it can have sublevel CAs too 🧚. The CA MAY be run by the organization itself, or by the organization running the PCA for organizations that don't want to take on the responsibility themselves 🫶.

4.2 Use of Registration Authorities (RAs) 🪪

Since the CA might be located far away from the users, local authorities are needed for physical identification and authentication of users 🗺️. For security reasons, and to avoid an unnecessarily large number of CAs, these authorities are not allowed to issue certificates 🙅‍♀️.

A registration authority (RA) is an ordinary user. They're appointed by an organization or an organizational unit, trusted by a CA, and act as the point of contact for people who want to register as users, meaning people who want a certificate issued 💌. To avoid faked certification requests, users MUST send their self-signed certificate to an appropriate RA, and then physically visit the RA with proof of identity 🛂. If the user is properly authenticated, the RA forwards the self-signed certificate to the CA in a message signed by the RA ✅.

For bulk certification (see 5.3), the RA MUST physically verify the identity of the user before handing out the password for access to the user's private key 🔑.

A CA MAY appoint as many RAs as it wishes 🧑‍🤝‍🧑. The only difference between certifying an RA and certifying an ordinary user is that the RA (a person) MUST sign an agreement with the certifying CA, stating the obligation to follow the agreed procedures 📝.

5. PCA Security & Privacy 🔒

5.1 Security requirements imposed on the PCA 🔐

• The PCA will have its private key stored on a smartcard 💳.
• The PCA will be run on a dedicated workstation with no network connection. The workstation will be physically secured 🏰.
• Exchanging data between the PCA workstation and the rest of the world will be done using tapes or floppy discs 💾.
• The PCA RSA key pair will have a length of 1024 bits.
• Backups from the PCA workstation MUST be stored in at least one off site location. Backups MUST be physically secured 🧳.

5.2 Security requirements imposed on CAs that are to be certified 🛡️

• A CA MUST be run on a dedicated workstation with no network connection. The workstation MUST be physically secured 🏰.
• Exchanging data between the CA workstation and the rest of the world MUST be done using tapes or floppy discs 💾.
• The CA RSA key pair MUST have a minimum length of 1024 bits 🔑.

A security requirements document concerning CAs will be made available online, and it's expected to be obeyed 📄.

5.3 Security requirements imposed on RAs that are to be certified 🛡️

• RAs MUST use a work station, with remote login disabled. Use of X-terminal, terminal emulator etc. with processes running on a remote machine is strictly prohibited 🚫.
• The RA RSA key pair MUST have a minimum length of 512 bits 🔑.

🚨 Remote login stays off on RA workstations. No exceptions, bestie.

A security requirements document concerning RAs will be made available online, and it's expected to be obeyed 📄.

5.4 Measures taken to protect the privacy of any information collected in the course of certifying CAs and (for CAs) users. 🙈

CAs will not collect any security relevant information about users 🫣. In cases where CAs generate keys (and certificates) on behalf of users, all information about the user's private key will be securely deleted after the user has received it 🗑️. CAs will always generate their own key pairs, so no security relevant information will be collected by the PCA 💅.

All archived material about DNs for users will be stored on the CA workstations. These are physically protected and do not have any network connections 🔐✨.

7. Certificate management ✨

okay so bestie, UNINETT's X.500 service is where certificates for users inside UNINETT member organizations get stored 📂💖 Other users can use X.500 too if they have access to it. The certifying entity ALSO keeps every issued certificate in a local database, on top of the X.500 directory, so there are two copies. Iconic redundancy 🫶

If a CA doesn't have X.500 access, it MUST mail every issued certificate to the UNINETT PCA, and the PCA makes the X.500 entries on the CA's behalf. The PCA is basically the friend who does the upload for you 💅

There are two ways to request certificates: straight from the X.500 directory, or by querying a mail-responder service run by the UNINETT PCA 📬

The details on how certificates get mailed, and how to use the mail-responder, live at this WWW site: http://www.uninett.no/pca/ 🌸

8. CRL Management 🦋

Okay this section is giving "stay on schedule or else" 😭 Certificate Revocation Lists (CRLs) MUST be issued at least once a month, on a specified date, by CAs. The UNINETT X.500 service is used to publish CRLs. Same deal as before: if a CA can't reach X.500, the CRL MUST be mailed to the UNINETT PCA, who puts the X.500 entries in for them 📮

CRLs can be requested two ways too, either directly from the X.500 directory or through the mail-responder that the UNINETT PCA maintains 🧚

For the mailing details and how to use the mail-responder, check out http://www.uninett.no/pca/ 🍓

The UNINETT PCA keeps the CRL updated with revoked CA certificates, continually 🔄

Now the lowkey tea ☕ There is NO automatic distribution service for CRLs, so users have to go pull them themselves from X.500 or the mail-responder. Black lists are not supported right now 🙈 And the way new CRLs get announced is through appropriate news groups and information services 📢

9. Naming Conventions 🎀

Let's talk names, because this is where the vibes get very specific 💜

9.1 Naming conventions for CAs

CAs' DNs follow the conventions their organization already has. If the organization doesn't have any preferences, it SHOULD use this scheme:

C=<country>, O=<organization> [, OU=<organizational-unit>]

Country is the country code. Every Norwegian organization has C=no, for example 🇳🇴 Organization is the organization the CA represents, which is basically the scope the CA certifies users for. Organizational-unit is optional, and it's for when a big organization has more than one CA and needs to tell them apart 🏢

Example: the CA responsible for certifying UNINETT employees gets this DN: C=no, O=uninett ✨

9.2 Naming conventions for users

Users' DNs follow the conventions their organization already has too. If the organization doesn't have a preference, it SHOULD use this one:

C=<country>, O=<organization>, [OU=<organizational-unit>,]
CN=<personal name>

The personal name has to be unique for the user within their organization, and the organization's CA is responsible for making sure every certified user has a distinct personal name 🫶 Usually the personal name is the user's full name. Using OU is optional.

Example: if Per Olsen is an employee of UNINETT, he gets the DN C=no, O=uninett, CN=Per Olsen 💅

Also, the CA picks which users get certified as belonging to the organization. The PCA does NOT make that call 👑

10. Business Issues 💼

Okay the legal stuff, but make it cute 🧾

10.1 Legal agreements concerning CAs

If a CA wants to get certified by the UNINETT PCA, the CA will have to sign a legal agreement with the UNINETT PCA first. To get the agreement, you contact the UNINETT PCA 📝

10.2 Legal agreements concerning RAs

If an RA wants to be certified by a CA, a person representing the RA will have to sign a legal agreement with that CA ✍️ You can get the agreement from the appropriate CA, or straight from the UNINETT PCA. Each CA decides locally whether the RA gets certified, so it's the CA's call 🦋

10.3 Fees

The UNINETT PCA reserves the right to charge fees 💸 The fee structure is decided by UNINETT policy.

11. Other 🌈

11.1 Distribution of software needed by CAs, RAs and users

The software is based on the SecuDE-package from GMD Darmstadt, and it's free for non-commercial purposes 🎁 All software distributions SHOULD include a signature from the UNINETT PCA so you can verify the integrity of what you downloaded. Users, CAs, and RAs are expected to verify those signatures immediately after installation. Do not skip this step, bestie 😤

12. Security Considerations 🔐

Okay this one is short but it is SERIOUS 💀 Security issues are discussed throughout this memo. Like, everywhere. Read the whole thing 🙈

13. References 📚

• [1] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.
• [2] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, IAB IRTF PSRG, IETF PEM, BBN, February 1993.
• [3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, IAB IRTF PSRG, IETF PEM WG, TIS, February 1993.
• [4] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, RSA Laboratories, February 1993.

14. Author's Address 🧚‍♀️

Here's who wrote it, in case you want to reach out 💌

Nils Harald Berge
Norwegian Computing Center
Gaustadallien 23
P.O.Box 114 Blindern,
N-0314 Oslo, Norway

Phone: (+47) 22 85 25 00
Fax : (+47) 22 69 76 60
EMail: Nils.Harald.Berge@nr.no

That's the whole RFC, bestie! 🌈✨💖