> On Jan 22, 2018, at 9:39 PM, Jeffrey Walton <noloader@xxxxxxxxx> wrote: > > If OpenSSL want to change the standard so that it aligns with the > project's implementation then the project should go to LAMP. > Otherwise, the project is acting without authority. OpenSSL cannot > arbitrarily decide to do something else on a suggestion or a whim. There is no "authority", nor is there an "Internet police". > You know, this issue could have been side stepped by providing both > behaviors, making one default, and allowing the user to make the > choice. Instead, the project wrapped its arms around the solution that > broke interop. Actually, IIRC Mozilla's NSS and Microsoft's CAPI do the same thing. So it is unclear where exactly we're breaking "interop". > I can't help but wonder, doesn't anyone think these decisions through? This was thought through and discussed. I brought to the team's attention: http://www-archive.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html The following table shows the OIDs recognized in the extended key usage extension, and how they map to cert types and key usages for CA and non-CA certs. extended key usage OID non-CA cert CA cert ----------------------------------- -------------- ---------------- SEC_OID_EXT_KEY_USAGE_EMAIL_PROTECT EMAIL_CA EMAIL_CA SEC_OID_EXT_KEY_USAGE_SERVER_AUTH SSL_SERVER SSL_CA SEC_OID_EXT_KEY_USAGE_CLIENT_AUTH SSL_CLIENT SSL_CA SEC_OID_EXT_KEY_USAGE_CODE_SIGN OBJECT_SIGNING OBJECT_SIGNING_CA SEC_OID_EXT_KEY_USAGE_TIME_STAMP TIME_STAMP TIME_STAMP SEC_OID_OCSP_RESPONDER OCSP_RESPONDER OCSP_RESPONDER For CA certs in the cert chain, the requirements are: Cert Usage Requried Key Usage Required Cert Type -------------------- -------------------- ----------------------- SSLServerWithStepUp: GOVT_APPROVED AND CERT_SIGN; SSL_CA; SSLClient: CERT_SIGN; SSL_CA; SSLServer: CERT_SIGN; SSL_CA; SSLCA: CERT_SIGN; SSL_CA; EmailSigner: CERT_SIGN; EMAIL_CA or SSL_CA EmailRecipient: CERT_SIGN; EMAIL_CA or SSL_CA ObjectSigner: CERT_SIGN; OBJECT_SIGNING_CA; UsageAnyCA: CERT_SIGN; OBJECT_SIGNING_CA OR EMAIL_CA OR SSL_CA; When NSS is asked to verify the validity of a certificate chain, it verifies the validity of that cert chain for a particular purpose, known as a SECCertUsage, as of a specific date and time. The list of known SECCertUsages is short: certUsageSSLClient ........... An SSL client authentication cert certUsageSSLServer ........... An ordinary SSL server cert certUsageSSLServerWithStepUp.. An SSL server cert that allows export clients to use strong crypto. certUsageSSLCA ............... An intermediate or root CA cert allowed to issue SSL client or SSL server certs or other intermediate SSL CA certs. certUsageEmailSigner ......... Used to verify S/MIME email signatures certUsageEmailRecipient ...... Used to encrypt S/MIME emails. certUsageObjectSigner ........ Used to verify signatures on files of executable code, e.g. jar files. certUsageStatusResponder ..... Used by an OCSP responder certUsageVerifyCA ............ A CA of any kind. and: https://www.ietf.org/mail-archive/web/pkix/current/msg32409.html Frequently Asked Questions RFC 5280 reads "In general, this extension will appear only in end entity certificates". Is it non-standard to have EKU in intermediate certificates, and will client software break when receiving such a certificate chain? o Inclusion of EKU in CA certificates is generally allowed. NSS and CryptoAPI both treat the EKU extension in intermediate certificates as a constraint on the permitted EKU OIDs in end-entity certificates. Browsers and certificate client software have been using EKU in intermediate certificates, and it has been common for enterprise subordinate CAs in Windows environments to use EKU in their intermediate certificates to constrain certificate issuance. Therefore, it is unlikely that using EKU in intermediate certificates would break other client software. o The use of the EKU extension in intermediate certificates was discussed at length in the mozilla.dev.security.policy forum. We considered other options, such as standardizing a set of Policy OIDs or un-deprecating NetscapeCertType. The discussion included the concern that one interpretation of RFC 5280 is that this use of EKU is non-standard, but it was decided that the RFCs are not clear, and perhaps conflicting, in regards to EKUs in CA certificates. In the discussion it was pointed out that other major browsers and client software already support this use of EKU but do not recognize NetscapeCertType; and we also recognized the difficulties involved in standardizing a set of Policy OIDs. The conclusion of the discussion was that EKU is the best tool for technically constraining the types of certificates that an intermediate certificate may sign. I am sorry to hear that you're saddened by my lack of fealty to RFC5280, but I find real-world considerations more compelling. The OP in this thread has perfectly reasonable work-arounds, the main obstacle seems to be a language barrier more than anything else. Over and out. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
