Yes, extensions aren't copied from a signing certificate to a signed
certificate because there generally is no need to as that signing
certificate is still in the certificate chain.
Look closely at the delegated credentials - you'll see there are at
least two certificates, one of which will be the certificate into
which you embedded the extensions, so you can access the extensions
by walking the certificate chain.
The function gss_inquire_cred_by_oid() should return your extensions
for you.
Von
On Jul 31, 2007, at 10:41 AM, Vineela M wrote:
Hello,
I am trying to understand how context establishment and delegation
works.
Here's what I have so far, I have a client and the server which are
set to establish a security context (using gss_init_sec_context,
gss_accept_sec_context,...).
and delegation.
So far so good, but here's what I have trouble with.
I have obtained an X.509 proxy credential for the client with non-
critical extensions. I replaced the client's proxy /tmp/x509_upxxx
with the new proxy which has non-critical extensions.
When I check the delegated credential received by the server, the
received client's credential does not have any non-critical extension.
It seems like the non-critical extensions are just ignored.
Is it supposed to be that way?
Is there a function the client/server need to invoke so that the
non-critical extensions present in the client's proxy credential
will be delegated?
I have tried changing the non-critical extension to critical
extension and then used gss_set_sec_context_option with
APPLICATION_WILL_HANDLE_EXTENSIONS parameter.
But it fails and reports that it cannot verify the credential.
Can some one tell me how the server can obtain the extension part
from the client?
Thanks in advance.
Regards,
Vineela Muppavarapu.
See what you’re getting into…before you go there. Check it out!
