Sections 4.6, 4.7, 4.8 Certificate renewal, rekey, modification

[jaspenc]

Is the Device Root going to employ certificate renewal, rekey or modification for the certificates it issues? If so, these sections need to say so and the associated subsections need to be specified (by whom, under what circumstances, etc). If not, make that statement and the associated subsections become N/A.
If the Device Root does not intend to renew, rekey or modify, but will allow subordinate CAs to do so, then this needs to be explicit.

[lachellel]

@LarryFrank had submitted this (and all sub-sections):

For 4.6:

• CA and Subscriber certificates issued under the policy SHALL NOT be renewed.
• Short-lived On-Line Certificate Status Protocol (OCSP) Delegated responder certificates MAY be renewed.

For 4.7:

• allows for re-key
• Once a certificate has been rekeyed, the superseded certificate MAY or MAY NOT be revoked, but SHALL NOT be further re-keyed or modified.
• Subscribers SHALL identify themselves for the purpose of re-keying as required in Section 3.3.

For 4.8:

• Subscriber certificates SHALL NOT be modified.
• CA certificates MAY be modified to update attributes other than the public key.

[lachellel]

For 4.8 and comparison purposes:
Google

• Google does not modify previously issued certificates. Any request for modification will result in
  the renewed validation and issuance of a new certificate, as governed by sections 4.1 and 3.2.

Symantec

• Certificate modification refers to the application for the issuance of a new certificate due to changes in the information in an existing certificate (other than the subscriber’s public key). Certificate modification is considered a Certificate Application in terms of Section 4.1.

[lachellel]

Questions:

• 4.6: What is the mission need to make a distinction for OCSP signing certs? One policy reduces possibilities for errors and reduces auditing...is there a need?

• 4.7: Why allow for rekey?

  • If a rekey is allowed, shouldn't the superseded certificate be revoked no matter what?

• 4.8: Why allow for differences?

[LarryFrank]

•4.6: What is the mission need to make a distinction for OCSP signing certs? One policy reduces possibilities for errors and reduces auditing...is there a need?

No-check means an OCSP cert cannot (effectively) be revoked. To reduce the potential, issuing short lived OCSP certs is seen as a mitigation of that security threat. Renewal is a simple and effective way to allow CAs to easily issue new certificates every 30-45 days. DoD operates this was and has done soe effectively for several years.

◦If a rekey is allowed, shouldn't the superseded certificate be revoked no matter what?

Current federal policy and NISTR do not require it and, operationally, there is often a need for overlap to allow for smooth transition from the current certificate to a new one.

Why allow for differences?

DoD has found that having the ability to modify a CA cert allows for more flexibility in operations. Not requiring a new CA key to change a CA cert reduces complexity. Some products do not support this but some do. Subscriber certs - the difficulty in verifying attributes essentially creates the need for going through an initial authentication process anyway and there is no operational benefit.

[LarryFrank]

For 4.8 and comparison purposes:

Both are talking about subscriber certificates and I would agree with them on that. I made the exception for CA certs (CA/B baseline say "no stipulation", by the way) because DoD finds modification of CA certs to have been very useful. E.G., adding a policy OID to a CA cert - which has no impact on the issued certs, allows the CA to be used for a purpose that may not have been known at the time of original issuance and has no security impact. Not allowing modification (policy or technology) makes things much more complicated when the PKI needs to make changes.

[aakunz]

Just as a data point: while current AF PKI generally follows the DoD PKI for cert policy, we do rekey/renew differently. This is short extract from our current Root CA CPS: "Root CA certificates will be re-keyed ten (10) years after initial issuance, per Section 3.3. Re-keying the Root CA certificate involves issuing a new certificate that is identical to the old one but with a new, different public key (corresponding to a new, different private key) according to the schedule and steps listed in Section 4.2." AF PKI does not support cert renewal for any NPE (CA or other device).