Jean-Marc Desperrier wrote:
Julien Pierre wrote:
You can however implement what you want without NSS changes, by wrapping the NSS certificate verification function.
By effectively reimplementing a certificate chain build algorithm.
Extending it is more like it, since you reuse the code that's aready there and don't reimplement all the other checks.
Your algorithm is simple, because it handles only simple cases, but full implementation of rfc3280, cross-certification, policy constraints, handling cert renewal where the old CA cert is signed by the new cert makes this more complex.
Cross-certification and policy constraints are explictly not supported by NSS at this time. You were only asking about a way of changing the CRL checking, and I provided you with an algorithm as a workaround. I do agree that to get to full RFC3280 compliance, the cert chain verification code in NSS needs to be rewritten. I can't predict whether that's going to happen or not.
I'd prefer to create a patch for NSS where :
- we can have an optionnal maximal age paramater for revocation information
Again, please see bugzilla 233806 about this.
- we can optionnally store a list of the CA up to the root with the revocation information for each of them.
Can you detail the format of such a list that you propose ? Where would you want to store it ? In the softoken (cert db) ?
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
