Jean-Marc Desperrier wrote:
Nelson B wrote:
Jean-Marc Desperrier wrote:
In my tests, Communicator 4.x did not enforce the restriction you
describe in all case.
If the intermediate/root CA certs had no netscape cert type extension
at all, it was possible to enable then for "object signing" without
problems, despite a description implying they were required to
explicitly have it.
Very interesting. That would be a pretty serious flaw, and would
(I think) weaken the relative strength of the "Object Signing" OID
(as compared to the Code Signing OID).
I don't get how it weakens the "Object Signing" OID with regards to
"Code Signing OID".
It's the same behaviour as "Code Signing OID" where only the signing
cert requires the OID.
It may be that, but that is not how it was designed to be.
The design/intent was to require the EE cert and all intermediate CA
certs to have this extension/OID, and for the root to be trusted for
Object signing, in order for the EE cert to have object signing
permission.
In fact, everything is similar to Microsoft implementation of "Object
Signing" where one can too use the extended key usage to restricts the
ability of the CA to emit or not "Object Signing" certs, even if this
kind of use is not endorsed by pkix (I asked them when I was actually
interested in this and did the above test, and the consensus was eku
should apply to the cert, and not be herited when used for a CA cert,
and if this kind of CA restriction was really useful then a new key
usage would be better than diverting eku from it's original intend).
I'm not suggesting the design for netscape object signing was perfect,
merely stating what the design intent was.
--
Nelson B
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
