Yes. Renew'd certificates retain the same keypair. Perhaps I will have to write a document which tells how to recreate the cert issuance request with the same keypair (since, as long as the keypair is kept strictly confidential, there is no reason to create a new one).
G ________________________________________ From: Adam Kennedy [[email protected]] Sent: Wednesday, April 14, 2010 6:57 PM To: Garrett Serack Cc: [email protected] Subject: Re: [Coapp-developers] Let's talk about libraries Just to clarify (I'm not a huge crypto person) the key/spec remains stable across the annual cert renewal? For the big repos, a release rate of 1 per year or less is quite common for many small and mature/stable components. Adam K On 15 April 2010 11:40, Garrett Serack <[email protected]> wrote: > Yes, the manifest binding is that flexible. > > WinSXS manfiest policy files are incredibly flexible, and are designed to > support exactly this type of scenario. > > You can easily bind to version 1.2, and subsequent packages policy files > declare the version ranges that they are deemed to superceede. > > And, yeah, the certificate thumbprint (I should say 'publicKeyToken')* is > very stable--since the publisher has had to go to a CA to get the > certificate, it's highly unlikely that they would want to have new keys > reissued--which in this rare case would introduce a problem--I'm going to > talk to the WinSXS guys about that too. Oddly enough, a similar problem > arises in Digital Identity Technology. > > (*it's not actually a the thumbprint, it's the last 8 bytes of the SHA-1 > hash of the public key [uh, *that's* the thumbprint] as a 16 character > hexidecimal string.) > > I think we're aiming to have this a very painless process for > developers--you won't have to go digging for the pKT at all--the > SmartManifest tool will wire it up neatly for you. > > (I got a feelin' tomorrows first blog post will be all about WinSXS) > > G > ________________________________ > From: Adam Kennedy [[email protected]] > Sent: Wednesday, April 14, 2010 6:22 PM > To: Garrett Serack > Cc: [email protected] > Subject: Re: [Coapp-developers] Let's talk about libraries > > I'm less worried about the logistics of who does the signing than I am about > this... > > This manifest block is a dependency specification, but is it going to be > stable and flexible enough to be practical? > > Currently, the Linux shared libraries (from which code will be ported) > supports library dependencies of "1.2.latest" by depending on "1.2" instead > of "1.2.3". > > Is this going to support that level of wild-carding? Or if not can it be > emulated in the build farm? Also, if you are a third-party packager, will > the certificate thumbprint be stable over time. Or will I need to go search > a database somewhere every time I want to update a dependency to work out > what the matching thumbprint is? > > Adam K > > On 13 April 2010 03:49, Garrett Serack <[email protected]> wrote: >> >> In order for the consuming application to specify what library it is >> looking for, its manifest lists the certificate thumbprint, the name of the >> library and the version. > > _______________________________________________ > Mailing list: https://launchpad.net/~coapp-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~coapp-developers > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
