This is getting to be a little more complicated than I thought. Rather than plough on into yet more weeds, perhaps it might help to put out a very early albeit very incomplete draft tomorrow so people can see what the weeds look like?
OK more fun out in revocation land... Indirect CRLs. Should these be considered a substitute for the direct CRL or could they be merely an adjunct? Reading through RFC 5280 it seems like indirect CRLs are just thrown in there without much thought as to the implications of allowing someone else to sign the CRL. The problem is that a CRL is both an explicit assertion that a set of certs is invalid and an implicit assertion that all unlisted certs are valid. What is an RP to assume from an indirect CRL? RFC 5280 seems to suggest that an indirect CRL is just like a direct CRL but it really doesn't seem to anticipate the issue. Which is going to make marking them as indirect utterly pointless. To the extent that the indirect flag has a meaning it becomes an evil bit. Working out if a CRL is direct is something a client should CHECK and arrive at as a conclusion. If it matters it should be configured into the trust anchor metadata. The only reason for telling the RP that the CRL is indirect that I can see would be to warn them that it is incomplete. [Now Rob is going to tell me X.509... But I don't want to read that because I am pretty certain the majority of client side implementers did not.]
_______________________________________________ wpkops mailing list [email protected] https://www.ietf.org/mailman/listinfo/wpkops
