[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KeyNote draft available
>One other point - it appears that all authorizations can be delegated
>indefinitely, right? If one key grants an authority to a second, the
>second key can pass the authority on to a third in any way it likes?
>
>In the CA example, KeyNote accepts:
>
> $action_signer = "dsa-sha1-pkcsX:6:01a32f"
> $app_domain = "RFC822-EMAIL"
> $address="mab@keynote.research.att.com"
> $name="M. Blaze"
>
>but if there were an additional credential:
>
> VERSION: 1
> SIGNER: dsa-sha1-pkcsX:6:01a32f
> KEY-PREDICATE: rsa-sha1-pkcsX:6:112233
> TRUST-PREDICATE: true
> SIGNATURE: dsa-sha1-pkcsX:10:f43a2c81ffea129d
>
>this would allow key 01a32f to pass its authority on to key 112233.
>
>So KeyNote would then also accept:
>
> $action_signer = "rsa-sha1-pkcsX:6:112233"
> $app_domain = "RFC822-EMAIL"
> $address="mab@keynote.research.att.com"
> $name="M. Blaze"
>
>and the end user has the power to bind his name to alternate keys?
>
>In some contexts this may be permissible and appropriate, but perhaps
>not in others, if the end users are not trusted.
Yes, that's correct. But a credential that doesn't want to allow
deligation can test that the value of $action_signers is the same
as the key being authorized. (This is admitedly a bit subtle, but
seems clearner than including an explict mechanism for this. If
people insist, we could also include some kind of $cert_depth
magic variable that gives the "distance" from the action_signers.
But I'd have to think about the implications of doing this).
-matt
>Perhaps it would be the application's responsibility to make sure that
>it only provides appropriate credentials, and in this case it should
>not have provided that last one?
>
>Hal
Follow-Ups:
References: