On 7/23/08, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 23/07/2008, at 4:23 AM, Robert Burrell Donkin wrote: > >> On Fri, Jul 11, 2008 at 5:42 PM, Brett Porter <[EMAIL PROTECTED]> >> wrote: >>> Hi, >>> >>> I've wanted to pick up my work on this for some time and was >>> prodded by the >>> [EMAIL PROTECTED] threads to take another crack at this. >>> >>> http://docs.codehaus.org/display/MAVEN/Repository+Security (the >>> issue and >>> related branches are linked) >> >> (sorry for picking this up late) >> >> in general, definitely worth implementing and a big improvement >> >> there are some weaknesses in a single set of trusted keys: it's a very >> coursely grained trust model. i may trust B1313DE2 to sign commons and >> JAMES releases but not maven ones. the owner of B1313DE2 may be >> expelled from apache.org but there is no way for an organisation to >> automatically inform the user that this key is not longer to be >> trusted for their releases. signed meta-data is one way to approach >> this problem. > > Right. I do have a section at the bottom where you can trust only > certain people for certain keys that you've picked up below, but it > was rightly pointed out that might be overkill. > > We do need a specific answer to your described story, and it also > applies in the other direction - you don't want to have to load every > Apache committers key to say you trust everything from Apache. I > haven't fully investigated the security implications of using role > keys to sign others. > >> >> >>> Per-artifact settings >>> >>> By default, all keys in the user's keyring will be accepted. >>> However, to strengthen a requirement, >>> a project may require that the key be a particular one, or signed >>> by a particular key. The key >>> provided might be either an email address or the key ID. >> >> identifier used: >> a. definitely shouldn't be the email address since this is trivial >> to fake >> b. collisions are possible between Key IDs and (given an ID) it may >> be possible to construct a colliding key though this would be >> definitely non-trivial >> c. recommended that the fingerprint is used (the Key ID is derivable >> from it) > > These are all intended to be a user convenience for specifying them, > and it's the users responsibility to get the right key into their > keyring for the given identifier. > > Certainly any mechanism that helps retrieve a key to add to the > keyring should be verifying the fingerprint. > > Do keyrings support adding multiple keys with the same ID but > different fingerprints? I didn't know that was an issue.
Unintentionally generated two keys with the same ID is very unlikely. So I'm not sure what would happen if two were added to a client. However, intentionally generating a key with the same ID is a possible attack vector. AIUI the fingerprint is strong enough for this attack to be unfeasible and the fingerprint needs to be checked. > >> >> >>> Web of Trust >>> >>> Initially, the user will be required to explicitly add keys to >>> their keyring that they accept. >> >> this may need a little more thought. adding keys to the rings only >> allows a signature to be verified. only signed keys are trusted and >> this is a separate action. checking signatures is worthwhile even if >> the singature is untrusted: though a valid untrusted signature does >> not allow for positive validation, if the signature is invalid even >> when the signature is untrusted this indicates an attack of some kind. >> >> in general, i think that automatic download is very important for >> usability. in my experience, users often have problems understanding >> key servers. > > I agree this area needs more thought (and it's similar to your first > point). > > WoT won't be sufficient on it's own as most users have never had > contact with other signers. However it does need to be used for > automatically downloading keys (which does make it much easier to use, > for certain). > >> >> >>> The key should be downloaded from a trusted keyserver or KEYS file >>> (as specified in settings.xml above), not from the repository that >>> the artifact is being downloaded from. >> >> this may need more thought. these distribution mechanisms are >> typically intended to just distribute keys without gaurantees. > > I think getting KEYS (not automatically) from the original web server > should be satisfactory to most users in terms of trustworthiness. It > was poorly worded in that it looked like that might be a transparent > action where it's not though. I would only trust KEYS for a particular purpose, not generally Robert > >> >> >> another weakness when not using keyservers is how revocation >> certificates can be distributed. > > This is true. > > Thanks for the feedback! > > Cheers, > Brett > > >> >> >> - robert >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
