Christian Eyrich wrote:
> I read through the bug, the source and the spec at > http://wp.netscape.com/eng/security/comm4-cert-download.html#communicator. > > Nelson said, that mozilla still honors that spec but either it doesn't > or I don't understand it right.
> For application/x-x509-email-cert: > - First cert has to be a user cert. Does this mean no self signed cert? > Or does it just mean the cA component has to be false and bits 5, 6, 7 > of netscape-cert-type must not be set?
In this case (x-x509-email-cert) it really only means that the cert is a valid cert for encryption of S/MIME emails. It's a valid SMIME email recipient cert, having the necessary extensions and names for that purpose.
> - All other (following) certs in the data block have to be chained (i.e. > sign its forerunner) to the first cert?
IMO, that would be a reasonable requirement to impose, except that no order on the following certs has ever been imposed. The test is (has been): can a valid chain be formed with these certs?
> - All other (if correctly chained) have to be inserted in the Authority tab?
Must be CA certs. What tab they appear in is not part of the definition of the cert import.
> For application/x-x509-ca-cert: > - Is Mozilla supposed to import several certs that aren't chained?
The intent here is that the first cert is a root CA, and the ones following it may be subordinate to it. They may or may not form a single chain. This mime type is used to import a ROOT CA cert, and other CA certs that, while not explicitly trusted individually, should receive implicit transitive trust from their issuer when doing chain validation.
If the CA from which this package of certs is being imported is trustworthy, then the whole "package" of certs imported should be valid. If any cert in the package is invalid, that perhaps you really shouldn't trust this CA or ANY of the certs in the package.
> Generally: > - If not importing not chained certs, should Mozilla reject all certs in > that data block or only the non-chained?
I think it's reasonable to impose a requirement that x-x509-user-cert and x-x509-email-cert import a single chain, but not necessarily an ordered one (For backward compatiblity). For those MIME types, I'd say just discard any certs not part of a valid chain.
> BTW, does the comment in CERT_ImportCerts at #2273 and following > "if we are importing only a single cert and specifying a nickname, we > want to use that nickname if it a CA" match the code? > To me it looks like it's possible the nickname (not canickname) gets > assigned while adding to perm also if it's no CACert.
Originally, the test did not include the "&& (fcerts > 1)" part. The comment is attempting to supply a justification for the addition of that part of the test. Clearly, it would be better if the comment attempted to explain that the code is trying to achieve for all cases, and not only for that one. That code appears to be as presently intended.
/Nelson _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
