It is difficult to create a proxy with a lifetime identical to that of the
enclosed assertion.  I claim that---

An assertion bound to an X.509 certificate SHOULD NOT have NotBefore or
NotOnOrAfter attributes!

This implies that the embedAssertion method should 1) ignore the lifetime of
the assertion, and 2) take an integer lifetime argument.

I agree that an assertion in a X.509 cert doesn't need a lifetime since it can
implicitly inherit one from the X.509 credential.

I'd prefer a RP didn't ignore a lifetime that is present, since we're making
point-in-time decisions, it should validate the assertion is valid at the
current time.

Sorry, I may have overstated my case in Comment #1 (it was late when I wrote
that :).  Let me try again.

- A self-issued assertion (assertion issuer == certificate issuer) bound to an
X.509 certificate SHOULD NOT have NotBefore or NotOnOrAfter attributes.

- If an assertion (self-issued or otherwise) bound to an X.509 certificate has
NotBefore and/or NotOnOrAfter attributes, the relying party MUST independently
validate both the assertion lifetime and the certificate lifetime.

The conclusion for our implementation is still the same: the embedAssertion
method should 1) ignore the lifetime of the assertion, and 2) take an integer
lifetime argument for the lifetime of the certificate.

The argument about not using the issuing credential's lifetime seems fair. I'll
change embed assertion to take a lifetime or default to 12 hours (same default
as grid-prpxy-init). 

But I don't see why self issues assertions should not have NotBefore or
NotAfter. Can't the relying party can validate the timestamps in this case too
?

The question in Comment #4 is answered in Comment #3.  If the bound assertion
has a <saml:Conditions> element, all conditions MUST be checked for validity
(according to SAML Core).  This includes the NotBefore or NotOnOrAfter
attributes, if present.

That said, a self-issued assertion need not have NotBefore or NotOnOrAfter
attributes since the assertion inherits its lifetime from the certificate.  In
fact, the assertion SHOULD NOT have NotBefore or NotOnOrAfter attributes since
it is difficult to synch the NotBefore or NotOnOrAfter attributes of the
assertion with the NotBefore or NotOnOrAfter fields of the certificate.  (If
you can think of way to do this, please let me know.)

I don't see any issues with saying a self issued assertion *need not* have the
NotBefore or NotAfter field since it can be inherited from the certificate it
is embedded in. I don't see why a restriction that it *should not have* needs
to be imposed. What if I want to have a credential with greater lifetime
embedded with an assertion with shorter lifetime ? Assertions are non-critical
extensions and hence not all RPs are required to process them.

Maybe I am missing the point, but I really don't get the need for imposing such
a restriction on "self-issued" assertions.

It never occurred to me that an authority might want to issue a certificate
having a bound assertion with variable lifetime.  Can you give a use case for
that?

A bound SAML assertion inherits much from the enclosing certificate.  Issuer is
one example.  Subject confirmation is another.  The implicit confirmation
method of the certificate is holder-of-key and it makes no sense to bind an
assertion with something other than holder-of-key.  Unless the assertion is
intended to be reusable by the relying party, an explicit subject confirmation
should be avoided.

It seems that the NotBefore and NotOnOrAfter attributes of the assertion should
be consistent with the enclosing certificate.  I would hesitate breaking that
consistency without a well-defined use case.  That said, if others think
"SHOULD NOT have NotBefore or NotOnOrAfter attributes" is too strong language,
I'll back off.

I don't see a strong argument for saying an issuer shouldn't include a time if
it has some good reason (the only one I can think of would be if it is getting
an atttibute lifetime from some other other attribute source). I don't have
strong feelings, but MAY feels somewhat more reasonable, mainly because I can't
think of a good reason why it should be SHOULD.

Created an attachment (id=1209) [details]
Attached is a partial replacement for
org.globus.wsrf.impl.security.util.SAMLUtil

GSIUtil is a partial replacement for
org.globus.wsrf.impl.security.util.SAMLUtil.  It fixes the lifetime bug
reported here, cleans up and extends the API of the GSI-related methods in
SAMLUtil, and adds new functionality (such as creating a GlobusCredential from
a Java KeyStore).  GSIUtil is not a complete replacement for SAMLUtil, however,
since the latter contains some SAML-related methods that are seemingly quite
different.

Added API that allows lifetime as parameter and defaults to 12 hours. Fix
comitted to trunk.