Shibboleth Developers

["Howard Gilbert" <>]

> See pathLenConstraint, http://www.faqs.org/rfcs/rfc3280.html Sec. 4.2.1.10
> 
> If you really buy off on this stuff, you're supposed to let the cert
> machinery enforce all these rules, not impose them yourself. If you trust
> the CA, it's because you trust what it allows, including the chain length.
> 
> I think Howard would agree, but that's also (I think) why he's arguing for
> anything we build as a one-off that's not PKIX to be limited to one hop.
> Either you're doing 3280 and your head probably explodes, or you're doing
> something else, and doing chains at that point is probably overkill.

I keep trying to say that this isn't about path validation, but the message
gets lost. An example is worth a thousand URLs.

I put up an IdP on a machine with the name and certificate chain:

CN=shibboleth.its.yale.edu,OU=ITS,O=Yale University,...
Signed by 
CN=ITSCA, OU=ITS, O=Yale University
Signed by
CN=YALECA, O=Yale University

Meanwhile Student Activities gets a CA from Yale, and it creates a CA for
the Wiffenpoofs, only there is a bad sysadmin in Wiffenpoofs and he issues a
Cert

CN=shibboleth.its.yale.edu, OU=Wiffenpoofs, OU=StudentAct, O=Yale University
Signed by
CN=WiffenpoofCA, OU=Wiffenpoofs, OU=StudentAct, O=Yale University
Signed by
CN=StudentActCA, OU=StudentAct, O=Yale University
Signed by
CN=YALECA, O=Yale University

A CA issues a Certificate to someone who is who they claim to be. While the
central administration may try to verify that the people to whom they issue
Certificates are honorable, there is nothing in the RFC about verifying that
they are smart. In this case a sequence of decisions have been made that
were incrementally reasonable but led ultimately to a final untrustworthy
person.

Now there are three things to say

First, both chains are valid in the CA-chain path validation sense. Both
derive from Yale's presumably self-signed root. Put the Yale root CA in your
database of CAs, and validity checks out.

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.

If anyone reads the entire chain, and if they understand all the links in
the chain, then the status of the Certificates is blindingly obvious.
However, CA chain validation only asks the question whether the root is
valid.

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.

It is not clear if the current mess of RFC's can close this gap. RFC 3280
can constrain subjectAltNames issued by a CA to be subordinate to the
subjectAltName of the same type issued to the CA. Thus if Yale had a rigid
institutional DNS naming hierarchy that exactly matched its CA policy (which
it doesn't and could not be made to have given current technology) then the
Wiffenpoofs might be allowed to only issue DNS subjectAltNames of the form
*.wiffenpoofs.studentactivities.yale.edu
And only issue URI subjectAltNames with host names in the same range.
Unfortunately, DNS at Yale is fairly flat by administrative decision.
Besides, the use of name constrains is optional. Worse, the RFC on Web
Server subject name mapping clearly states that a subjectAltName of type DNS
name takes precedence over CN in the Subject name field, but it doesn't
require it. Nor does RFC 3280, and nor does current Shibboleth code. So even
if the Wiffenpoofs were constrained in the DNS form subjectAltName they
could issue, no RFC can prevent the use of
CN=shibboleth.its.yale.edu, OU=Wiffenpoofs, OU=StudentAct, O=Yale University
And the RFC on Web Server subject names requires that it be accepted.

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. 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

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. Thus, if I put 
CN=ITSCA, OU=ITS, O=Yale University
in the validity database, then the validity sweep down should stop when I
hit it, and if I put it in the Trust database then the Trust sweep down can
stop with it hits it.

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.

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.

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).

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.

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.