Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: Mac OS X code signing suggestions?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mac OS X code signing suggestions?

Hi Perry,

Thanks for this info.

I have one more question.

I have a certificate chain that I want to verify. I want to make sure that the leaf certificate comes from me, and that the root certificate is a trusted root CA (i.e., it is in X509Anchors).

Can you give me some API hints on how best to do this?

Thanks,
Jamie

From: Perry The Cynic <email@hidden>
To: Jamie Wood <email@hidden>
CC: email@hidden
Subject: Re: Mac OS X code signing suggestions?
Date: Wed, 10 Nov 2004 15:51:08 -0800

--On Wednesday, November 10, 2004 3:02 PM -0800 Jamie Wood <email@hidden> wrote:

> The "codesigning" value of the extended key usage extension is
> explicitly  designed to cover signing executable stuff. It would be a
> reasonable policy  to only accept code signed with a certificate that
> has this usage enabled  (following the usual X509 rules and profiles).
> You will find that Verisign  et al charge rather larger fees for code
> signing certificates, on the  grounds that you're probably a
> corporation that can afford it. (There is  arguably also a greater risk
> of lawsuits associated with those.)
>
> The manifest APIs in Tiger will, by default, verify against the X509
> Generic policy and thus accept any (valid) certificate. They have
> provisions to break out the certificate validation step so you can hack
> it  any way you like.
>

So, in Tiger I will be able to sign my code with a JavaSoft certificate
and write my client so that Tiger will accept it, by modifiying the
verification process so that it handles JavaSoft certificates? Or, will I
have to ask Verisign to just give me a "generic" code signing certificate
(if such a thing exists)?

Careful here. "Tiger" does not accept or reject anything. The system does not, as of Tiger, *require* that you sign code, and it will ignore any signatures applied to your bundles. It's up to you to call APIs to verify any signatures as you see fit.

Note (since you brought up Java) that the Java programming environment may have its own idea of signing and verifying Java code, which is entirely separate and independent from the Manifest APIs we're discussing, and is only used within the Java environment.

With that proviso, any code signing cert should do. In fact, any cert without an "extended key usage" extension will do, too, because the default is "if the extension is absent, it allows anything." (Any CA handing out such certificates today ought to be flogged, of course.)

If I use the Generic policy, will I be able to sign my code with any
certificate and verify it using the manifest APIs, even if the
certificate does not have a code signing extension?

Yes. The "X509 Generic" policy just verifies the cryptographic integrity of the cert chain. It does not impose any other constraints on the certificate, other than self-consistency (e.g. CA certs with extended usage extensions must be consistent with the certs they sign).

Cheers
-- perry
---------------------------------------------------------------------------
Perry The Cynic email@hidden
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
---------------------------------------------------------------------------



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden







References: 


 >Re: Mac OS X code signing suggestions? (From: Perry The Cynic <email@hidden>)























Visit the Apple Store online or at retail locations.

1-800-MY-APPLE


Contact Apple | Terms of Use | Privacy Policy


Copyright © 2011 Apple Inc. All rights reserved.