Comments on draft-ietf-pkix-rfc3280bis-01.txt

1. Comments on draft-ietf-pkix-rfc3280bis-01.txt IETF PKIX Meeting Paris - August 2005 Denis Pinkas (Denis.Pinkas@bull.net)

2. Topics that will be addressed • Root key update, • keyUsage (NR/CC bit), • privateKey Usage period • Ambiguity in naming, • CRL checking, • Indirect CRLs, • « Delegated CRLs » and « Indirect CRLs ».

3. Root CA key update • RFC 2510 “Certificate Management Protocols” contains text « buried » there. • Root key change is not a client-server protocol, since it can simply be performed by placing static data in a repository: • "old with new" certificate, • "new with new" certificate, • "new with old" certificate. • In order to promote root key changes, the text should be placed (and adapted) inside 3280bis. • A text proposal to adapt the text from RFC 2510 has been sent to the mailing list on November 15, 2004.

4. keyUsage (NR/CC bit) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • « The nonRepudiation bit is asserted when the subject public key is used to verify digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), used to provide a non-repudiation service which protects against the signing entity falsely denying some action. In the case of later conflict, a reliable third party may determine the authenticity of the signed data ». • Proposal for a compromise with X.509 2000)/Cor.3 (04/2004): • « The contentCommitment bit is asserted when the subject public key is used to verify digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6) and is intended to signal that the signer is intending to commit to the content being signed. In the case of later conflict, this may help a non-repudiation service provider to determine if the subject's claimed repudiation is true or false ».

5. privateKeyUsagePeriod • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • “D.1 Private Key Usage Period This extension SHOULD NOT be used within the Internet PKI. (…) CAs conforming to this profile MUST NOT generate certificates with private key usage period extensions unless at least one of the two components is present and the extension is non-critical.” • A discussion on the list indicated in 2003 that this was useful for HSMs and, even more, for Time-Stamping Units. • PrivateKeyUsagePeriod should be allowed /RECOMMENDED for HSMs and TSUs.

6. Ambiguity in naming (1/2) • A detailed response was sent to Tim on July 18. • Name collisions problems may exist for leaf certificates, CA certificates and CRL certificates. • Problems for CA certificates and CRL certificates arise only *during* the path verification algorithm. • Once a leaf certificate has been verified to be valid, the output of the path verification algorithm is a sequence of certificates up to a given trust anchor. • A major issue is that RFC 3280 does not provide the full certification path as an output of the validation algorithm and is silent about what to do with it. • Leaf certificates may be used in two contexts: a) access control or end-entity authentication, b) non repudiation.

7. Ambiguity in naming (2/2) • Mail from Steve Kent the same day : “I appreciate your comments on subtle issues associated with name collisions, and how these issues differ for ACL or end entity authentication use vs. non-repudiation use”. “I don't think 3280 or its successor should be providing detailed guidance for application developers re use of certs. But but another document, maybe a BCP, would be a good lace to do this. One could discuss in more detail the question of what constitutes a safe ACL entry or a suitable name to display for a received e-mail message, etc. Similar example could be provided for NR application contexts”. • A BCP (Best Current Practice), or a BCR (Best Current Recommendation) ? • A warning in the security considerations section, pointing to an informative annex would also be appropriate.

8. CRL checking (conforming clauses) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • « Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure when processing CRLs that are issued in conformance with this profile ». • There should be separate sections addressing the processing that MUST be supported by Relying Parties supporting : • mandatory-to-support extensions, • non-mandatory-to-support extensions.

9. CRL checking (incorrect state input) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • « This algorithm assumes that all of the needed CRLsare available in a local cache. • « This algorithm begins by assuming the certificate is not revoked. The algorithm checks one or more CRLs until either the certificate status is determined to be revoked  […] ». • The current text is incorrect : • “If the revocation status remains undetermined, then return the cert_status UNDETERMINED”. • In practice all the needed CRLs may not be in the cache, so the algorithm should start (and finish) with « UNDETERMINED ».

10. CRL checking (cache) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • « This algorithm assumes that all of the needed CRLs are available in a local cache. Further, if the next update time of a CRL has passed, the algorithm assumes a mechanism to fetch a current CRL and place it in the local CRL cache. » • If the cache contains an old CRL (which is a “needed CRL”) where SN of the target certificate is present, the current result of the algorithm is “UNDETERMINED”, instead of “REVOKED”. • If the cache contains two valid CRLs, the most recent CRL will not necessarily be used. The result of the algorithm may be “NOT_REVOKED”, instead of “REVOKED”. • The algorithm needs to be modified to take into consideration theses two cases. CRL 1 CRL 0 CRL 2 Current time

11. CRL checking (input parameter) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : “6.3.1 Revocation Inputs To support revocation processing, the algorithm requires two inputs: (a) certificate: The algorithm requires the certificate serial number and issuer name to determine whether a certificate is on a particular CRL. [ … ]” • This is insufficient. One input should be the full certification path.

12. CN = BestCA CN = BestCA CRL checking (signature verification) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : “(f) Obtain and validate the certification path for the issuer of thecomplete CRL. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set. (g) Validate the signature on the complete CRL using the public key validated in step (f)”. • It is unclear what means “validate the certification path for the issuer of the complete CRL”. • Because of possible CA or CRL name collisions,the “same sequence of DNs from the same TA as the one used to validate the target certificate” shall be used. • The revocation status of the CRL issuer certificate shall also be tested. TA

13. Indirect CRLs (5.3.4 Certificate Issuer) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • “When present, the certificate issuer CRL entry extension includes one or more names from the issuer field and/or issuer alternative name extension of the certificate that corresponds to the CRL entry”. • Extract from: draft-ietf-pkix-rfc3280bis-01.txt (4.2.1.14 CRL Distribution Points) : • “The cRLIssuer identifies the entity who signs and issues the CRL. If present, the cRLIssuer MUST contain at least one an X.500 distinguished name (DN), and MAY also contain other name forms”. • In section “4.2.1.7 Issuer Alternative Name” there is no requirement for uniqueness of IssuerAltName. • It is getting worse with name collisions ! • Please suppress “and/or issuer alternative name extension” .

14. Indirect CRLs (CA name ambiguity) • There is the need to add the following: • “In order to prevent CA DN ambiguity, a CRL Issuer SHALL not accept to manage revocation status information for a given CA DN, if it already manages revocation status information for another CA that has the same DN”.

15. Delegated CRLs and Indirect CRLs • Santosh : « If you want to propose a single delegated CRL, this must be done via a new extension or show how existing implementations can stay compliant with it ». • Response: Delegated CRLs may be supported • without a new extension, • by preserving backward compatibility (?). If a CRL Issuer (that is not a CA) inserts an IDP CRL extension, but only “works” for a single CA, RP software MAY work using the existingalgorithm, and MAY use a simpler piece of code. • Benefits: a simple piece of Relying Party code to support the simple case where a CRL Issuer is only “working” for one CA.

16. Two issues • Meaning of the indirectCRL boolean from the IDP extension. • What do we call “indirect CRL” ? The indirectCRL boolean is absolutely necessary to signal the presence of “certificate issuer CRL entry extensions”. The indirectCRL boolean is not necessary, if no “certificate issuer CRL entry extension” is present. • The name of the boolean could be changed to “multipleCAs”.

17. Indirect CRLs (reconciliation ?) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • “If the scope of the CRL only includes certificates issued by the CRL issuer then the indirectCRL boolean MUST be set to FALSE. Otherwise, if the scope of the CRL includes certificates issued by one or more authorities other than the CRL issuer, the indirectCRL boolean MUST be set to TRUE”. • Proposed replacement: • “If the issuing distribution point CRL extension is presentand if the scope of the CRL only includes certificates issued by a CA that is also the CRL Issuer, then the multipleCA boolean MUST be set to FALSE. • Otherwise, if the scope of the CRL includes certificates issued by more than one CA, the multipleCA boolean MUST be set to TRUE ”.

18. Indirect CRLs (vocabulary) • Extract from: draft-ietf-pkix-rfc3280bis-01.txt : • If the scope of the CRL includes one or more certificates issued by an entity other than the CRL issuer, then it is an indirect CRL. • Proposed replacement: • If the issuer of the CRL is a not a CA, or if the issuer of the CRL is a CA and the scope of the CRL includes certificates issued by one or more other CAs, then this CRL is called an indirect CRL. • A definition for “delegated CRL” might be: • A delegated CRL is an indirect CRL where the issuer of the CRL is not a CA and where the scope of the CRL only include certificates issued by one CA.

19. Indirect CRLs (to be noticed) • The two following sentences, extracted from draft-ietf-pkix-rfc3280bis-01.txt are not aligned : • If the scope of the CRL includes one or more certificates issued byan entity other than the CRL issuer, then it is an indirect CRL. • Otherwise, if the scope of the CRL includes …… certificates issuedby one or more authorities other than the CRL issuer, the indirectCRL boolean MUST be set to TRUE”. • Proposals to fix both sentences have been proposed in previous slides.