Also,  After taking a very quick look at the patch.

This requires a dependency on bouncycastle ( sort of the obvious choice ).
 But this means the core will depend on bouncycastle.

Les, what is the _policy_ for this type of dependency,   I don't think it
should be a core dep.

A couple of options are:
1.) Push this realm to its own sub-module.
2.) Mark the dep as optional/provided/etc ( not a big fan of this one )
3.) Nothing, leave it as a dep


On Mon, May 24, 2010 at 1:11 PM, Brian Demers <[email protected]>wrote:

> Yeah, the comparing of two public keys confused me (still does actually)
> but I emailed the apache sshd list of conformation (hasn't hit the archive
> yet, so no link)
>
> Anyone else have any thoughts on these realms?
>
>
> On Mon, May 24, 2010 at 12:56 PM, Paul Merlin <[email protected]> wrote:
>
>> Le lundi 24 mai 2010 18:26:39, Brian Demers a écrit :
>> > Here is what we have:
>> >
>> http://github.com/sonatype/security/tree/master/security-realms/security-pu
>> > blic-key-realm/
>> >
>> > Note this just compare two public keys, ( so this assume something else
>> is
>> > doing the hand shaking with the private key )
>> >
>>
>> Thanks for sharing Brian.
>>
>> Some things are similar to my implementation (already attached as a patch
>> in
>> jira). Looking at PublicKeyWithEquals, it could be related to my second
>> matching
>> strategy, fingerprint, except that you compare the public key data
>> (pk.getEncoded()) and not the certificate data.
>>
>> Be aware that a KeyPair can be certified several times and so a PublicKey
>> can be
>> used in several X509Certificate 'instances'.
>>
>> IOW the ssl engine had the proof that the client own the PrivateKey and
>> that
>> it's certificate is trusted. You then match only the PublicKey that's
>> inside the
>> certificate, not the certificate itself.
>>
>> Use cases leading to a security hole in your implementation will certainly
>> by
>> awkward and depend a lot on deployment and certification policies but one
>> can
>> imagine such a scenario.
>>
>> We could say the very same about my Simple strategy.
>>
>> /Paul
>>
>>
>>
>

Reply via email to