rfc5280 chain validation implementation?

[Werner Koch]

On Fri, 24 Apr 2009 10:52, simon at josefsson.org said:

> Right.  It is difficult to document any another algorithm and prove that
> it leads to the same result though.  The RFC 5280 algorithm is well
> described and seems possible to implement directly.

Well, I didn't looked at that algorithm but assume that it is similar to
the to the one in rfc 3280.  Lets see...  oh yes, I am not yet up to the
latest standards.  Anyway in a world where you can't use AES for S/MIME
encryption because the majority of software (Outlook) can't handle it, I
am not sure whether always updating to the latest standards is a good
idea ;-)

> I think we must separate path validation from path construction.
> Building a chain using various locally trusted certificates, and
> auxilliary certificates, is difficult, but what I need is only path
> validation.

Well, if you already know the complete chain, the validation is pretty
easy (except for the more exotic features).  If you don't know, you need
to check the certificates anyway while constructing the chain.  Look at
some of the comments in gnupg/sm/certchain and consider that we had a
whole lot a bunch of support requests to handle some real world PKIs.

> Indeed, I have started to think about separating the path validation
> from GnuTLS into a separate server.  Protocol ideas in:
>
> http://redmine.josefsson.org/projects/gnutls/wiki/GnuTLSExternalValidation
>
> The best would be if GnuTLS would not have to implement path validation
> or private key operations in the same process as the TLS implementation.

For private key operation you may use gpg-agent directly (or if you
prefer pkcs11 with the help of scute).  Looking at the Wiki:

   Private key protocol

The sign operation is actually implemented and used by Scute for its
job.  9We once had to add that funny SHA1-MD5 thing to get that
working.)

  X.509 Chain Validation

Regarding the DoS problem: If you already know all the certificates, we
could add a mode which won't lookup any extra certificates and just do
the chain validation.  There is still the CRL/OCSP DoS problem but that
is something you can't avoid.  If you have the fingerprint of the
certificates hey should be used instead of passing along the
certificates themself. Dirmngr will cache them and ask back to for a
certificate it does not know about.

IIRC, there is some infrastructure for your TRUSTED/UNTRUSTED commands
already available.  I am not sure whether Dirmngr is the right server
for this as it overloads its real purpose.  However it is already
available as a system daemon.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.