Folks,
We just submitted a new draft of the RPKI Certificate policy that has
the changes listed below. Thanks go to Tomofumi Okubo for his
careful review and feedback.
Karen
1.2. Overview
Deleted:
"In the future, the PKI also may include end entity certificates
in support of access control for the repository system as
described in 2.4."
2.2. Publication of certification information
Added:
"The CP will be published as an IETF RFC and will be available
from the IETF RFC repository."
2.4. Access controls on repositories -- first sentence
Changed:
From: "Each CA or repository operator SHOULD implement access
controls to prevent unauthorized persons from adding,
modifying or deleting repository entries."
To: "Each CA or repository operator MUST implement access
controls to prevent unauthorized persons from adding,
modifying or deleting repository entries."
2.4. Access controls on repositories -- 2nd sentence
Added:
This data is supposed to be accessible to the public.
4.7.1. Circumstance for certificate re-key -- last paragraph
Changed:
From: Section 5.6 below notes that when a CA signs a certificate,
the signing key SHOULD have a validity period that exceeds the
validity period of the certificate. This places additional
constraints on when a CA SHOULD request a re-key.
To: Section 5.6 below notes that when a CA signs a certificate,
its certificate SHOULD have a validity interval that is at
least as long as the validity period of the certificate
being signed. This places additional constraints on when a
CA SHOULD request a re-key.
5.6 Key change over
Changed:
From: When a CA wishes to change keys, it MUST acquire a new
certificate containing the public key of its new key pair, well
in advance of the scheduled change of the current signature key
pair. The private key that a CA uses to sign a certificate or CRL
SHOULD have a validity period that is at least as long as that of
any certificate being issued under that certificate.
To: When a CA wishes to change keys, it MUST acquire a new
certificate containing its new public key, well in advance of
the scheduled change. This certificate SHOULD have a validity
period that is at least as long as that of any certificate
being issued under that certificate.
Added the following sections:
6.2.5. Private key archival
The details of the process and procedures used to archive the
CA's private key MUST be described in the CPS issued by the CA.
6.2.6. Private key transfer into or from a cryptographic module
The details of the process and procedures used to transfer the
CA's private key into or from a cryptographic module MUST be
described in the CPS issued by the CA.
6.2.7. Private key storage on cryptographic module
The details of the process and procedures used to store the CA's
private key on a cryptographic module and protect it from
unauthorized use MUST be described in the CPS issued by the CA.
6.2.8. Method of activating private key
The details of the process and procedures used to activate the
CA's private key MUST be described in the CPS issued by the CA.
6.2.9. Method of deactivating private key
The details of the process and procedures used to deactivate
the CA's private key MUST be described in the CPS issued by
the CA.
6.2.10. Method of destroying private key
The details of the process and procedures used to destroy the
CA's private key MUST be described in the CPS issued by the CA.
6.2.11. Cryptographic Module Rating
The security rating of the cryptographic module MUST be described
in the CPS issued by the CA.
6.4 Activation data
Each CA MUST document in its CPS how it will generate, install,
and protect its activation data.
6.5. Computer security controls
Changed
From: Each CA MUST document the technical security requirements it employs
for CA computer operation in its CPS.
To Each CA MUST document the technical security measures it employs
for CA computer operation in its CPS.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
