[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on "shrinkwrap"
-----BEGIN PGP SIGNED MESSAGE-----
In message <Pine.NEB.3.95q.970827044137.244B-100000@pilari.ssh.fi>, Markku-Juha
ni Saarinen writes:
>> How would a client "do it itself?"
>
>Well, anyone with the right certs can do the reduction. And the client has
>to have them as he gives them to the server.
True, but the client can not produced a reduced certificate which will
be later on accepted by the verifier.
>Indeed I have (I suppose I'm the only person who has actually tried to
>implement it).
That may not be accurate.
>Well, [SPKI] doesn't say so. Actually some forms of certs (like ACL's) are
>always unsigned.
I thought it was rather obvious that only signed objects would be
transmitted. Sending unsigned ACLs/certs is begging for attacks.
>By the way, why do you talk about "certificate chains" when the <sequence>
>construct (4.2.6) is especially meant for this kind of use ?
>Suppose that I'm A and want to log to target machine B and I have a cert
>sequence originating from B that says that I can do that. When I'm trying
>to give this chain to B, E comes in and substitutes this sequence with
>an another that says X can log in. B reduces this and gives it back to me.
>Result: the service is denied from me.
But is the sequence signed such that its acceptable by B ?
Denying a service is easy. The questions are:
- - can X log on to B when he has no authorization for that ? (no)
- - can X make B produce arbitrary reduced certs ? (no)
I believe the confusion is raised by our not stating that all objects
transmitted must be signed. But ACLs are either signed (so they can be
transmitted) or are stored locally at the verifier, so that shouldn't
be a problem.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNAQtW70pBjh2h1kFAQGYugP/Qa2O3eOH4kB1ODwU+VbRd0ueQ4L3D1DJ
veGWFRk2OtDMiCmcOoVRV5Ji+HjCqeW5G8OUeWdJ5V9eTaW6AHZOz//FLFmFQkBc
atf9z3zNzcG/i4VyCRuU8sCZkZeikG8tLo0WA9lhRMmWkX2G2DGj+FuWLvTpSmet
VsU3l97cPXI=
=upas
-----END PGP SIGNATURE-----
Follow-Ups:
References: