Shibboleth Developers

["Scott Cantor" <>]

You're saying (correctly) that many CAs have a policy that enables them to
sign intermediate CAs that are themselves following useless or bad policy.
That means you shouldn't trust the original CA because it doesn't meet your
policy needs. It doesn't mean path validation is not applicable to the use
case or that it's somehow separate from trust.

> A CA issues a Certificate to someone who is who they claim to be.

No. It issues certificates in accordance with its policies. Those CAs (if
any) in turn are subject to some of those policies. If not, the root policy
is effectively nil. Which is worthless.

> Secondly, even though it is an option, both sets of DNs are properly
> subordinate. If you happen to check the Subject DNs (and you don't have to
> and there is no evidence that any software Java or openssl does this) then
> they have met every requirement imposed by the optional clauses of the RFC
> even if you had chosen to enforce the option which nobody does.

Java now (supposedly) does check naming constraints. OpenSSL may or may not.
Other PKIX software certainly does. Those are the only rules. There is no
rule that says anything about subordination. Anybody can sign anybody else
(unless they were given constraints by their signer).

> Chain validation applied down from the current certificate through the
> issuers to the root. Trust has to be validated upward, from a particular
> Trusted CA up through intermediate implicitly equally trusted CAs to the
> current Certificate. These are two entirely different algorithms and you
> cannot substitute one for the other.

This is not my understanding (and it is not how Shibboleth 1.2 works). Each
hop is checked to insure that it doesn't violate the constraints imposed by
its issuer until you find an issuer that is a trust anchor, at which point
you're done. There is no reverse step that I know of, unless I misunderstand
the process. Again, this isn't about whether it's useful, but if we can't
agree on what the process is...

> The bottom line here is that I will not be satisfied myself with any
> system that keys off the root self-signed CA for the University.

This is a statement about your CA (maybe even most), not about path
validation. I don't understand why you feel the two aren't separable. The
arguments against path validation that Walter makes are for practical
reasons because it creates errors and confusion in return for supposedly
making deployment somehow "scalable". It's not an argument that path
validation requires trusting CAs that aren't trustworthy.

> The only way I can have trust is to Trust certificates issued by my one
> level down CA CN=ITSCA, OU=ITS, O=Yale University

Then why wouldn't you simply make that your trust anchor for the path
validation process? The fact that OpenSSL wants it to be self-signed is a
bug to fix, that's all.

> Now it also happens that I should be able to validate the Certificate off
> the same CA Certificate that I Trust. Although some implementations of
> Certificate validation are rumored to require that the chain be run all
> the way down to the root, the standards say that validation should stop
> if a CA is encountered that is in the validity database.

http://marc.theaimsgroup.com/?l=openssl-users&m=106388669001136&w=2

> Trust is part of Shibboleth. Validity is part of every X.509
> implementation. Trust is based on the Metadata. Validity is based on some 
> other database (a JKS file for Java, the Registry for Windows, ...). For
> our purposes, we would certainly want every Trusted CA to also be in the 
> validity database, but we may have to add code to make this happen.

I don't understand the distinction you're trying to make. Claiming that PKI
doesn't consider path validation to be a trust operation is not consistent
with anything I know about it. And I certainly have no interest in two
separate databases here. I'm not going do path checking based on the Windows
root store and then go look at metadata for trust. It's one or the other.

> The validity check does many useful things. It will check expiration
> dates, CA bits, other constraints.  It is useful for Shibboleth to 
> require that the certificate be valid and that these checks have been
> done. This makes Trust easier to verify because we don't have to
> duplicate the checks. However, a valid certificate isn't necessarily
> trustworthy.

If you're doing PKI, yeah, it does. There is nothing else to check (apart
from application considerations about whether the certificate can be used
for a particular purpose).

> After validity, you have to take the extra step. The Certificate itself
> has to be a match for one in the Metadata, or the CA that issued 
> it (or, if you want, some CA on the chain for this Certificate) has to be
> a match for one in the Metadata extensions (for some Metadata structure 
> enclosing the Role for which the Certificate is being tested).

You're saying if we use well-known keys, we should still be doing validity
checking? I thought we at least agreed not to do that...

> It looks like the validity check, but it is a much simpler algorithm and a
> different data reference. We don't need to check dates, revocations,
> constrains, etc. That has all been done. We get the certificate chain as
> an array and look for a match of elements in the chain to parent 
> objects in the Metadata DOM tree.

That is what path validation already does if the objects in the tree are
used as trust anchors during the validation process. What is the point of
doing this again?

> If I put the direct issuer in the Metadata, it looks for direct issuer. If
> I put something lower, it will match indirect issuers. The important thing
> here is that the Metadata doesn't contain any CA that has subordinate CAs
> with untrustworthy administrators. That doesn't happen campus wide. It
> happens only at the departmental level. 

That is what deciding which CAs to trust *is*. If you don't trust it, you
don't trust it. That doesn't require creating a distinction between trust
validation and path validation.

-- Scott