ejbca-design.txt

JAVA做的J2EE下CA认证系统 基于EJB开发

This is an initial design document from the early days of ejbca, the very start...

IMPORTANT DESIGPARAMETERS
=========================
Modular to be able to change (through configuration) authentication machanism when certs are created, create certs in different ways (RSA, DSA), etc.

Modular for different signers, several CAs should be able to run on ONE server, with separate user databases, etc.

Flexible user interface for clients, browsers, PKIX, general PKCS10, own (EJB)API, batch-creating or one at a time.

Flexible formats that an application results in, PKCS7-certificate (ie), PEM, DER, PKCS12 etc.


Easy to install (right defaults).

Easy to setup and adminstrate (right defaults).


ROLES
=====

Sysadmin: installs and configures SW so that CA-admin can take over and configure CA

CA-admin: administrates rootCAs, CAs, subCAs, RAs, CA-admins, RA-admins

RA-admin: administrates end-entities, approves cert requests, generates end-entity keys/cert


USECASES
========

End-entity:
----------

1. End-entity registers with RA

2. End-entity authentizates to RA
	With nothing
	With password
	With previously issued certificate

3. End-entity gets cert through java-API.
	End-entity sends cert request
	End-entity receives cert reply
	End-entity does all in one step

4. End-entity gets cert from browser
	End-entity sends cert request
		Netscape4
		Netscape6
		IE5
	End-entity receives cert reply
		Netscape4
		Netscape6
		IE5
	End-entity does all in one step
		Netscape4
		Netscape6
		IE5
5. End-entity gets cert externally delivered
	PKCS12

CA:
---
( Certificate Management Protocols, draft-ietf-pkix-rfc2510bis-04.txt)

1. CA generates keys (for self)

2. CA creates cert-request (for self)

3. CA sends cert-request

4. CA receives cert-reply (for self) 

5. CA receives cert-request

6. CA creates new certificate 

7. CA signs new certificate

8. CA sends cert-reply

9. CA publishes certificate

10. CA creates CRL (at scheduled time, sets new schedule, must be made before certs are issued)

11. CA publishes CRL (at URL, PKIX)

(Certificate and CRL Profile <draft-ietf-pkix-new-part1-08.txt>
If the distributionPoint field is present and contains a URI, the
following semantics MUST be assumed: the object is a pointer to the
most current CRL issued by this CRL issuer.  The URI schemes ftp,
http, mailto [RFC1738] and ldap [RFC1778] are defined for this
purpose.  The URI MUST be an absolute pathname, not a relative
pathname, and MUST specify the host.)

RFC2485: 
Internet X.509 Public Key Infrastructure
Operational Protocols: FTP and HTTP
HTTP Conventions
Within certificate extensions and CRL extensions, the URI form of
GeneralName is used to specify the location where issuer certificates
and CRLs may be obtained.  For instance, a URI identifying the
subject of a certificate may be carried in subjectAltName certificate
extension. An IA5String describes the use of HTTP to fetch
certificate or CRL information.  For example:
http://www.netcom.com/sp/spyrus/housley.cer
http://www.your.org/pki/id48.cer
http://www.your.org/pki/id48.no42.crl
For convenience, the names of files that contain certificates should
have a suffix of ".cer".  Each ".cer" file contains exactly one
certificate, encoded in DER format.  Likewise, the names of files
that contain CRLs should have a suffix of ".crl".  Each ".crl" file
contains exactly one CRL, encoded in DER format.      

Transport Protocols for CMP <draft-ietf-pkix-cmp-transport-protocols-04.txt>

RA:
---

1. RA authorizes cert-request (for end-entity)

2. RA sends cert-reply (to end-entity)

3. RA generates keys (for end-entity)

4. RA creates cert-request (for end-entity)

5. RA sends cert-request (for end-entity)

6. RA receives cert-reply (for end-entity)


CA-admin:
---------

1. CA-admin creates new rootCA
	sets policy
	Generate keys and cert

2. CA-admin creates RA
	Assigns rights
		Which CA the RA is for
		Naming restrictions?
	Generate keys and cert alt. assign already existing cert (created as existing user).

3. CA-admin creates new CAs
	sets policy
	Generate keys and cert

4. CA-admin assigns new CA-admins
	Assigns right
		Which CA(s) the admin is for
		Assign new admins?/Create CAs/Create RAs?/Create new rootCAs?
	Assign already existing cert (created as existing user through RA).
	
5. CA-admin gets list of existing certs and keys for admin


RA-admin:
---------

1. RA-admin registers end-entity
	RA-admin does the job
	User does the job himself
	
2. RA-admin approves cert request
	Manually approves
	Automatically approves

3. RA-admin creates keys and certs for external delivery
	PKCS12
	PKCS8/PEM
	
4. RA-admin lists certs and keys for end-entity


Sysadmin:
---------

Sysadm installs SW

Sysadm creates SSL-keys/cert for server

Sysadm installs SSL-keys/cert for server

Sysadm assigns master CA-admin
	Generate keys

Install:
--------

Install general SW (appservers)

Install CA-SW in appservers

Install client-SW for CA- and RA-admins (if not web)


SW-DESIGN
=========

Nouns: certificate, keys (cert + nycklar = keystore?), rootCA, CA, RA, CA-admin, RA-admin, end-entity, policy, cert-request, cert-reply, rights

Verbs: approve, sign, generate keys, create cert-request, create certificate, sign certificate, create cert-reply, send, receive, install, authorize, find


Some objects and types:
------------------------

EntityName

EntityType

Policy

Keys

Cert-request

Cert-reply

Rights

AuthenticationType

AuthorizationType

CRL

Important mappings and operations:
----------------------------------

Mapping from Entity to certificate (one-to-many)

Mapping from Entity to keys (one-to-many)

e.g. Mapping from Entity to Keystore (one-to-many)

Mapping from certificate to Entity (many-to-one)

Mapping from cert-request to Entity (one-to-one)

Mapping from authentication to Entity (one-to-one)

Mapping from Entity to rights (one-to-many)

--
Mapping from Entity to keystore: Certificate and Entity contains DN -> DN = primary key
DN not unique since mapping is one-to-many -> DN + fingerprint of cert = primary key
-> Keystore must contain cert
findByDN must be possible
findByFingerprint must be possible

Mapping from certificate and cert-request to Entity: Certificate and cert-request contains DN, Entity contains DN -> DN = primaryKey for Entity

Mapping from authentication to Entity: authentication contains userID/pwd or DN -> userID or DN = primaryKey for Entity

Mapping from Entity to rights: entity contains DN/userID -> DN or userID = primaryKey for Rights (alt. Entity contains rights, but this makes one-to-many hard)

Finding latest CRL efficiently must be possible.

Finding older CRLs (by date?) must be possible.

Finding next CRL issue time efficiently must be possible.