Open
Bug 387024
Opened 18 years ago
Updated 3 years ago
move certificate usage parameter to PKIX_ProcessingParams structure
Categories
(NSS :: Libraries, defect, P2)
NSS
Libraries
Tracking
(Not tracked)
NEW
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.
Reporter | ||
Updated•18 years ago
|
Assignee: nobody → alexei.volkov.bugs
Whiteboard: PKIX
Comment 1•18 years ago
|
||
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.
Comment 2•18 years ago
|
||
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.
Comment 3•18 years ago
|
||
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.
Comment 4•18 years ago
|
||
> 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.
Updated•18 years ago
|
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
Reporter | ||
Updated•18 years ago
|
Priority: P2 → P1
Reporter | ||
Updated•18 years ago
|
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
Updated•18 years ago
|
Summary: Make required certificate usage to be a part of PKIX_ProcessingParams structure → move certificate usage parameter to PKIX_ProcessingParams structure
Updated•18 years ago
|
Priority: P1 → P2
Updated•17 years ago
|
Target Milestone: 3.12 → 3.12.2
Comment 6•16 years ago
|
||
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12.2 → ---
Comment 7•3 years ago
|
||
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)
Updated•3 years ago
|
Severity: normal → S3
Comment 8•3 years ago
|
||
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.
Description
•