anyone running an OCSP responder for InCommon CRLs?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

anyone running an OCSP responder for InCommon CRLs?

peter williams-3

If anyone has a public endpoint for an OCSP endpoint serving the operating organization’s realtime validation opinions on the certs reported on the InCommon CRL, do please share it.

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

Cantor, Scott E.
Peter Williams wrote on 2009-01-16:
> If anyone has a public endpoint for an OCSP endpoint serving the operating
> organization's realtime validation opinions on the certs reported on the
> InCommon CRL, do please share it.

InCommon no longer relies on PKI validation of its certificates for any
purpose, so the CRL is immaterial now. There is no real-time source of that
information other than the metadata.

You can shrink your window of exposure by refreshing the metadata more often
(in conjunction with a script that actually prevents injection of older
metadata by checking the SSL certificate at the publication point).
 
To my knowledge, there is no current proposal to offer a PKI through
InCommon other than for federation purposes (for which we do not rely on
PKI). If that changes, then obviously it's a different ballgame.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
Ok, in principle.

Some follow-ups:

1. if a Federation wants to use PKI for SAML protocols, can it do so with Shib (or is PKI simply now a legacy technology that Shib SPs should ignore)?

2. Is anyone running an OCSP server for the SSL certs offered by the ACS https endpoints published the signed InCommon metadata, as it serves (realtime, limited exposure) signed metadata

3. If the IDP receives a server cert from using ACS URL with a critical extension pointing to the OCSP endpoint (while posting a SAMLResponse, say) will it ignore it (and be "formally" non-complying)?

4. Do the InCommon rules countenance a Shib IDP operator to configure the IDP to be non compliance with PKI standard - when interworking with an SSL PKI-based ciphersuite?

For obvious reasons, there is no assurance of confidentiality from SSL if the SSL server entity has been spoofed...

5. Does Shib IDP enforce the rule that the reported DNS address of the actual ACS IP endpoint reported by its socket must match the cn= field in a cert bound to that SSL channel?


> -----Original Message-----
> From: Scott Cantor [mailto:[hidden email]]
> Sent: Friday, January 16, 2009 10:01 AM
> To: [hidden email]
> Subject: RE: [Shib-Users] anyone running an OCSP responder for InCommon
> CRLs?
>
> Peter Williams wrote on 2009-01-16:
> > If anyone has a public endpoint for an OCSP endpoint serving the
> operating
> > organization's realtime validation opinions on the certs reported on
> the
> > InCommon CRL, do please share it.
>
> InCommon no longer relies on PKI validation of its certificates for any
> purpose, so the CRL is immaterial now. There is no real-time source of
> that
> information other than the metadata.
>
> You can shrink your window of exposure by refreshing the metadata more
> often
> (in conjunction with a script that actually prevents injection of older
> metadata by checking the SSL certificate at the publication point).
>
> To my knowledge, there is no current proposal to offer a PKI through
> InCommon other than for federation purposes (for which we do not rely
> on
> PKI). If that changes, then obviously it's a different ballgame.
>
> -- Scott
>

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

Cantor, Scott E.
Peter Williams wrote on 2009-01-16:
> 1. if a Federation wants to use PKI for SAML protocols, can it do so with
> Shib (or is PKI simply now a legacy technology that Shib SPs should
ignore)?

Can it? Yeah, the code's there and it works (mostly). Should it? I doubt it,
unless you provide the expertise to fix and enhance what's there to your
standards.

OCSP for example isn't supported by me right now, for example and I have no
intention of adding that. In theory there might be OpenSSL bits for that,
but I never went looking.

CRL support is at least working in svn now, there was a bug that basically
prevented even what little I had done from running, which just reinforced my
attitude that this was a bad idea.

> 2. Is anyone running an OCSP server for the SSL certs offered by the ACS
> https endpoints published the signed InCommon metadata, as it serves
> (realtime, limited exposure) signed metadata

Those SSL certs are arbitrary (they're browser facing). Whether they're
valid or not is really a matter for the client. There are undoubtedly many
such responders, as many commercial CAs run them, but there cannot be one
server for them, and no SAML implementation is ever involved in validating
them in any case.
 
> 3. If the IDP receives a server cert from using ACS URL with a critical
> extension pointing to the OCSP endpoint (while posting a SAMLResponse,
say)
> will it ignore it (and be "formally" non-complying)?

The IdP doesn't talk to an ACS, the browser does.

> 4. Do the InCommon rules countenance a Shib IDP operator to configure the
> IDP to be non compliance with PKI standard - when interworking with an SSL
> PKI-based ciphersuite?

InCommon has nothing to say about it, and there is no standard to follow in
any case. All TLS does is deal with the crypto. The rest is out of its
scope, with the exception of server name validation, which InCommon requires
for the back-channel in the usual ways.
 
> 5. Does Shib IDP enforce the rule that the reported DNS address of the
> actual ACS IP endpoint reported by its socket must match the cn= field in
a
> cert bound to that SSL channel?

The IdP isn't involved. InCommon does not require people to use commercial
SSL certificates or to follow the rules browsers require for browser-facing
endpoints. Everybody does of course because they have to for practical
reasons.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
What about the https artifact resolution endpoints of the IDP? Will the SP follow or ignore a critical extensions in the realtime https server cert that the IDP's ARS supplies?

Presumably not. If the https or SAML software will never be completed to process CRLs/deltaCRLs/ARLs/deltaARLs, its seems unlike folks will focus on OCSP client libraries.

Im asking all this as I'm turning on the OCSP support in our own SAML2 SPs talking to our own IDPs, recognizing that I will probably need to shortly be talking to Paul's SAML server (based on recent Shib2 IDP code base). What his underlying Shib2 code cannot/will not support, obviously a given interworking interconnection deployment will just have to abandon. His SP partners will just have to accept the risk, mitigating using compensating controls.

As I today turn on OCSP client usage locally at the SP at the root/authority cert level, if my IDPs offering https-endpoints (for metadata recovery or ARS) are in the same SSL root domain as are his IDPs ARS https endpoints, I'm going to need to have the fallback code changed so I can specify _by IDP connection_ that IDP's failure to meet the OCSP policy is not deemed a failure (i..e the SP is set to fail open on missing OCSP assertions from a declared subset of IDP connections for recovering metadata or doing artifact resolution).

This whole issue set seems way beyond Liberty Interoperable, and absent rules set by a Federation any IDP/SP has every right to object to supporting features too onerous for its software baseline: such as cert validity, CRLs, OCSP, key lengths, ciphersuites, etc.


FYI: The basic "conforming" notion in the PKIX standards from IETF is rather similar to SAML and Shib ruleset: the inability to process a critical extension correctly requires the endpoint to consider the cert as missing; and proceed from there. This CAN mean the SP's https resolver goes to an alternative source of asymmetric keys (e.g. SAML metadata). If  Shib2 SP hascontrol over https resolution, there is nothing in https or SSL that would stop the SP using Shib metadata as a basis for https cert validity on a binding (much as its model applies certs in the pure SAML protocols)


> -----Original Message-----
> From: Scott Cantor [mailto:[hidden email]]
> Sent: Friday, January 16, 2009 10:53 AM
> To: [hidden email]
> Subject: RE: [Shib-Users] anyone running an OCSP responder for InCommon
> CRLs?
>
> Peter Williams wrote on 2009-01-16:
> > 1. if a Federation wants to use PKI for SAML protocols, can it do so
> with
> > Shib (or is PKI simply now a legacy technology that Shib SPs should
> ignore)?
>
> Can it? Yeah, the code's there and it works (mostly). Should it? I
> doubt it,
> unless you provide the expertise to fix and enhance what's there to
> your
> standards.
>
> OCSP for example isn't supported by me right now, for example and I
> have no
> intention of adding that. In theory there might be OpenSSL bits for
> that,
> but I never went looking.
>
> CRL support is at least working in svn now, there was a bug that
> basically
> prevented even what little I had done from running, which just
> reinforced my
> attitude that this was a bad idea.
>
> > 2. Is anyone running an OCSP server for the SSL certs offered by the
> ACS
> > https endpoints published the signed InCommon metadata, as it serves
> > (realtime, limited exposure) signed metadata
>
> Those SSL certs are arbitrary (they're browser facing). Whether they're
> valid or not is really a matter for the client. There are undoubtedly
> many
> such responders, as many commercial CAs run them, but there cannot be
> one
> server for them, and no SAML implementation is ever involved in
> validating
> them in any case.
>
> > 3. If the IDP receives a server cert from using ACS URL with a
> critical
> > extension pointing to the OCSP endpoint (while posting a
> SAMLResponse,
> say)
> > will it ignore it (and be "formally" non-complying)?
>
> The IdP doesn't talk to an ACS, the browser does.
>
> > 4. Do the InCommon rules countenance a Shib IDP operator to configure
> the
> > IDP to be non compliance with PKI standard - when interworking with
> an SSL
> > PKI-based ciphersuite?
>
> InCommon has nothing to say about it, and there is no standard to
> follow in
> any case. All TLS does is deal with the crypto. The rest is out of its
> scope, with the exception of server name validation, which InCommon
> requires
> for the back-channel in the usual ways.
>
> > 5. Does Shib IDP enforce the rule that the reported DNS address of
> the
> > actual ACS IP endpoint reported by its socket must match the cn=
> field in
> a
> > cert bound to that SSL channel?
>
> The IdP isn't involved. InCommon does not require people to use
> commercial
> SSL certificates or to follow the rules browsers require for browser-
> facing
> endpoints. Everybody does of course because they have to for practical
> reasons.
>
> -- Scott
>

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

Cantor, Scott E.
Peter Williams wrote on 2009-01-16:
> What about the https artifact resolution endpoints of the IDP? Will the SP
> follow or ignore a critical extensions in the realtime https server cert
> that the IDP's ARS supplies?

It will do whatever OpenSSL does when the built-in X509_verify function is
executed on the chain. If you want to know more, you'll have to ask them or
look at the code. To the best of my knowledge, it probably ignores most
extensions, critical or otherwise, and I have no code that overrides that
behavior. I believe it checks a few things like the CA flag, but not much
else besides the date(s). It also enforces things it shouldn't (such as not
allowing a non-self-signed trust anchor).

> Presumably not. If the https or SAML software will never be completed to
> process CRLs/deltaCRLs/ARLs/deltaARLs, its seems unlike folks will focus
on
> OCSP client libraries.

I have no intention of doing anything other than the CRL fixes that are in
the next release to get them working. If whatever else you're talking about
isn't built-in to OpenSSL's support for CRLs, then it's not coming from me.
OCSP may or may not be in OpenSSL, but I'm not doing it.

And none of that is Java, so if you want to know what the IdP can do, I
can't tell you. Sun's PKIX validator is supposedly "very complete". All I
know is the thing failed randomly on me once with a particular certificate
that worked for months prior, and I vowed never to trust it again.

> Im asking all this as I'm turning on the OCSP support in our own SAML2
> SPs talking to our own IDPs, recognizing that I will probably need to
> shortly be talking to Paul's SAML server (based on recent Shib2 IDP code
> base).

That's kind of immaterial then, because it's not my SP (I assume) and the
IdP code isn't really involved in what you do or don't do with the
certificate on your end.

> What his underlying Shib2 code cannot/will not support, obviously
> a given interworking interconnection deployment will just have to
> abandon. His SP partners will just have to accept the risk, mitigating
> using compensating controls.

As stated in this set of questions, the code in Shibboleth has nothing to do
with it, but your original question makes more sense. You would need nothing
from Shibboleth but would need OCSP for an InCommon-issued certificate (if
you're asking because the IdP in question is using one). I believe the
answer there is no, but it's more of a question for the InCommon admins, so
you could ask them via their contact address.

> This whole issue set seems way beyond Liberty Interoperable, and absent
> rules set by a Federation any IDP/SP has every right to object to
supporting
> features too onerous for its software baseline: such as cert validity,
CRLs,
> OCSP, key lengths, ciphersuites, etc.

Yes, and you can make that list much smaller without PKIX.

> FYI: The basic "conforming" notion in the PKIX standards from IETF is
rather
> similar to SAML and Shib ruleset: the inability to process a critical
> extension correctly requires the endpoint to consider the cert as missing;
> and proceed from there.

Yes, I'm aware of how extensions work, and if you think OpenSSL is wrongly
implementing their validation, I would take it up with them. Personally, I
do think it's broken, but if it weren't, people would never get certs to
work at all with it, which is really the whole problem to begin with.

> This CAN mean the SP's https resolver goes to an
> alternative source of asymmetric keys (e.g. SAML metadata). If  Shib2 SP
> hascontrol over https resolution, there is nothing in https or SSL that
> would stop the SP using Shib metadata as a basis for https cert validity
on
> a binding (much as its model applies certs in the pure SAML protocols)

That's exactly what it does, and has done so since the first release. Which
trust engine you configure determines what the process it uses is, though
the processes have changed over time in small ways to fix bugs or add
features.

You seem to be treating SSL as something "separate". It is not. If it is
being used as part of a SAML profile (server-side), it is a mistake to apply
different rules to the validation of a key used for signing or for TLS. We
strive for nearly 100% equivalence, and on the SP side we're pretty close.
On the IdP, we're stuck with mod_ssl's bugs in a few cases.

The only place in SAML where this is made explicit is probably the metadata
"use" attribute that equates SSL and signing, but I essentially think it's a
bug to ever treat them separately. At the very least, it's an inferior
approach that is unmanageable.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
> > Im asking all this as I'm turning on the OCSP support in our own
> SAML2
> > SPs talking to our own IDPs, recognizing that I will probably need to
> > shortly be talking to Paul's SAML server (based on recent Shib2 IDP
> code
> > base).
>
> That's kind of immaterial then, because it's not my SP (I assume) and
> the
> IdP code isn't really involved in what you do or don't do with the
> certificate on your end.

In Paul's case, I suspect the IDP metadata will be published on an endpoint of the IDP's server (rather than at an aggregation point like a Federation). If there are CRLs and OCSP involved, Ill guess that all such management (and any policy semantics) will all be delegated to a public CA or not be addressed (with a private CA).

Under the theory that the SAML endpoint is in control of SSL (since https resolution is a "binding" for which SAML metadata specifies the validity semantics - at least for ARS) if the IDP actually now provides a https cert chain with (critical) extensions to an ARS resolver, isn't it telling the resolver to perform the controls in those certs?

Or would you consider it to be quite permissible for a ARS resolver to ignore the CA cert flag in cert chain...and accept EE certs minted by the owner of the SSL server cert (by amending openssl, say)?

Now ARS endpoints are in the metadata (which can therefore specify semantics for ARS endpoints); whereas as the URL of the metadata itself is not (arguably). Does the rationale for ARS all pertain to the handling of metadata itself, when recovered over https?

I suppose, technically, metadata recovery is not tied to a "SAML binding", unlike use of an ARS. Metadata recovery is just a regular use of https, where semantics  are defined by the some combination of the cert issuer and whatever technical controls the relying party software happens to implement, on some host or other.

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

Cantor, Scott E.
Peter Williams wrote on 2009-01-16:
> Under the theory that the SAML endpoint is in control of SSL (since https

This is a philosophical distinction that doesn't help in the real world. If
you can't assume anything about the code running at the other end of the SSL
pipe, then the pipe itself offers nothing. It's true for the web servers
your bank runs just as much as a SAML server.

> resolution is a "binding" for which SAML metadata specifies the validity
> semantics - at least for ARS) if the IDP actually now provides a https
cert
> chain with (critical) extensions to an ARS resolver, isn't it telling the
> resolver to perform the controls in those certs?

SAML doesn't require any particular rules, and neither does TLS. The process
of certificate validation is up to the relying party and whatever rules it
wants to follow. In SAML, the rules are out of scope, so there is no
assumption anywhere about what a certificate means absent a profile for what
it means.

If you're asking whether I'd rather use bare keys SSH-style so that I don't
have to keep reminding people this, the answer is heck yes but that option
just isn't open in practical terms.

Now, OTOH, if you're suggesting that it's a bad idea to rely on a trust
engine that purports to follow PKIX and doesn't do it properly, I'm totally
in agreement there. I urge nobody to use that code if they can avoid it.

> Or would you consider it to be quite permissible for a ARS resolver to
> ignore the CA cert flag in cert chain...and accept EE certs minted by the
> owner of the SSL server cert (by amending openssl, say)?

Permissible in SAML? Absolutely; anybody that thinks otherwise can feel free
to point me at the text I supposedly wrote that says this. Wise? Probably
not.

I think what matters is clarity and openness of the process, and I will
totally agree that the fact that I can't even tell you what OpenSSL will do
half the time is a pretty good sign that that code is dangerous to use.

> Now ARS endpoints are in the metadata (which can therefore specify
semantics
> for ARS endpoints); whereas as the URL of the metadata itself is not
> (arguably).

Absolutely true.

> Does the rationale for ARS all pertain to the handling of
> metadata itself, when recovered over https?

Depends what you mean by rationale. The spec says nothing about what you
have to do with a certificate used within SAML profiles, and it also says
nothing about it for metadata exchange. Now, does that imply that any given
technique is reasonable for both? No, of course not.
 
> I suppose, technically, metadata recovery is not tied to a "SAML binding",
> unlike use of an ARS.

No, it's not.

> Metadata recovery is just a regular use of https,
> where semantics  are defined by the some combination of the cert issuer
and
> whatever technical controls the relying party software happens to
implement,
> on some host or other.

It *can* be that. It can also be something entirely different that ignores
https, as with most federations using Shibboleth today.

The first step is to stop making everybody's life painful at runtime and use
metadata. Then you can solve the metadata exchange problem deliberately and
with care, with far more options for code to use.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
In reply to this post by Cantor, Scott E.
Is it also shib philosophy that on preparing an encrypted assertion for a recipient with a cert, that any signing-only keyusage in the SHOULD be ignored by the IDP?

or is the profile rule stronger: MUST be ignored?

One way to do this is to simple cause openssl/cert libraries to regard the certificate as v1, rather than v3.



> -----Original Message-----
> From: Peter Williams
> Sent: Friday, January 16, 2009 11:26 AM
> To: [hidden email]
> Subject: RE: [Shib-Users] anyone running an OCSP responder for InCommon
> CRLs?
>
> What about the https artifact resolution endpoints of the IDP? Will the
> SP follow or ignore a critical extensions in the realtime https server
> cert that the IDP's ARS supplies?
>
> Presumably not. If the https or SAML software will never be completed
> to process CRLs/deltaCRLs/ARLs/deltaARLs, its seems unlike folks will
> focus on OCSP client libraries.
>
> Im asking all this as I'm turning on the OCSP support in our own SAML2
> SPs talking to our own IDPs, recognizing that I will probably need to
> shortly be talking to Paul's SAML server (based on recent Shib2 IDP
> code base). What his underlying Shib2 code cannot/will not support,
> obviously a given interworking interconnection deployment will just
> have to abandon. His SP partners will just have to accept the risk,
> mitigating using compensating controls.
>
> As I today turn on OCSP client usage locally at the SP at the
> root/authority cert level, if my IDPs offering https-endpoints (for
> metadata recovery or ARS) are in the same SSL root domain as are his
> IDPs ARS https endpoints, I'm going to need to have the fallback code
> changed so I can specify _by IDP connection_ that IDP's failure to meet
> the OCSP policy is not deemed a failure (i..e the SP is set to fail
> open on missing OCSP assertions from a declared subset of IDP
> connections for recovering metadata or doing artifact resolution).
>
> This whole issue set seems way beyond Liberty Interoperable, and absent
> rules set by a Federation any IDP/SP has every right to object to
> supporting features too onerous for its software baseline: such as cert
> validity, CRLs, OCSP, key lengths, ciphersuites, etc.
>
>
> FYI: The basic "conforming" notion in the PKIX standards from IETF is
> rather similar to SAML and Shib ruleset: the inability to process a
> critical extension correctly requires the endpoint to consider the cert
> as missing; and proceed from there. This CAN mean the SP's https
> resolver goes to an alternative source of asymmetric keys (e.g. SAML
> metadata). If  Shib2 SP hascontrol over https resolution, there is
> nothing in https or SSL that would stop the SP using Shib metadata as a
> basis for https cert validity on a binding (much as its model applies
> certs in the pure SAML protocols)
>
>
> > -----Original Message-----
> > From: Scott Cantor [mailto:[hidden email]]
> > Sent: Friday, January 16, 2009 10:53 AM
> > To: [hidden email]
> > Subject: RE: [Shib-Users] anyone running an OCSP responder for
> InCommon
> > CRLs?
> >
> > Peter Williams wrote on 2009-01-16:
> > > 1. if a Federation wants to use PKI for SAML protocols, can it do
> so
> > with
> > > Shib (or is PKI simply now a legacy technology that Shib SPs should
> > ignore)?
> >
> > Can it? Yeah, the code's there and it works (mostly). Should it? I
> > doubt it,
> > unless you provide the expertise to fix and enhance what's there to
> > your
> > standards.
> >
> > OCSP for example isn't supported by me right now, for example and I
> > have no
> > intention of adding that. In theory there might be OpenSSL bits for
> > that,
> > but I never went looking.
> >
> > CRL support is at least working in svn now, there was a bug that
> > basically
> > prevented even what little I had done from running, which just
> > reinforced my
> > attitude that this was a bad idea.
> >
> > > 2. Is anyone running an OCSP server for the SSL certs offered by
> the
> > ACS
> > > https endpoints published the signed InCommon metadata, as it
> serves
> > > (realtime, limited exposure) signed metadata
> >
> > Those SSL certs are arbitrary (they're browser facing). Whether
> they're
> > valid or not is really a matter for the client. There are undoubtedly
> > many
> > such responders, as many commercial CAs run them, but there cannot be
> > one
> > server for them, and no SAML implementation is ever involved in
> > validating
> > them in any case.
> >
> > > 3. If the IDP receives a server cert from using ACS URL with a
> > critical
> > > extension pointing to the OCSP endpoint (while posting a
> > SAMLResponse,
> > say)
> > > will it ignore it (and be "formally" non-complying)?
> >
> > The IdP doesn't talk to an ACS, the browser does.
> >
> > > 4. Do the InCommon rules countenance a Shib IDP operator to
> configure
> > the
> > > IDP to be non compliance with PKI standard - when interworking with
> > an SSL
> > > PKI-based ciphersuite?
> >
> > InCommon has nothing to say about it, and there is no standard to
> > follow in
> > any case. All TLS does is deal with the crypto. The rest is out of
> its
> > scope, with the exception of server name validation, which InCommon
> > requires
> > for the back-channel in the usual ways.
> >
> > > 5. Does Shib IDP enforce the rule that the reported DNS address of
> > the
> > > actual ACS IP endpoint reported by its socket must match the cn=
> > field in
> > a
> > > cert bound to that SSL channel?
> >
> > The IdP isn't involved. InCommon does not require people to use
> > commercial
> > SSL certificates or to follow the rules browsers require for browser-
> > facing
> > endpoints. Everybody does of course because they have to for
> practical
> > reasons.
> >
> > -- Scott
> >

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

Cantor, Scott E.
Peter Williams wrote on 2009-01-20:
> Is it also shib philosophy that on preparing an encrypted assertion for a
> recipient with a cert, that any signing-only keyusage in the SHOULD be
> ignored by the IDP?

There seems to be a word missing in that sentence, but I think you're asking
about the certificate, not the metadata.

I wouldn't call it a philosophy, but no, we don't require anything but that
the credential resolver on top of the metadata hand us back a key. What that
plugin does is its business.

> or is the profile rule stronger: MUST be ignored?

I think it would be stupid to do so, but there's no MUST.

> One way to do this is to simple cause openssl/cert libraries to regard the
> certificate as v1, rather than v3.

I very much doubt that's simple, and even if it were, the IdP is in Java and
99% of the encryption that happens is by the IdP, not the SP.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
So Chad,


Did you program the resolvers for the IDP so one or more of them MAY ignore any and all extensions in the cert for the SP entity, when preparing encrypted assertions?

Does it check the CRL of the provider of the cert, if the CRLDP extension is populated, when preparing an encrypted assertion/nameid/attribute?

If that extension is critical, does it ignore it (and process the certificate...and produce an encrypted assertion)?

If the cert has a restriction (signing only), will it be ignored?

> -----Original Message-----
> From: Scott Cantor [mailto:[hidden email]]
> Sent: Tuesday, January 20, 2009 11:20 AM
> To: [hidden email]
> Subject: RE: [Shib-Users] anyone running an OCSP responder for InCommon
> CRLs?
>
> Peter Williams wrote on 2009-01-20:
> > Is it also shib philosophy that on preparing an encrypted assertion
> for a
> > recipient with a cert, that any signing-only keyusage in the SHOULD
> be
> > ignored by the IDP?
>
> There seems to be a word missing in that sentence, but I think you're
> asking
> about the certificate, not the metadata.
>
> I wouldn't call it a philosophy, but no, we don't require anything but
> that
> the credential resolver on top of the metadata hand us back a key. What
> that
> plugin does is its business.
>
> > or is the profile rule stronger: MUST be ignored?
>
> I think it would be stupid to do so, but there's no MUST.
>
> > One way to do this is to simple cause openssl/cert libraries to
> regard the
> > certificate as v1, rather than v3.
>
> I very much doubt that's simple, and even if it were, the IdP is in
> Java and
> 99% of the encryption that happens is by the IdP, not the SP.
>
> -- Scott
>

Reply | Threaded
Open this post in threaded view
|

Re: anyone running an OCSP responder for InCommon CRLs?

Chad La Joie
The IdP does not do any checking of the cert when it's using it to
encrypt the assertion.  It checks the cert when the SP connects or when
it's validating a signature coming back from the SP.  When SLO is
supported it will also do a check when connecting to the SP.  For
encryption though it simply treats the cert as a key container, nothing
more.

Peter Williams wrote:

> So Chad,
>
>
> Did you program the resolvers for the IDP so one or more of them MAY ignore any and all extensions in the cert for the SP entity, when preparing encrypted assertions?
>
> Does it check the CRL of the provider of the cert, if the CRLDP extension is populated, when preparing an encrypted assertion/nameid/attribute?
>
> If that extension is critical, does it ignore it (and process the certificate...and produce an encrypted assertion)?
>
> If the cert has a restriction (signing only), will it be ignored?
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
For my sins, I'm getting deeper into SAML2 metadata: its (key management) model, its requirements, its keyinfo doctrine (e.g. relationship to XKISS), and, of course, reality.

For the first time, I need to share the metadata controls with a Shib2.x IDP, building up to a production deployment of a SAML connection.

If I now specify not a cert but a chain of certs in my SP's X.509Data, for the "encryption" key usage, will the IDP process the chain (at least for v1 rules, such as checking validity periods and signature chaining)?

Does it do chain processing at metadata import time, or when the encryption primitive is invoked (or not at all)?

The set of certs is not ordered, in the spec. IN practice, is there an order I should impose?

If put a CRL in X509data, will it be processed and used?

> -----Original Message-----
> From: Chad La Joie [mailto:[hidden email]]
> Sent: Tuesday, January 20, 2009 11:08 PM
> To: [hidden email]
> Subject: Re: [Shib-Users] anyone running an OCSP responder for InCommon
> CRLs?
>
> The IdP does not do any checking of the cert when it's using it to
> encrypt the assertion.  It checks the cert when the SP connects or when
> it's validating a signature coming back from the SP.  When SLO is
> supported it will also do a check when connecting to the SP.  For
> encryption though it simply treats the cert as a key container, nothing
> more.
>
> Peter Williams wrote:
> > So Chad,
> >
> >
> > Did you program the resolvers for the IDP so one or more of them MAY
> ignore any and all extensions in the cert for the SP entity, when
> preparing encrypted assertions?
> >
> > Does it check the CRL of the provider of the cert, if the CRLDP
> extension is populated, when preparing an encrypted
> assertion/nameid/attribute?
> >
> > If that extension is critical, does it ignore it (and process the
> certificate...and produce an encrypted assertion)?
> >
> > If the cert has a restriction (signing only), will it be ignored?
> --
> SWITCH
> Serving Swiss Universities
> --------------------------
> Chad La Joie, Software Engineer, Net Services
> Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
> phone +41 44 268 15 75, fax +41 44 268 15 68
> [hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

Re: anyone running an OCSP responder for InCommon CRLs?

Chad La Joie
The answer is the same as the last time you asked.  The IdP does NOT do
any PKIX validation on the cert, it only uses the cert as a
semi-convenient container for the key encryption key.  In the case that
the metadata contains a cert chain it picks out the end-entity cert
(though I can't remember the exact logic it uses, Brent wrote that code).

Peter Williams wrote:

> For my sins, I'm getting deeper into SAML2 metadata: its (key management) model, its requirements, its keyinfo doctrine (e.g. relationship to XKISS), and, of course, reality.
>
> For the first time, I need to share the metadata controls with a Shib2.x IDP, building up to a production deployment of a SAML connection.
>
> If I now specify not a cert but a chain of certs in my SP's X.509Data, for the "encryption" key usage, will the IDP process the chain (at least for v1 rules, such as checking validity periods and signature chaining)?
>
> Does it do chain processing at metadata import time, or when the encryption primitive is invoked (or not at all)?
>
> The set of certs is not ordered, in the spec. IN practice, is there an order I should impose?
>
> If put a CRL in X509data, will it be processed and used?


--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
Ok. Lets recall in an open system that an SP has to interwork with multiple vendor's implementations of an IDP. This is now my reality, as a production interworking with a derivative of the Shib2.x IDP is now being contemplated, for deployment in short order.

Here is what we know on encrypted assertion handling by the IDP:

If a cert value is specified in the SP metadata, its certificate semantics are not verified per X.509.

If cert chain value is specified..., the PKIX validation profile is not applied/enforced.

If cert chain value is specified..., the core X.509 chaining semantics are neither processed nor enforced (because the IDP just ignores the authority components of the chain, essentially).

Now we know that "somehow" the IDP does pick an "EE" cert from the chain.  We know however the code does not identify the cert as EE from performing chaining logic; but somehow it can so identify one cert from the set.

It WOULD be useful to know what the IDP code does for cert discovery. For example, it might implement something as simple as the 'EE' cert is assumed to be the first or last element in the original list. (Assume the metadata is signed, using an enveloped signature, so the IDP has assurance of the originator's ordering).

> -----Original Message-----
> From: Chad La Joie [mailto:[hidden email]]
> Sent: Wednesday, January 21, 2009 1:19 AM
> To: [hidden email]
> Subject: Re: [Shib-Users] anyone running an OCSP responder for InCommon
> CRLs?
>
> The answer is the same as the last time you asked.  The IdP does NOT do
> any PKIX validation on the cert, it only uses the cert as a
> semi-convenient container for the key encryption key.  In the case that
> the metadata contains a cert chain it picks out the end-entity cert
> (though I can't remember the exact logic it uses, Brent wrote that
> code).
>
> Peter Williams wrote:
> > For my sins, I'm getting deeper into SAML2 metadata: its (key
> management) model, its requirements, its keyinfo doctrine (e.g.
> relationship to XKISS), and, of course, reality.
> >
> > For the first time, I need to share the metadata controls with a
> Shib2.x IDP, building up to a production deployment of a SAML
> connection.
> >
> > If I now specify not a cert but a chain of certs in my SP's
> X.509Data, for the "encryption" key usage, will the IDP process the
> chain (at least for v1 rules, such as checking validity periods and
> signature chaining)?
> >
> > Does it do chain processing at metadata import time, or when the
> encryption primitive is invoked (or not at all)?
> >
> > The set of certs is not ordered, in the spec. IN practice, is there
> an order I should impose?
> >
> > If put a CRL in X509data, will it be processed and used?
>
>
> --
> SWITCH
> Serving Swiss Universities
> --------------------------
> Chad La Joie, Software Engineer, Net Services
> Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
> phone +41 44 268 15 75, fax +41 44 268 15 68
> [hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

Re: anyone running an OCSP responder for InCommon CRLs?

Chad La Joie


Peter Williams wrote:
> If a cert value is specified in the SP metadata, its certificate semantics are not verified per X.509.

No, it's not validated per PKIX, there is a difference.

> If cert chain value is specified..., the PKIX validation profile is not applied/enforced.
>
> If cert chain value is specified..., the core X.509 chaining semantics are neither processed nor enforced (because the IDP just ignores the authority components of the chain, essentially).

There is no such thing an X.509 "chain", thats a PKIX validation thing.

> Now we know that "somehow" the IDP does pick an "EE" cert from the chain.  We know however the code does not identify the cert as EE from performing chaining logic; but somehow it can so identify one cert from the set.
>
> It WOULD be useful to know what the IDP code does for cert discovery. For example, it might implement something as simple as the 'EE' cert is assumed to be the first or last element in the original list. (Assume the metadata is signed, using an enveloped signature, so the IDP has assurance of the originator's ordering).

Feel free to look in the code.  I *think* it's a bit smarter than just
picking the first one, but I'm not sure.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

Cantor, Scott E.
Chad La Joie wrote on 2009-01-21:
> Feel free to look in the code.  I *think* it's a bit smarter than just
> picking the first one, but I'm not sure.

The SP isn't, FWIW. I just pick the first one that produces a public key.
 
-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3
It's harder for the IDP. I can from the "construction/architecture" of the type design (but the text is hardly comprehensive) that the IDP is obligated to do a fair amount of professional-grade key management for encrypted attributes. Its obviously pointless worrying about subtleties like OCSP vs CRLs, when it's obvious that the core key management mechanisms are poorly understood/documented.

When doing key management to help share 1 or more encrypted attributes with an SP affiliation, an IDP needs to get the asymmetric keys for the affiliation (members) vs the particular SP. One has to search out the "right" chain from the X509data graph(s).

The certs in the Sp-side metadata have to support the different key management requirements that the SP's authnReq will place on the IDP: providing keys that support the nature of release attributes to SP affiliations, vs keys that target release to one and only one nominated relying party.

It will also be useful to see how the xmlenc primitives are used for affiliation-centric security services for encrypted attributes, and if they really interoperate particularly in the affiliation case. Shib IDP may assume that all SPs share one asymmetric private-key component for example (so one can wrap the symmetric keys once only). Or, more properly, the IDP would be performing key-wraps of symmetric key several times, once per member of the affiliation group (each time using proper asymmetric key of that affiliate member).

Nothing gospel in my memo. Im merely reading the xmlenc/dsig/core/metadata specs, inferring the intended management model from the type system design (I can trust dave solo to have got x509data right, for asymmetric key management), and then see how they might apply to the end-end security services that SAML2 exploits. There seems little method to use other than read between the lines, and theorize how the types MIGHT be used to implement the security services rationally.

> -----Original Message-----
> From: Scott Cantor [mailto:[hidden email]]
> Sent: Wednesday, January 21, 2009 7:58 AM
> To: [hidden email]
> Subject: RE: [Shib-Users] anyone running an OCSP responder for InCommon
> CRLs?
>
> Chad La Joie wrote on 2009-01-21:
> > Feel free to look in the code.  I *think* it's a bit smarter than
> just
> > picking the first one, but I'm not sure.
>
> The SP isn't, FWIW. I just pick the first one that produces a public
> key.
>
> -- Scott
>

Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

Cantor, Scott E.
Peter Williams wrote on 2009-01-21:
> When doing key management to help share 1 or more encrypted attributes with
> an SP affiliation, an IDP needs to get the asymmetric keys for the
> affiliation (members) vs the particular SP. One has to search out the
> "right" chain from the X509data graph(s).

No, it has to use metadata for the Affiliation.

> The certs in the Sp-side metadata have to support the different key
> management requirements that the SP's authnReq will place on the IDP:
> providing keys that support the nature of release attributes to SP
> affiliations, vs keys that target release to one and only one nominated
> relying party.

Yes, and it does. Nobody uses this feature or even knows it exists, so it's moot. I also don't think the IdP supports affiliations yet in any case.

> It will also be useful to see how the xmlenc primitives are used for
> affiliation-centric security services for encrypted attributes, and if they
> really interoperate particularly in the affiliation case. Shib IDP may
> assume that all SPs share one asymmetric private-key component for example
> (so one can wrap the symmetric keys once only).

That's what an affiliation assumes.

> Or, more properly, the IDP
> would be performing key-wraps of symmetric key several times, once per
> member of the affiliation group (each time using proper asymmetric key of
> that affiliate member).

That's a different use case.

-- Scott



Reply | Threaded
Open this post in threaded view
|

RE: anyone running an OCSP responder for InCommon CRLs?

peter williams-3

> > It will also be useful to see how the xmlenc primitives are used for
> > affiliation-centric security services for encrypted attributes, and
> if they
> > really interoperate particularly in the affiliation case. Shib IDP
> may
> > assume that all SPs share one asymmetric private-key component for
> example
> > (so one can wrap the symmetric keys once only).
>
> That's what an affiliation assumes.

Can you give a pointer. I searched for spec info on this in vane, last night.

Sharing an asymmetric private key component across the affiliation group members is obviously going to require suitable key management hardware - capable of cloning a private key into multiple (secure) keystore instances.

If you are using HSM equipment (as I do), asymmetric key cloning is a highly controlled process. It's also highly proprietary method. Obviously, if one is using software-crypto, you just (securely) copy a .jks file around to clone keys. Hopefully, all the affiliation members have the same software interface (e.g. can import .jks files or pkcs#15 streams)

Have folks tried having Shib SP talk to Shib IDP to have encrypted attributes sent to the affiliation? This would be similar to what I want to try next, with a Shib2 IDP.

12