Open Bug 387024 Opened 18 years ago Updated 3 years ago

move certificate usage parameter to PKIX_ProcessingParams structure

Categories

(NSS :: Libraries, defect, P2)

Tracking

(Not tracked)

People

(Reporter: alvolkov.bgs, Unassigned)

References

Details

(Whiteboard: PKIX)

Implementation of the function has the following lines: certificateUsage = ((PKIX_PL_NssContext*)plContext)->certificateUsage; /* convert SECertificateUsage (bit mask) to SECCertUsage (enum) */ while (0 != (certificateUsage = certificateUsage >> 1)) { certUsage++; } Later, required cert flags and trust type will be calculated based on certUsage. Conversion from SECCertificateUsage to SECCertUsage is done incorrectly as the first one may have more when one bit set.
Assignee: nobody → alexei.volkov.bugs
Whiteboard: PKIX
What are the semantics when more than one bit is set? It should probably be the same as CERT_VerifyCertificate: certificateUsage contains a bitfield of all cert usages that are required for verification to succeed I think this is doable with libpkix if a single anchor supports all the required usages. However, I think this will fail if multiple paths are used. For example, if you require SSL client and Email, and the cert chains up to multiple anchors, one of which is trusted for SSL client only, and the other is trusted for Email only, this will probably. But, this is probably not that disastrous.
SECCertificateUsage is a PRUInt64. My thinking was to provide two new APIs: PKIX_Error * PKIX_ProcessingParams_SetUsage( PKIX_ProcessingParams *params, PKIX_Int64 usage, void *plContext); PKIX_Error * PKIX_ProcessingParams_GetUsage( PKIX_ProcessingParams *params, PKIX_Int64 *usage, void *plContext); Where 'usage' is defined as "the types of certificate usage that the trust anchor must be trusted for. The usages are application-level, examples being email, ssl client, object signing etc." However, PKIX does not define a 64-bit type, and it does not currently pull in NSPR, so this API is not doable. Instead, I will probably suggest a simple -1 terminated PKIX_Int32 array of usages. PKIX_Error * PKIX_ProcessingParams_SetUsage( PKIX_ProcessingParams *params, PKIX_Int32 *usage, void *plContext); PKIX_Error * PKIX_ProcessingParams_GetUsage( PKIX_ProcessingParams *params, PKIX_Int32 **usage, void *plContext); Each element in the 'usage' array is a value from the SECCertUsageEnum space. In fact, we may have to mirror this out to the PKIX namespace. In CERT_VerifyCertificate, the usage flag is used for at least two things: 1) indicating the set of key_usage and extended_key_usage fields which should appear in the leaf cert 2) indicating which set of trust bits on the trust anchor we are interested in. PKIX already has a mechanism for doing 1) - via the PKIX_CertSel* interface, for example PKIX_ComCertSelParams_SetKeyUsage() and PKIX_ComCertSelParams_SetExtendedKeyUsage() , However, there is no mechanism (other than setting this global context flag for setting the trust flags used for 2). So, that's why my definition of usage only covers the trust bits, not extended key usage and key usage.
One more issue: PKIX_CertSel* is deficient if you want to check for multiple usages in one pass. For example, if I want to check for "sslClient" and "emailrecipient", I would have to set PKIX_ComCertSelParams_SetKeyUsage(params, KU_DIGITAL_SIGNATURE | KU_KEY_AGREEMENT_OR_ENCIPHERMENT ); and PKIX_ComCertSelParams_SetExtendedKeyUsage(params, NS_CERT_TYPE_SSL_CLIENT | NS_CERT_TYPE_EMAIL ); The problem is that this would pass a cert with KU_DIGITAL_SIGNATURE and NS_CERT_TYPE_EMAIL, which is wrong. So, with this reservation, and my comment #1, I don't think we can support multiple usages in a single pass at this time.
> I don't think we can support multiple usages in a single pass at this time. Right, Alexei and I also came to this conclusion last Friday. We propose to fix this, in the short term (e.g. for 3.12.0), by changing the new cert_VerifyCertificate to call cert_VerifyCert once for each selected usage. (And, obviously, changing cert_VerifyCert to NOT call cert_VerifyCertificate, but to call libPKIX directly, as cert_VerifyCertificate does now.) Then the code in libPKIX does not need to handle the multiple-usages-in-a-single-pass case at all (for 3.12.0). Note that this is no worse than the behavior of 3.11.x today, and should be faster than 3.11.x because of the fact that libPKIX caches verified cert chains, avoiding the need to verify their signatures a second time.
Priority: -- → P2
Summary: PKIX_PL_Cert_IsCertTrusted may return wrong answer if requested to verify more when one cert usage. → PKIX_PL_Cert_IsCertTrusted returns wrong answer when asked to verify multiple cert usages
Version: 3.12 → trunk
No longer blocks: 390888
Priority: P2 → P1
Summary: PKIX_PL_Cert_IsCertTrusted returns wrong answer when asked to verify multiple cert usages → Make required certificate usage to be a part of PKIX_ProcessingParams structure
Blocks: 391244
Summary: Make required certificate usage to be a part of PKIX_ProcessingParams structure → move certificate usage parameter to PKIX_ProcessingParams structure
Priority: P1 → P2
Target Milestone: 3.12 → 3.12.2
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12.2 → ---

The bug assignee is inactive on Bugzilla, and this bug has priority 'P2'.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

Assignee: alvolkov.bgs → nobody
Flags: needinfo?(bbeurdouche)
Severity: normal → S3

We have modified the bot to only consider P1 as high priority, so I'm cancelling the needinfo here.

Flags: needinfo?(bbeurdouche)
You need to log in before you can comment on or make changes to this bug.