Quais são as desvantagens de usar policy_any em openssl.cnf?

Question

Conforme determinado neste documento , podemos usar policy_any para ignorar a maior parte do campos de subject em certificate request . Deve haver algumas desvantagens de ignorar esses campos, isso pode levar a alguns problemas relacionados à segurança?

O policy_any é dado como:

[ policy_any ]
 countryName            = supplied
 stateOrProvinceName    = optional
 organizationName       = optional
 organizationalUnitName = optional
 commonName             = supplied
 emailAddress           = optional

E se eu definir commonName = optional e countryName = optional também? É uma boa ideia usar policy_any ?

Obrigado pelo seu tempo!

    

Answer 1

A Política é simplesmente uma ajuda básica para organizar e verificar as solicitações de assinatura de certificados de entrada que seguem a política corporativa (ou, mais precisamente, a Política de Certificação (CP) e / ou Declaração de Práticas de Certificação (CPS) da organização).

Se você estiver assinando seus certificados na linha de comando, os benefícios de segurança serão insignificantes - afinal, você (ou outro usuário) poderia usar a opção -config <filename> do openssl para usar um arquivo de configuração alternativo e ignorar a política acima. Neste exemplo, pode ser útil pegar erros de digitação.

Por outro lado, se você estiver usando isso como parte de uma autoridade de certificação maior em que, por exemplo, os usuários enviam uma solicitação por meio de um portal da Web, essa seção de política pode ajudá-lo a obter solicitações de assinatura que não receberam todas os campos exigidos pela sua política corporativa.

Dito isso, se definido como supplied , como no seu exemplo, não é muito uma verificação, pois não verifica se as entradas são válidas ou seguem a política corporativa. Por exemplo, não verifica se há commonName de www.google.com quando sua organização é chamada acme.com!

Usar match em vez de supplied ajudaria com alguns dos campos, como você poderia, por exemplo, impor que organizationalUnit seja consistente nos certificados de sua organização. No entanto, você não pode usar match no campo commonName , pois isso deve mudar em cada certificado.

Restrições de nome podem ajudá-lo em determinados perfis de certificado.

No seu exemplo, alterar commonName e countryName para optional simplesmente impediria que eles fossem obrigatórios.

Observe que os campos que não estão nessa lista são removidos silenciosamente do certificado assinado. Ou seja, se sua solicitação tiver o campo generationQualifier definido como III , ele será removido do certificado (a menos que você use a opção preserveDN ).

A lista que você tem em sua pergunta é apenas um exemplo das páginas de documentação dos campos mais usados. Há muito mais campos possíveis que você pode usar, como initials , givenName e generationQualifier . Alguns estão listados no RFC 5280 e se eles não são exigentes o suficiente para suas necessidades, você pode até mesmo definir o seu próprio. Tudo o que o OpenSSL requer é que pelo menos um campo esteja presente.