Signature MetadataFilter, name, CA, CRL comparison

[Marc Thornton]

>  I haven't been able to configure it in an way that works?  I don't have
> >control over the incoming metadata and the inclusion of
> >Shibboleth-specific extensions, therefore I am using StaticPKIX.
> I don't know whether you're talking about metadata verification or runtime
> trust, but those are two different things. The static engine is usually
> inappropriate for runtime trust, it's too rigid for most deployments.
> There are no Shibboleth extensions relevant to metadata verification, so
> you're apparently mixing models.
>
When I spoke of metadata, I meant the metadata extensions identified in the
TrustEngine documentation, which would be used at runtime for  SAML Request
signature validation.

Unfortunately, I seem to be stuck in a catch-22 based on the current
implementation for CRL validation though.  The certificates we are forced
to deal with use a DirName CRL Distribution Point, which identifies a DN
where that particular certificate's CRL can be downloaded (can be different
for each certificate).  Since neither OpenSSL, nor Shibboleth support this
extension, I have a process in place to periodically download the CRL and
place it in a local file. In processing the StaticPKIX TrustEngine with
this local CRL path and checkRevocation set to "entityOnly" or "fullChain",
I get the following error in the logs:
   OpenSSL [3]: path validation failure: unhandled critical CRL extension

I am assuming it refers to the DirName CRL extension ie
      X509v3 CRL Distribution Points:
                DirName:

Short of a customization to the xml-tooling call to OpenSSL's verify_cert
call to ignore missing "critical extensions", it seems I am out of luck on
implementing CRL validation with this type of cert?

Marc




>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20111220/9b05a90c/attachment.html