This document is written according to the structure suggested by the IETF RFC 3647 and superceedes the earlier version written according to the structure suggested by the RFC 2527. The Public Key Infrastructure (PKI) used for the implementation of the policy described by this CP/CPS document is derived from the requirements and recommendations of RFC 3289 (obsoleting RFC 2459) and is designed to be in accordance with IGTF Classic X.509 CAs with secured infrastructure profile.
SiGNET CA functions as part of the Experimental Particle Physics Department (F9-IJS) of the "Jozef Stefan" Institute in Ljubljana, Slovenia (IJS), the leading Slovenian non-profit research organization.
SiGNET CA is the top level Certification Authority for Slovenia. SiGNET CA provides public key infrastructure (PKI) to Slovenian research and educational organisations and users, and Slovenian participants in grid projects and EGEE collaboration.
This document describes the set of rules, operational procedures and obligations for the issuance and management of certificates used by the Slovenian Grid Network Certification Authority (SiGNET CA).
OID structure:
| IANA | 1.3.6.1.4.1 |
|---|---|
| IJS | .15312 |
| SiGNET CA | .3 |
| CP/CPS | .1 |
| Major Version | .1 |
| Minor Version | .1 |
SiGNET certificates are signed by SiGNET CA. SiGNET CA does not issue certificates to subordinate certification authorities.
SiGNET CA certificate is signed by itself.
SiGNET CA manages the functions of its Registration Authority.
Additional registration authorities may be created by SiGNET CA as required. Such trusted intermediaries are formally assigned by SiGNET CA and their identities and contact details are published in an on-line accessible repository at the following URL: http://signet-ca.ijs.si/signet-ralist.txt.
RAs must sign an agreement with SiGNET CA, stating their adherence to the procedures described in this document. RAs are not allowed to issue certificates under this CP/CPS.
SiGNET CA will issue certificates to entities formally based or having offices in Slovenia, or participating in projects based in Slovenia, and are intended for cross-organisational sharing of resources in the fields of research and/or education.
Certificates can be issued to persons and computer entities (services or hosts). Organisations employing the person or owning the computer entity are not the end entities themselves.
Relying parties may be:
persons receiving signed or encrypted objects, suchs as e-mails, and persons accessing hosts or services using SiGNET CA issued certificates
hosts and services communicating with certifcate owners using certificates for authentication in association with Grid, e-science or related research and development activities.
No stipulation.
Certificates issued are of the following types:
authorised for document-signing, personal authentication, and encryption of communications
authorised for object-signing, host authentication, and encryption of communications
authorised for object-signing, service authentication, and encryption of communications
The certificates issued by SiGNET CA may not be used for financial transactions or for any commercial usage, including gifts.
SiGNET CA is responsible for the registration, maintenance, and interpretation of this CP/CPS. SiGNET CA is managed by the F9 - Experimental Particle Physics Department of the "Jozef Stefan" Institute in Ljubljana, Slovenia.
F9 IJS general web address is: http://www-f9.ijs.si/.
SiGNET CA general web address is: http://signet-ca.ijs.si/.
SiGNET CA policy documents are at: http://signet-ca.ijs.si/policy/.
SiGNET CA Certificate Repository is at: http://signet-ca.ijs.si/cert/.
SiGNET CA CRL Repository is at: http://signet-ca.ijs.si/crl/.
SiGNET CA address for operational issues is:
SiGNET CA F9 Experimental Particle Physics Department "Jozef Stefan" Institute Jamova 39 P.O. BOX 3000 SI-1001 Ljubljana Slovenia
email: signet-ca@ijs.si phone: +386 1 477 3742 fax: +386 1 425 7074
The contact person for questions related with this document is:
Jan Jona Javorsek F9 Experimental Particle Physics Department "Jozef Stefan" Institute Jamova 39 P.O. BOX 3000 SI-1001 Ljubljana Slovenia
email: jona.javorsek@ijs.si phone: +386 1 477 3742 fax: +386 1 425 7074
The contact persons for questions related with SiGNET CA operations are the previous defined contact person and:
Borut Kersevan F9 Experimental Particle Physics Department "Jozef Stefan" Institute Jamova 39 P.O. BOX 3000 SI-1001 Ljubljana Slovenia
email: borut.kersevan@ijs.si phone: +386 1 477 3454 fax: +386 1 425 7074
The second person named under section 1.5.2.
SiGNET CA CP/CPS changes are prepared and revised by SiGNET CA management. The approved document is to be submitted to EUGridPMA for revision of compliance with IGTF Classic X.509 CAs with secured infrastructure profile and acceptance in European e-Science projects.
The following definitions and associated abbreviations are used in this document.
Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a passphrase, or a manually-held key share).
Organisation Européene pour la recherce nuclèaire, the European Organisation for Nuclear Research, an intergovernmental organisation having its seat in Geneva, Switzerland.
Synonymous with Public Key Certificate.
An entity trusted by one or more users to create and assign public key certificates and be responsible for them during their whole lifetime.
A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.
A computer configured with appropriate software to support the procedures described in this CPS.
A statement of the practices which a certification authority employs in issuing certificates.
A time stamped list identifying revoked certificates which is signed by a CA and made freely available in a public repository.
Experimental Particle Physics Department of the "Jozef Stefan" Institute in Ljubljana, Slovenia. F9-IJS is leading SiGNET and actively participating in grid infrastructure deployment in Slovenia. (More info on F9-IJS: http://www-f9.ijs.si/.)
A fully qualified domain name consists of a host name and all domain names up to and including the top-level domain. FQDN is sufficient for unique identification of a host (multihomed IP non withstanding) or service.
"Jozef Stefan" Institute in Ljubljana, Slovenia (IJS), is the leading Slovenian research organisation. This non-profit organisation is responsible for a broad spectrum of basic and applied research in the fields of natural sciences and technology. (More info on IJS: http://www.ijs.si/.)
In the context of a particular certificate, the issuing CA is the CA that issued the certificate.
A data structure containing the public key of an end entity and some other information, which is digitally signed with the private key of the CA which issued it.
Organisations, policies and computing facilities required for operating a public key security, encryption and authentication scheme.
Policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate.
An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e. an RA is delegated certain tasks on behalf of a CA).
A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate. In this document, the terms "certificate user" and "relying party" are used interchangeably.
A storage area, usually online, which contains published materials, such as lists of issued certificates, CRLs, policy documents, etc.
A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS employing the approach described in this framework.
Slovenian Grid Network is the root organisation providing grid and computational network services to Slovenian scientific, educational and research communities.
SiGNET CA is the top level Certification Authority for Slovenia. SiGNET CA provides public key infrastructure (PKI) to Slovenian research and educational organisations and users, and Slovenian participants in grid projects and EGEE collaboration. (More info on SiGNET CA: http://signet-ca.ijs.si/.)
In the context of a particular CA-certificate, the subject CA is the CA whose public key is certified in the certificate (see also Issuing certification authority).
Within this document the words must, must not, required, shall, shall not, should, should not, recommended, may, optional are to be interpreted as in RFC 2119.
Any other terms are to be understood as defined in RFC 3647.
SiGNET CA will manage an online repository with unlimited access on its public web server at the following URL: http://signet-ca.ijs.si/.
The repository is operated at a best-effort basis, where the intended availability is continuous.
SiGNET CA will publish the following information with no access restrictions:
SiGNET CA's root certificate and public key and all previous SiGNET CA root certificates and keys needed to check still valid certificates;
A Certificate Revocation List of SiGNET CA issued certificates signed by SiGNET CA;
All past and current versions of this document;
Other relevant information, including any relevant subscriber and relying party documentation as per SiGNET CA management discretion.
Information that can be published is limited by provisions in section 9.4.
SiGNET CA will publish all up-to-date documents on best effort basis.
CRLs will be issued and published after every certificate revocation or at least 7 days before the current CRL expires. The usual validity of a CRL is 30 days.
New versions of CP-CPS will be published as soon as they have been approved.
SiGNET CA imposes no access control on its Policy, its Certificate and CRLs.
SiGNET Grid CA may at any time impose a more restricted access control policy to the repository at its discretion.
SiGNET CA public web site, online repository and certificate request submission web interface are operated at a best-effort basis, where the intended availability is continuous.
The names used in certificate Subject Name and issuer name shall be in the form of full X.501 distinguished names (DN).
Name forms are further defined in section 7.1.5.
Any name under this CP/CPS starts with C=SI, O=SiGNET. If the
subject is part of an organisation, an O=organisation. An
optional OU=organisational_unit must be appended if the
organisation consists of multiple administrative divisions. (Changes
in division name that do not change the organisational layout of an
organisation do not constitute a reason to invalidate the current unit
name.) The last part is the CN, which takes one of the following
forms:
CN is the full name of the subject.The name must include at least one given name in full and the full surname. Only ASCII alphanumeric letters, space and dash may be used.
Example of a full subject name for a person from IJS:
C=SI, O=SiGNET, O=IJS, OU=F9 CN=Janez Kranjski
A change in the name of the person does not invalidate the certificate and does not necessitate immediate change of the distinguished name.
CN is the host fully qualified domain name DNS name (FQDN). In case the host entity is not an internetwork entity or no such FQDN is assigned for other reasons, the entity is not eligible for certification under this policy.
FQDN domains may be different from organisation and
organisational_unit fields since assigned FQDN does not always follow
the structural layout of an organisation or network.
Example of a full subject name for a server:
C=SI, O=SiGNET, O=IJS, OU=F9, CN=host.ijs.si
CN is constructed in the same way and under the same conditions as for hosts, but with a service identifier related to the service appended to the front.
Example of a full subject name for a service:
C=SI, O=SiGNET, O=IJS, OU=F9, CN=ldap/host.ijs.si
### If technical reasons prohibit the above form of name for a service in a certificates bound to network entities, a FQDN shall be included as a dnsName in the SubjectAlternativeName certificate extension.
The subject name in a certificate must have a reasonable association with the authenticated name of the subscriber.
The common name CN in the certificate subject name must be obtainable from the real subject name. For persons it must be obtainable from a name of the person. For host certificates, the CN must be formed from the registered fully qualified domain name (DNS FQDN). For a service certificate, the CN must be related to the type of service the certificate is identifying.
The Organisation Name in the certificate subject name must be one of the organisations involved in SiGNET activities. Current list of values available for Organisation Names in the in the certificate subject name can be obtained from the URL mentioned in section 1.3.2.
No personal certificates shall be issued to roles or functions, only to named and identified persons.
See section 3.1.1.
The distinguished name for each certificate must be unique. In case of real subject name duplication, additional numbers and/or letters will be appended to the distinguished name to guarantee uniqueness.
Certificates must apply to unique individuals or resources. Users must not share certificates.
Name claim disputes are resolved by discretion of the first person named under section 1.5.2.
No stipulation.
The possession of the private key by the requestor is considered proven when the signature of the certifucate signing request (CSR) is verified using the public key present in the request.
No certificates are issued directly to organisations. Certificate requests for entities such as hosts and services must be made by a secure online submission to SiGNET CA Public Server, signed with a valid personal SiGNET certificate. Alternatively, an e-mail message signed with a valid personal personal SiGNET certificate may be used.
A user requesting a certificate must meet in person with the RA and show a legaly valid Slovenian photo ID or acceptable foreign photo ID recognised in Slovenia, such as a passport.
If the identification document is valid and the photo image corresponds to the bearer, the RA shall consider that the user is correctly identified.
The RA must forward a photocopy of the document for safekeeping by the CA.
Additionally, the RA may consider that the user is correctly identified if the RA has previously identified the user using the procedure described above and the user can prove possession of his/her secret key of an existing certificate issued by SiGNET CA. In this case the RA must check by telephone or personal conversation that the request originated at the known user.
If authentication is not completed within fifteen days of receipt of the certificate request by the RA, the request will be deemed to have expired. The process of submitting a certificate request and complying with the authentication procedure as per sections 3.2.2 and 3.2.3 shall have to be repeated.
No stipulation.
SiGNET CA may take steps to ascertain that the user is indeed entitled to represent the organisation or entity which has the rights over the host or service on behalf of which the certificate request has been made.
If the name of an organisation is requested to be part of a subject name, SiGNET CA may take steps to ascertain that the organisation consents to such use.
In the certificate request, the generic e-mail for the host or service must be specified in the Certificate data part and the e-mail of the user requesting the certificate in the User data.
No stipulation.
Rekeying of certificates will follow the same procedure as an initial registration.
Additionally, rekeying of certificates of persons before certificate expiration can be requested by submitting a rekey request to the SiGNET CA Public Server, signed by the subscriber's current personal SiGNET CA certificate with the old key.
A public key whose certificate has been revoked shall not be re-certified.
Rekey of certificates after revocation follows the same rules as an initial registration.
Unless SiGNET CA can independently verify that a key compromise has occurred, a revocation request must be authenticated before being accepted. Anyone can make certificate revocation requests by sending email to the CA. However, the CA will not revoke a certificate unless the request is authenticated, or it can be verified independently that there is reason to revoke the certificate. See section 4.9.
Authenticated certificate revocation requests may be made by
The RA using:
Digitally signed email to signet-ca@ijs.si;
Other secure method, as specified in the RA Operator's procedure;
The method for authentication of individual entity, as described in section 3.2.3.
The subscriber by:
Mailing the SiGNET CA directly by email to signet-ca@ijs.si, digitally signed with a certificate which has not expired or been revoked and was issued under this CP/CPS, regardless of the document version, where the e-mail address in the request must belong to the person that owns the certificate;
The method for authentication of individual entity, as described in section 3.2.3.
Anyone who can prove possesion of the private key associated with the certificate.
SiGNET CA issues certificates only to users who are members or associates of eligible projects or organizations or can demonstrate their connection with eligible projects or organisations.
Eligible are exclusively Slovenian scientific, educational and research organizations and projects.
Additionally, the user has to be either a Slovenian resident, possibly temporary, or Slovenian citizen, with the exception of users connected with eligible organizations or projects who have no accepted grid or scientific CA in thier country of origin and residence.
SiGNET CA issues host and service sertificates only for hosts and services administered by an eligible user, project or organization.
Any certificate application request to SiGNET must follow the following provisions:
The subject must be an acceptable end user entity, as defined by this policy.
Personal certificates must not be shared; server certificates must be linked to a single network entity.
The applicant must register with a SiGNET RA as per section 3.
The request must obey SiGNET CA distinguished name scheme.
The distinguished name must be as per section 3.1.1; see also section 7.
The distinguished name must be unambiguous and unique.
The applicant must generate their key pair as per section 6.
The applicant must guard their private key and not reveal it to SiGNET CA. SiGNET CA must not generate the key pair for the applicant.
Maximal lifetime of a certificate is one year. The default validity period is one year.
Certificate requests are made via SiGNET CA's public web interface at http://signet-ca.ijs.si/. Alternatively, if the web interface can not be used, certificate requests can be made via e-mail with the attached public key in PEM-format at signet-ca.user@ijs.si.
Certificate requests are submitted also through any additional approved RA's as per section 1.3.2.
Each SiGNET RA must sign an agreement to adhere to the procedures described in this document.
Each SiGNET RA shall authenticate entities requesting a certificate according to the procedures outlined in section 3.2.
Each SiGNET RA shall:
Approve certificate requests according to the procedures outlined in this document;
Validate the connection between a public key and the requester identity including a suitable proof of possession method;
Confirm such validation to the CA;
Send the approved certificate requests to SiGNET CA;
Check that the subscriber knows and agrees to subscriber obligations concerning safeguarding their private key - for a personal key, this means that the key is protected by a pass-phrase of length of at least 15 characters in length; for a server key it means that the key is at least readable only by root or a restricted user account;
Check that the information provided in the certificate request is correct and check that the email address provided by the subscriber is correct;
Approve revocation requests according to the procedures outlined in this document;
Send the approved revocation requests to SiGNET CA;
Sign each request before sending it to SiGNET CA;
Request revocation of a certificate in the event that it becomes aware of circumstances justifying such revocation;
inform the CA and request the revocation of the RA's certificate if the RA's private key is destroyed, lost, compromised or suspected to be compromised;
Log all transactions and requests;
Follow the policies and procedures described in this document.
Each SiGNET RA should respond to a certification request in three working days.
Additional time constraints are as specified in section 3.2.3.
The first step in the issuance process is the approval of the request by an RA (including SiGNET CA's own RA). The following requirements must be fulfilled:
RA must authenticate the applicant according to the procedures described in section 3.2.3;
RA must check if the request sender can apply for a certificate according to section 1.3.3
RA is recognised by SiGNET CA as a RA for the applicant, as specified in section 1.3.2
If all the above requirements are fulfilled, then RA approves the request and passes on the request to the CA for issuance of a certificate.
The subject will be notified by e-mail. If the subject is a person, the e-mail will be sent to the address accompanying the request. Otherwise the e-mail will be sent to the address specified in the request. In the case of rejection, the e-mail will state the reason.
If the e-mail fails to be delivered in a period of 5 days, the certificate is revoked without further notice.
Once a certificate request has been approved by the RA, the certificate is normally issued by the CA within seven working days.
SiGNET CA is solely responsible for the issuance and management of certificates referencing this document.
As the issuer of SiGNET CA certificates, SiGNET CA accepts a number of obligations. SiGNET CA shall:
Ensure that all services, operations and infrastructure conform to this CP/CPS at all times;
Handle certificate requests and issue new certificates:
Accept and confirm certification request from entitled entities and approved certification requests from RAs;
Authenticate entities requesting a certificate, where applicable with the assistance of the designated RAs listed at the location specified in section 1.3.2;
Issue certificates based on approved certificate requests from authenticated entities;
Send notification of the issuing of the certificate to the subscriber;
Make issued certificates publicly available;
Handle certificate revocation requests and certificate revocation:
Accept and confirm revocation requests from entitled entities and RAs requesting that a certificate be revoked according to procedures described in this document;
Authenticate entities requesting that a certificate should be revoked;
Revoke certificates based on approved revocation requests from authenticated entities;
Issue a Certificate Revocation List (CRL) according to the procedures outlined in this document;
Make certificate revocation information publicly available in the form of published CRL.
No stipulation.
### Upon receiveing the certificate notification e-mail, visiting SiGNET CA online repository and retreiving the certificate, the subscriber has 5 working days to establish certificate usability. Unless the subscriber rejects the certificate in 5 working days, said certificate is considered accepted by the subscriber.
### SiGNET CA will make the issued certificate available in its online repository.
### SiGNET CA will notify the subscriber when a new certifcte is issued.
### Certificates issued by SiGNET CA and their associated private keys must be used exclusively in accordance with permissions and prohibitions stated in section 1.4.
Revoked and expired certificates and their key must not be used.
### The relying party must, upon being presented with a certificate issued by SiGNET CA:
check that the certificate has not expired;
check that the issuing CA is trusted by the relying party and the certificate is signed by the issuing CA correctly;
check that the use of certificate corresponds with the key usage fields in the certificate;
check the validity of the certificate as per section 4.9.6.
A certificate will be revoked when the information it contains is suspected to be incorrect or compromised. This includes situations where:
The subscriber's private key is lost, destroyed or suspected to be compromised;
The information in the subscriber's certificate is suspected or confirmed to be inaccurate;
The subscriber no longer needs the certificate to access Relying Parties' resources;
The subscriber no longer fulfills the conditions for participation in SiGNET;
The subscriber violated his/her obligations;
The system or service to which the certificate has been issued has been retired.
In addition, the CA will revoke all certificates in the event that its key has been compromised (as per section 5.7.3) or in the event that the CA has been terminated (as per section 5.8).
A certificate revocation can be requested by the holder of the certificate to be revoked or by any other entity presenting proof of knowledge of circumstances for revocation, as described in section 4.9.1.
The entity requesting the revocation must send the revocation request with an authenticated deposition via the public web interface at SiGNET or by a signed e-mail to SiGNET CA or a SiGNET RA. If this is not possible the CA/RA must be contacted directly. Authentication can be performed as per section 3.2.3.
In both cases above, the requesting entity must specify the reason for the revocation request and provide evidence of circumstances as described in section 4.9.1.
There will be no grace period associated with certificate revocation.
SiGNET CA handles revocation requests with priority and a certificate will be revoked as soon as possible after circumstances for revocation, as described in section 4.9.1, are established.
Before use of a certificate, a relying party must validate it against the most recently issued CRL.
CRLs will be issued and published after every certificate revocation or at least 7 days before the current CRL expires. The usual validity of a CRL is 30 days, as stated in 2.3 Time or Frequency of Publication.
No stipulation.
### SiGNET CA may provide additional mechanisms for revocation/status checking, such as an OCSP server or a web service.
### If an on-line revocation/status mechanism is provided, relying parties may use it instead or in addition to the published CRL, where the newest information has precedence.
No stipulation.
No stipulation.
There is no provision for certificate suspension.
No stipulation.
No stipulation.
No stipulation.
### do something with this sections:
### SiGNET CA provides a CRL for certificate validity checking.
### SiGNET CA certificate validity checking service and its usage is further described in section 4.9.
### SiGNET CA certificate validity services are provided on best effort basis only, with the intention of providing continous service.
SiGNET CA my provide an OCSP responder service in addition to CRL service.
No stipulation. See 6.2.3 Private Key Escrow.
No stipulation.
No stipulation.
SiGNET CA operates in the computer centre of the F9 department at IJS, building C. The access to the building and the computer centre room is controlled.
The private keys of the SiGNET CA are only available in encrypted format on media in a secure location. Physical access to the hardware is restricted to personnel authorised to operate SiGNET CA.
The computer centre room is environmentally controlled, has suitable air conditioning system and the repository machines are connected to an UPS system and any available building backup power.
No stipulation.
No stipulation.
SiGNET CA key and back-up copies of SiGNET CA related data are kept on several removable storage media in a secure location. Backups are kept in an off-site secure location.
Waste carrying potential confidential information, such as old media and storage devices, are physically destroyed before being trashed.
Off-site backup is stored at a dislocated room with physically restricted access.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
SiGNET CA personnel must be staff members of the F9 IJS, Experimental Particle Physics Department of the "Jozef Stefan" Institute in Ljubljana, Slovenia.
SiGNET CA personnel must pass F9 IJS computer room clearance.
SiGNET CA personnel must be appointed by the manager of F9 IJS who can revoke the appointment at his/hers discretion any time without any notice.
SiGNET CA should perform operational audits of the CA/RA staff at least once per year.
A list of SiGNET CA and all RA personnel should be maintained and verified at least once per year.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
The following events are recorded and audited:
Certification requests;
Issued certificates;
Issued CRLs;
Requests for revocation;
Boots and shutdowns of the CA equipment;
Interactive system logins at the CA equipment.
Audit logs will be analysed at least once per month.
Logs will be kept for a minimum of 3 years.
Only authorised CA personnel and authorised external auditors are allowed to view and process audit logs. Audit logs are copied to an off-line non-magnetic medium.
Audit logs backups are copied to an off-line medium, which is stored at a dislocated room with physically restricted access.
The audit log collection system is internal to SiGNET CA.
No stipulation.
No stipulation.
The following events are recorded and archived:
Certification requests;
Approved Certification requests;
Issued certificates;
Requests for revocation;
Issued CRLs;
System logs for startups and shutdowns of the CA equipment;
System logs for interactive system logins at the CA equipment.
All e-mail messages received by SiGNET CA;
All e-mail messages sent by SiGNET CA.
Logs will be kept for a minimum of 3 years.
Only authorised CA personnel and authorised external auditors are allowed to view and process audit logs. Audit logs are copied to an off-line medium.
Audit log backups are copied to an off-line medium, which is stored at a dislocated room with physically restricted access.
No stipulation.
The archive collection system is internal to SiGNET CA.
No stipulation.
The private signing key for SiGNET CA is changed periodically. To avoid interruption of validity of subordinate keys the new SiGNET CA private key should be generated one year before the expiration of the old key. From that point on new certificates are signed by the newly generated signing key. The new SiGNET CA public key is posted in the on-line repository.
No stipulation.
If the CA equipment is damaged or rendered inoperative, but the CA private key is not destroyed, CA operation will be reestablished as quickly as possible. If the private key is destroyed the case will be treated as in section 5.7.3.
If the CA's private key is destroyed, lost, compromised or suspected to be compromised, or if the entities key is revoked, the CA will:
Make all reasonable efforts to notify subscribers, RAs and cross-certifying CAs of which the CA is aware;
Terminate the certificates and CRL distribution services for certificates and CRLs issued using the compromised key;
Generate a new CA key pair and certificate and make the latter available in the public repository;
Notify relevant security contacts at IJS.
In the case of such a CA key compromise, new certificates will be issued only in accordance with the entity identification procedures defined for initial registration in section 3.
If an RA's private key is compromised or suspected to be compromised, the RA will inform the CA and request the revocation of the RA's certificate.
If an entity private key is compromised or suspected to be compromised, the entity or its administrator must request a revocation of the certificate and make all reasonable efforts to inform any known relying parties.
In the case of a disaster whereby the CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, SiGNET CA will take whatever action it deems appropriate.
Before SiGNET CA terminates its services, SiGNET CA shall:
Make all reasonable efforts to inform subscribers, RAs and cross-certifying CAs;
Make knowledge of its termination widely available;
Cease issuing certificates and CRLs;
Destroy all copies of private keys.
Notify relevant security contacts at IJS.
Each subscriber must generate his/her own key pair. SiGNET CA does not generate private keys for subjects. The private key should not be known by other than the authorised user of the key pair.
Applicants are recommended to use tools available from SiGNET CA public web server to create their key pair as part of the request generation process. If key pairs are generated by some other means the applicant must ensure that key lengths conform to those given in section 6.1.5.
Key pairs for the SiGNET CA are generated exclusively by SiGNET CA staff members on a dedicated, disconnected system, using a recent, trustworthy version of required operating system software and software package.
Each applicant must generate their own key pair.
Applicants public keys are delivered to the issuing CA by the HTTP protocol via the CA's public web interface.
Alternatively, applicants public keys are delivered to the RA or directly to SiGNET CA in in PEM-format in an email containing the certificate request. The RA must send the public key to SiGNET CA in an email signed by the RA.
SiGNET CA certificate and public key can be downloaded from SiGNET CA public repository at the following URL: http://signet.ijs.si/pub/.
The minimum key length for a personnel, server or service certificate is 1024 bits;
The CA key minimum length is 2048 bits.
No stipulation.
Keys may be used for authentication, data enchipherment, message integrity and session key establishment. The SiGNET CA private key is the only key that can be used for signing SiGNET certificates and CRLs.
For the certificates issued by SiGNET CA under this policy,
keyUsage field must be used in accordance with RFC 2459. The
keyUsage extension is defined in subsection 7.1.2.
No stipulation. ### should expand?
No stipulation.
SiGNET CA keys are not given in escrow. SiGNET CA is not available for accepting escrow copies of keys of other parties.
SiGNET CA private key is kept encrypted in multiple copies on removable devices media in safe places, including off-site storage. The passphrase is in a sealed envelope kept in a safe.
Subscribers are responsible for the backup of their encrypted private keys.
See section 6.2.4.
No stipulation.
No stipulation.
The activation of the CA private key is done by providing the passphrase.
No stipulation.
After termination of the CA and after the archival period for archives has expired, all media that contain the private key of the CA (including those specified in section 6.2.4) will be securely and permanently destroyed, according to then best current practice.
No stipulation.
The public key is archived as part of the certificate archival.
SiGNET CA root certificates have a validity of five years. For other entity certificates, the maximum validity period for a certificate is one year.
There is no stipulation as to the validity of the generated key pair.
SiGNET CA private key is protected by a passphrase with a minimum length of 15 characters. All passphrases used by the SiGENT CA have a length of at least 15 characters, consist of both letters, numbers and signs and does not contain consecutive or repetitive keystrokes.
A copy of the passphrase is kept in a safe. The passphrase is known to current staff members of SiGNET CA on a need to know basis. Change of staff will imply a change in the passphrases.
No stipulation.
The operating systems of CA/RA computers are maintained at a high level of security by applying all the relevant patches;
CA systems configuration is reduced to the bare minimum;
The machine used for signing certificates is not connected to any network and is kept powered off when not in use;
The machines used to hold online repositories and run web site interfaces is protected by a suitable firewall;
Unauthorised physical access is prohibited.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
The CA signing machine is not connected to any kind of network;
CA/RA machines other than the signing machine are protected by a firewall.
No stipulation.
All certificates issued by SiGNET CA conform to the Internet PKI profille (PKIX) for X.509 certificates as defined by RFC 3280.
X.509 v3 (0x2).
All certificates that reference this CPS will include a reference to the AIN.1 O.I.D. of this document as per section 1.2 within the appropriate field.
The following extensions are set in user certificates:
X509v3 Basic Constraints: CRITICAL CA:FALSE
X509v3 Subject Key Identifier
X509v3 Authority Key Identifier
X509v3 Key Usage: CRITICAL Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
X509v3 CRL Distribution Points
X509v3 AuthorityInfoAccess for optional OCPS ###
X509v3 Issuer Alternative Name
X509v3 Subject Alternative Name (at least user's email)
X509v3 Certificate Policies
Netscape Cert Type: SSL Client, S/MIME, Object Signing
Netscape Base URL
The following extensions are set in host certificates:
X509v3 Basic Constraints: CRITICAL, CA:FALSE
X509v3 Subject Key Identifier
X509v3 Authority Key Identifier
X509v3 Key Usage: CRITICAL Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
X509v3 CRL Distribution Points
X509v3 AuthorityInfoAccess for optional OCPS ###
X509v3 Issuer Alternative Name
X509v3 Subject Alternative Name (at least administrative email)
X509v3 Certificate Policies
Netscape Cert Type: SSL Server, SSL Client, S/MIME, Object Signing
Netscape Base URL
The following extensions are set in the SiGNET CA self-signed certificate:
X509v3 Basic Constraints: CRITICAL CA:TRUE
X509v3 Subject Key Identifier:
X509v3 Authority Key Identifier:
X509v3 Key Usage: CRITICAL Certificate Sign, CRL Sign
X509v3 CRL Distribution Points
X509v3 Issuer Alternative Name
X509v3 Subject Alternative Name
Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA
Netscape Base URL
The following extensions are set in SiGNET CA's OCSP certificates (if used):
X509v3 Basic Constraints: CRITICAL, CA:FALSE
X509v3 Subject Key Identifier
X509v3 Authority Key Identifier
X509v3 Key Usage: CRITICAL Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
X509v3 Extended Key Usage: CRITICAL serverAuth, timeStamping, OCSPSigning
X509v3 Issuer Alternative Name
X509v3 Subject Alternative Name (SiGNET CA administrative email)
X509v3 Certificate Policies
X509v3 authorityInfoAccess: URL of the OCSP responder
Netscape Cert Type: SSL Server, SSL Client, S/MIME, S/MIME CA, Object Signing, Object Signing CA
Netscape Base URL
No stipulation.
See section 3.1.1.
countryName |
must be |
|---|---|
organisationName |
must be |
organisationName(2) |
If set, must be the Slovenian scientific or educational organisation
involved in SiGNET activities. Current list of values available for
|
commonName |
must be name and surname or FQDN of the subject. |
See also sections 3.1.2, 3.1.4 and 3.1.5.
SiGNET Grid CA identifies this policy with the object identifier (OID) as specified in section 1.2.
No stipulation.
No stipulation.
No stipulation.
X.509 v2 (0x1).
No stipulation.
Note that OCSP service in SiGNET CA is optional.
OCSP profile v1 (0x0).
No stipulation.
No external audit will be required, only a self-assessment by the SiGNET CA that its operation is according to this document.
SiGNET CA will perform the self-assessment at least once a year.
Requests for external audit from other trusted CA may be considered at the discretion of IJS with the consideration that all costs and accommodations associated with such an audit will be borne by the requesting party.
No stipulation.
No stipulation.
No stipulation.
SiGNET CA will take immediate action if the assessment shows conflicts between the provisions of this CP/CPS document and the actual practice.
If any discovered conflicts show consequences on the reliability of cetrification process, any certificates issued under the influance of the problem shall be revoked imediatelly.
SiGNET CA will report assessment results to EU Grid PMA members and relying parties.
No fees are charged for any service provided by SiGNET CA.
See section 9.1.
See section 9.1.
See section 9.1.
See section 9.1.
See section 9.1.
No financial responsibility is accepted.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
SiGNET CA collects personal information about the subscribers (e.g. full name, organisation, organisation unit, e-mail address, phone number public key, certificate request file).
These data will be protected according to law of Republic of Slovenia.
By making an application for a certificate a subscriber is deemed to have consented to their personal data being stored and processed, subject to the Personal Data Protection Act of the Republic of Slovenia (ZVOP, 210-01/89-3/20, 1999 art. 3).
The full name is included in the certificate. Any info on organisation and organisational unit is included in the certificate. E-mail address and phone number are not included in the certificate.
Any information about subscriber that is not present in the certificate and CRL is considered private and confidential and will not be released outside of SiGNET CA.
Record of the e-mail messages sent and received by SiGNET CA is considered private and confidential.
Under no circumstances will SiGNET CA have access to the private keys of the subscribers to whom it issues a certificate.
Data contained in the CRLs and the subscriber certificate shall not be considered private and confidential and will be published in a publicly accessible location.
SiGNET CA and its accreddited RA are responsible to protect private information.
Subscribers allow SiGNET CA and its accredited RAs to process and store their private information according to this document with the act of applying for a certificate, in accordance with the Personal Data Protection Act of the Republic of Slovenia (ZVOP, 210-01/89-3/20, 1999 art. 3).
No other use of private information is allowed without specific consent for such specific use from the subscriber. Such consent is not needed for regular operation of the CA and no subscribers can be forced to give such consent to SiGNET CA.
SiGNET CA will not disclose certificate or any certificate-related information to any third party, aside from information publicly available, except when so required by a legal authority of competent jurisdiction.
In the case of certificate revocation/suspension, SiGNET CA will notify and inform the following entities:
The subject of the personal certificate;
The requester of the host or service certificate;
The IJS Networking Center security officer in case of security compromise.
No information about the reason for a revocation is published.
This document is based on the following sources:
RFC 3647 (superceeding 2527);
IGTF Classic X.509 CAs with secured infrastructure profile v. 4.1;
EuroPKI Certificate Policy;
Global Grid Forum Certificate Policy Model, version 7 October 2002;
CERN Certificate Policy and Certificate Practice Statement;
Grid-Ireland CA Certificate Policy and Certificate Practice Statement;
IUCC CA Certificate Policy and Certificate Practice Statement;
PK-GRID-CA Certificate Policy and Certificate Practice Statement;
Polish Grid CA Certificate Policy and Certificate Practice Statement.
AUSTRIAN GRID CA Certification Policy and Certification Practice Statement v1.2.0
This text may be used by others without prior approval; acknowledgments are welcomed but not required.
Unmodified copies may be published without permission.
SiGNET CA claims no intellectual property rights on issued certificates, certificate revocation lists, practice/policy specifications, names or keys.
SiGNET CA only guarantees to control the identity of the subjects requesting a certificate according to the practices described in this document;
SiGNET CA will not give any guarantees about the security or suitability of the service;
SiGNET CA aims to achieve a reasonable level of security, but its certification services are provided on a best-effort basis only;
Section 9.6.1 applies mutatis mutandis to the representatons and warranties of the RA.
It is the RA's responsibility to authenticate the identity of subscribers requesting certificates, according to the practices described in this document. It is the RA's responsibility to request revocation of a certificate if the RA is aware that circumstances for revocation are satisfied.
In addition, applicants for SiGNET CA certificates must:
Accept conditions and adhere to the procedures described in this document;
Represent correct information on the certificate application and only such information as he/she is entitled to submit for the purposes of this document.
Authorise the treatment and conservation of personal data;
Generate a key pair using a trustworthy method;
Take reasonable precautions to prevent any loss, disclosure or unauthorised use of the private key associated with the certificate, including
selecting a strong passphrase with a minimum of 15 characters and
protecting the passphrase from others;
Use the certificate exclusively for authorised and legal purposes, consistent with this document;
Notify SiGNET CA when the certificate is no longer required;
Notify SiGNET CA when the information in the certificate becomes wrong or inaccurate;
Notify SiGNET CA immediately if the private key associated with the certificate is destroyed, lost, compromised or suspected to be compromised;
Notify SiGNET CA when they no longer fulfill the conditions for use of a SiGNET CA certificate, and cease usage immediately;
By using the authentication procedures described in this document subscribers accept the restrictions to liability described in section 9.8.
In using a certificate issued by SiGNET CA relying parties agree to:
Accept conditions and adhere to the policies and procedures described in this document;
Verify the certificate revocation information before validating a certificate; #already in 4.9.6
Use the certificate exclusively for authorised and legal purposes, consistent with this document;
No stipulation.
SiGNET CA and its RAs provide no warranties, express or implied, including in respect of security and confidentiality, and of fitness for a particular purpose, for their procedures, repositories, databases and certificates, and will take no responsibility for problems arising from their operation, or for the use made of the certificates they provide.
IJS, F9 IJS, SiGNET CA and its RAs accept no liability for or in connection with the certification services and the parties using or relying on them shall hold IJS, F9 department and SiGNET CA free and harmless from liability resulting from such use or reliance;
IJS, F9 IJS, SiGNET CA and its RAs deny any financial or any other kind of responsibilities for damages or impairments resulting from SiGNET CA's operation.
No stipulation.
IJS shall be entitled to terminate the certification services at any time.
SiGNET CA will make all reasonable efforts to notify all its subscribers, all cross-certifying CAs, and any relying parties known to SiGNET CA to be currently and actively relying on certificates issued by SiGNET CA on such termination.
All certificates issued by SiGNET CA that reference this document will be revoked no later than the time of termination.
All e-mail communications between the CA and its accredited RAs must be signed with a certified key.
All e-mail communications between the CA or an RA and a subscriber must be signed with a certified key in order to have the value of a proof. All requests for any action must be signed.
Users will not be advised in advance of changes to SiGNET CA's CP and CPS. Changes are made available as defined in section 2.
This document and any older versions are available from the on-line repository given in section 2.1.
Any change to this document that changes actual policy and practice of SiGNET CA requires a change of document OID.
SiGNET CA will resolve naming disputes according to best current practice.
This document is subject to all applicable laws of the Republic of Slovenia.
This document is subject to all applicable laws of the Republic of Slovenia.
This CP/CPS document superseeds any prior agreements, written or oral, between the parties covered by this present document.
No stipulation.
RFC 2527: N/A
Should a clause of the present CP/CPS document become void because of a conflict with the governing law as per section 9.14 or because it has been declared invalid or unenforceable by a law-enforcing entity, this clause shall become void but the remainder of this document shall remain in force.
SiGNET CA is free to either replace the voided clause as per section 9.12 or to terminate the CA as per section 9.10.2 per its dicretion.
No stipulation.
No stipulation.
No stipulation.
This forms part of the operating procedures of the SiGNET Certification Authority (CA). 1. In acting as a Registration Authority (RA) for SiGNET CA I have read and understood and accepted the responsibilities and tasks assigned to an RA laid out in SiGNET CA Certification Policy and Practice Statement (CP/CPS) document available on SiGNET CA web site - http://signet-ca.ijs.si/. 2. I understand that SiGNET CA will notify me by email of changes to CP/CPS and I will immediately notify SiGNET CA if I am no longer willing to act as an RA under any new CP/CPS. 3. I understand that failure to fulfill my responsibilities and tasks under this agreement may result in the termination of my appointment as an RA. 4. In the event of resignation, I will inform the SiGNET CA at least 90 days prior to my resignation. Signed by ........................................ on .............. Email: ........................................ Signature: ......................
S. Chokani, W. Ford, R. Sabett and S. Wu "Internet X.509 Infrastructure Certicate Policy and Certication Practices Framework", RFC 3647, November 2003 - http://www.ietf.org/rfc/rfc3647.txt.
S. Chokani and W. Ford, "Internet X.509 Infrastructure Certicate Policy and Certication Practices Framework", RFC 2527, March 1999 - http://www.ietf.org/rfc/rfc2527.txt.
R. Housley, W. Polk, W. Ford and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and Certicate Revocation List (CRL) Profile", RFC 3280, April 2002 - Lhttp://www.ietf.org/rfc/rfc3280.txt.>
R. Housley, W. Ford, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure: Certicate and CRL Profile", RFC 2459, April 1999 http://www.ietf.org/rfc/rfc2459.txt.
X.501 : Information technology - Open Systems Interconnection - The Directory: Models, 2001
Z. S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997 - http://www.ietf.org/rfc/rfc2119.txt.
CA Certificate Revocation List. http://ca.grid-support.ac.uk/cgi-bin/importCRL.
CA web site. http://ca.grid-support.ac.uk/.
R. Cecchini. INFN CA CP/CPS. http://security.fi.infn.it/CA-CPS/CPS-1.0.pdf, December 2001. Version 1.0.
CERN Administrative Procedures manual - http://as.cern.ch/AdminMan/.
CERN CA Security Group http://service-grid-ca.web.cern.ch/service-grid-ca - Email: service-grid-ca@cern.ch.
CERN Certificate Policy and Certificate Practice Statement v2.2 - http://service-grid-ca.web.cern.ch/service-grid-ca/cp_cps/cp_cps.html.
CERN IT Division Grid Deployment Group - http://it-div-gd.web.cern.ch/it-div-gd/.
The European DataGrid Project http://eu-datagrid.web.cern.ch.
EuroPKI Certificate Policy. http://www.europki.org/ca/root/cps/en_index.html, October 2000. Version 1.1.
Tony Genovese. DOE Science Grid CA CP/CPS. http://www.doegrids.org/Docs/CP-CPS.pdf, December 2001. Version 1.1.
Global Grid Forum Certificate Policy Model, version 7, October 2002 - http://caops.es.net.
Grid-Ireland CA Certificate Policy and Certificate Practice Statement v0.4 - https://www.cs.tcd.ie/grid-ireland/gi-ca/gi-ca0v4.pdf.
R. Housley, W. Ford, W. Polk, and D. Solo. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. AKA RFC 2459. http://www.rfc-editor.org/rfc/rfc2459.txt, January 1999.
IUCC CA Certificate Policy and Certificate Practice Statement v1.5 - http://certificate.iucc.ac.il/ca/.
National Computational Science Alliance Certificate Policy. http://archive.ncsa.uiuc.edu/SCD/Alliance/GridSecurity/Certificates/AllianceCP9.1.html, June 1999.
Nystrom & Kaliski, Certification Request Syntax Specification, RFC 2986, November 2000 - http://www.ietf.org/rfc/rfc2986.txt.
The OpenSSL Project - http://www.openssl.org/.
PK-GRID-CA Certificate Policy and Certificate Practice Statement v1.1.1.3 - http://www.ncp.edu.pk/pk-grid-ca.
Polish Grid CA Certificate Policy and Certificate Practice Statement v0.4 - http://www.man.poznan.pl/plgrid-ca/ca-policy.html.
AUSTRIAN GRID CA Certification Policy and Certification Practice Statement v1.2.0, Document OID: 1.3.6.1.4.1.21356.1.1.1.2.0, May 2, 2007 - https://ca.austriangridca.at/CP_CPS/AustrianGridCA_CP_CPS.pdf
Port numbers. http://www.iana.org/assignments/port-numbers.
TrustID Certificate Policy. http://www.digsigtrust.com/certificates/policy/tsindex.html.
UK Grid Support Centre. http://www.grid-support.ac.uk/.
X.509 Certificate Policy For The Federal Bridge Certification Authority. Available from http://www.cio.gov/fbca/lib/index.htm, December 1999. Version 1.0.
ASN OID Changed.
Restructured according to RFC 3647 framework.
Changed FQDN restrictions (###).
Added a reference to section 9.4 Privacy of Personal Information in section 2.2 Publication of Certification Information.
Added description of proof of private key possesion in section 3.2.1
Reformulated section 3.2.3 to more cleary specify that only a legally accepted photo ID document is valid for authentication, omitting reference to IJS internal ID cards.
3.3.1 Indentification and authentication for routine re-key: syntax clarification.
3.4 Identification and authentication for revocation request: added item 3, allowing revocation by anyone able to prove possession of its private key.
Refactored for RFC 3647 by adding provisions from RFC 2527 1.3.4 Applicability to 4.1.1 Who Can Submit a Certificate Applicaton.
Refactored for RFC 3647 by adding provisions from RFC 2527 2.1.3 Subscriber obligations to 4.1.2 Enrollment Process and Responsibilities.
Refactored for RFC 3647 by moving provisions from RFC 2527 2.1.2 RA obligations to 4.2 Certificate Application Processing.
Refactored for RFC 3647 by adding provisions from RFC 2527 2.1.1 CA obligations to 4.3 Certificate Issuance.
Added requirement to respond in three working days and a reference to time constraints in 3.2.3 Authentication of Individual Identity in 4.4.3 Time to Process Certificate Applications.
Moved requirement to respond to a revocation request from 4.9.4 Revocation Request Grace Period to 4.9.5 Time Within which CA Must Process the Revocation Request.
Added the posibility to provide additional mechanisms for revocation/status checking, such as an OCSP server or a web service, to 3.9.9 On-Line Revocation/Status Checking Availability, 3.9.10 On-Line Revocation Checking Requirements and 4.10.3 Optional Features.
Added operational audit of personnel and personel list maintainence provisions to 5.3.1 Qualifications, Experience, and Clearance Requirements for profile compliance.
Dropped non-repudiation from the list of supported certificate uses in 6.1.7 Key Usage Purposes and from certificate extenisions in 7.1.2.
Added personal responsibility for subscriber private key backup to 6.2.4 Private Key Backup.
Added 'There is no stipulation as to the validity of the generated key pair.' as clarification to 6.3.2 Certificate Operational Periods and Key Usage Periods.
Added general conformity to PKIX as per RFC 3280 statement to 7.1 Certificate Profile.
Added missing Subject Alternative Name fields and Netscape Object signing extensions fields to 7.1.2 Certificate Extensions.
Added X509v3 AuthorityInfoAccess certificate extenisions for optional OCPS in 7.1.2.
Added specification for optional OCSP service certificates to 7.1.2 Certificate Extensions.
CRL version number changed to v2 in 7.2.1.
Added stipulation that self-assessment is performed at least once a year to 8.1 Frequency and Circumstances of Assessment.
New sections (not listing sections added for RFC 3647 conformity but having no stipulation):
Updated bibliography with RFC links and new CA/CPS references used in restructoring.
dg-eur-ca list comments) -
25-Sept-2004ASN OID Changed.
Minor typos corrected.
dg-eur-ca list comments) -
18-Sept-20041.3.3 - Last statement changed: certificates are not issued directly to organisations and organisations are not end entities, as per 3.1.8.
2.1.2 item 6 - Reformulated to not force RA to check the safeguarding of subscriber's private keys, but merely assure they are informed about their obligations.
2.1.5 item 1 - Reformulated.
2.4.3 - Replaced unclear name dispute resolution policy with "according to best current practice".
3.1.1 - Deleted reference to emtpy section 7.1.4.
3.1.1 - Reference to name changes for persons is now clearer.
3.1.8 - Requirement for both generic host/service e-mail and personal e-mail in host and service certificate request added.
3.1.9 - Addition: CA will keep copies of documents used for identification. Clarification: it is not possible to use telephone converstation for identification, but it is used for confimation when a user identifies by the possession of a secret key for an existing certificate.
4.1. item 5 - Added reference to section 3.1 where forms of names are defined.
The SiGNET CA contact email changed to signet-ca@ijs.si.
A number of typos and grammatical errors.
Name changes and internal revisions.
A number of changes based on the IUCC Certification Authority CA/CPS document and others.
Initial revision.