In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > John, > > I'm glad you brought this discussion to this newsgroup. > > As we discussed previously, the spec for downloading CA certs via > application/x-x509-ca-cert > http://wp.netscape.com/eng/security/comm4-cert-download.html#chains > says that the first of the certs in the PKCS7 signed data package is > treated as a root CA cert, with the user having an opportunity to edit > the trust flags, and the rest of the CAs in the package are installed as > untrusted intermediate CAs. > > The behavior you reported observing with mozilla was that the LAST cert > in the PKCS7 package is treated as the root CA, with an option to edit > the trust, and the other certs were treated as untrusted intermediate > CA certs. > > So, there is a discrepancy between the spec (which was originally written > for Communicator 4.0) and the mozilla behavior. > > The question in my mind is whether Communicator 4.0 followed the spec > (which means that Communicator 4.x and mozilla behave differently given > the same PKCS7 input), or whether both Communicator and mozilla behave > essentially the same. > > If the two programs behave differently, then one of them has a bug. > Clearly there can only be one right behavior for that MIME type. If the > two programs behave the same, then we can argue that both programs are > right and the spec itself simply needs to be revised to match the programs' > consistent behavior. >
When I saw that message I did some tests myself. If the certificates are reordered so the root CA is last it still gives the dialog allowing the intermediate CA trust to be edited, even though its now first and the root CA last. My initial thought was that this might be a SET OF reordering issue which would make the smallest certificate first. However a Netscape certificate sequence behaves in the same way. Just to add to the confusion I've just created a pair of test certificates one 512 bit the other 1024 bit and in this case whichever is first gets the trust edit dialog. Steve.
