Juan Lang : crypt32: Remove an unnecessary test for the extended key usage extension in CA certificates .

Alexandre Julliard julliard at winehq.org
Wed Nov 18 09:40:40 CST 2009


Module: wine
Branch: master
Commit: 96073d51298e835df6880df6e91a576c675afa08
URL:    http://source.winehq.org/git/wine.git/?a=commit;h=96073d51298e835df6880df6e91a576c675afa08

Author: Juan Lang <juan.lang at gmail.com>
Date:   Tue Nov 17 14:40:08 2009 -0800

crypt32: Remove an unnecessary test for the extended key usage extension in CA certificates.

---

 dlls/crypt32/chain.c |   57 --------------------------------------------------
 1 files changed, 0 insertions(+), 57 deletions(-)

diff --git a/dlls/crypt32/chain.c b/dlls/crypt32/chain.c
index bb7a6e1..89c8e90 100644
--- a/dlls/crypt32/chain.c
+++ b/dlls/crypt32/chain.c
@@ -1604,58 +1604,6 @@ static BOOL CRYPT_KeyUsageValid(PCertificateChainEngine engine,
     return ret;
 }
 
-static BOOL CRYPT_ExtendedKeyUsageValidForCA(PCCERT_CONTEXT cert)
-{
-    PCERT_EXTENSION ext;
-    BOOL ret;
-
-    /* RFC 5280, section 4.2.1.12:  "In general, this extension will only
-     * appear in end entity certificates."  And, "If a certificate contains
-     * both a key usage extension and an extended key usage extension, then
-     * both extensions MUST be processed independently and the certificate MUST
-     * only be used for a purpose consistent with both extensions."  This seems
-     * to imply that it should be checked if present, and ignored if not.
-     * Unfortunately some CAs, e.g. the Thawte SGC CA, don't include the code
-     * signing extended key usage, whereas they do include the keyCertSign
-     * key usage.  Thus, when checking for a CA, we only require the
-     * code signing extended key usage if the extended key usage is critical.
-     */
-    ext = CertFindExtension(szOID_ENHANCED_KEY_USAGE,
-     cert->pCertInfo->cExtension, cert->pCertInfo->rgExtension);
-    if (ext && ext->fCritical)
-    {
-        CERT_ENHKEY_USAGE *usage;
-        DWORD size;
-
-        ret = CryptDecodeObjectEx(cert->dwCertEncodingType,
-         X509_ENHANCED_KEY_USAGE, ext->Value.pbData, ext->Value.cbData,
-         CRYPT_DECODE_ALLOC_FLAG, NULL, &usage, &size);
-        if (ret)
-        {
-            DWORD i;
-
-            /* Explicitly require the code signing extended key usage for a CA
-             * with an extended key usage extension.  That is, don't assume
-             * a cert is allowed to be a CA if it specifies the
-             * anyExtendedKeyUsage usage oid.  See again RFC 5280, section
-             * 4.2.1.12: "Applications that require the presence of a
-             * particular purpose MAY reject certificates that include the
-             * anyExtendedKeyUsage OID but not the particular OID expected for
-             * the application."
-             */
-            ret = FALSE;
-            for (i = 0; !ret && i < usage->cUsageIdentifier; i++)
-                if (!strcmp(usage->rgpszUsageIdentifier[i],
-                 szOID_PKIX_KP_CODE_SIGNING))
-                    ret = TRUE;
-            LocalFree(usage);
-        }
-    }
-    else
-        ret = TRUE;
-    return ret;
-}
-
 static BOOL CRYPT_CriticalExtensionsSupported(PCCERT_CONTEXT cert)
 {
     BOOL ret = TRUE;
@@ -1804,11 +1752,6 @@ static void CRYPT_CheckSimpleChain(PCertificateChainEngine engine,
          isRoot, constraints.fCA, i))
             chain->rgpElement[i]->TrustStatus.dwErrorStatus |=
              CERT_TRUST_IS_NOT_VALID_FOR_USAGE;
-        if (i != 0)
-            if (!CRYPT_ExtendedKeyUsageValidForCA(
-             chain->rgpElement[i]->pCertContext))
-                chain->rgpElement[i]->TrustStatus.dwErrorStatus |=
-                 CERT_TRUST_IS_NOT_VALID_FOR_USAGE;
         if (CRYPT_IsSimpleChainCyclic(chain))
         {
             /* If the chain is cyclic, then the path length constraints




More information about the wine-cvs mailing list