Hallo Hr Eberhard Sorry, dass ich Ihnen das Mail nicht "entrusted" schicke. (Wahrscheinlich ist es auch schneller?) Erlauben Sie mir folgende Fragen: [EMAIL PROTECTED] wrote: > Ren� G. Eberhard wrote: > > > > Hi > > > > I really like this status mail. > > > > > o Steve is currently working on (in no particular order): > > > Proper (or at least usable) certificate chain verification. > > How do you do that? Is there a requirement spec in the archive? > > I think I'm not the only one who is interested in that. > > > > Well the current code can check chains cryptographically. What it In unserer SW pr�fen wir bereits Crypto (CertSig), CertLife (TimeValid<-Cert), CertStatus (Revokation<-(timely)CRL). Was uns eigentlich noch fehlt ist (a) CertSubjectIdentity(no Fake Cert in Chain) und die (b) Trust-Geschichte. Zu a): Ein m�gliches Vorgehen w�re: Subject-DN-ComparisonCheck: toBeCheckedCert-DN vs. stored issuerCert-DN (bereits beim Einf�gen verifizierten (Root zus�tzlich FingerPrint)), als zus�tzliche Pr�fung zur Crypto. Reicht dies aus? Zu b): Gibt es eine "oeffentliche Klassifizierung" von CAs (a la Class0 - Class5), auf die ein Trust-Level Labelling-System aufgebaut werden koennte? Worin besteht der Unterschied zwischen folgenden Cert-G�ltigkeits-Modellen: Kette- und Zwiebelschale. Ich nehme an, das Ketten-Modell entspricht dem normalen X509, auch mit Cross-Zertifikaten. Zudem, welches ist die "verl�sslichste Stelle" in einem X509Cert/CRL um an eine "IssuerKeyReference" zu kommen ( ben�tigt wird eine eindeutige KeyId des Signing Keys (incl. IssuingCA-Id)). Ist dies die Authority-Key-Identifier-Extension. Wenn ja, welche(s) Feld(er)? > > doesn't do is check the extensions with the unfortunate side effect that > anyone can pretend to be a CA: so chain verification isn't usually done. > > A must have check would be that the CA certificates really were CA > certificates: and, since its the same extension, pathlength checking > could be lumped in too and possibly some minimal keyUsage checks. This > isn't too hard to do and wouldn't affect too much (if any) of the > existing code. > > Proper chain verification probably needs a database of certificates and > CRLs with trust settings. However there is a set of dependencies here... > > 1. RSA_METHOD, DSA_METHOD, DH_METHOD and fixing existing code. > 2. EVP_METHOD and revision of EVP code. Was genau ist mit 1.) und 2.) angesprochen? F�r eine baldige Antwort (auch nur teilweise) w�re ich Ihnen dankbar. MfG, Erik Benz > > 3. Certificate and CRL database API with trust settings. > 4. Proper chain verify: including overhaul of the verify interface. > > Of these the first is approaching completion... > > Steve. > -- > Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ > Personal Email: [EMAIL PROTECTED] > Senior crypto engineer, Celo Communications: http://www.celocom.com/ > Core developer of the OpenSSL project: http://www.openssl.org/ > Business Email: [EMAIL PROTECTED] PGP key: via homepage. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] -- Diese Nachricht ist mit meiner (Erik Benz) Swisskey Corporate ID digital unterschrieben. Damit ist sichergestellt, dass ich der Absender bin und nichts veraendert wurde waehrend der Uebermittlung. Um mein Zertifikat zu ueberpruefen, muss Swisskey AG als vertrauenswuerdige Zertifizierstelle akzeptiert werden unter: http://www.swisskey.ch/prod/get_root_cert_d -- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
