Figure 9.56: Taxonomy of X.509 Certificate Object Interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellentaxonomie (Vererbungshierarchie).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R21-11), Functional Cluster Cryptography (ara::crypto), Sub-Namespace ara::crypto::x509.
• Technischer Zweck: Formale Definition des objektorientierten C++-Typsystems und der Vererbungsstruktur für X.509-Public-Key-Infrastruktur-Objekte (PKI). Das Diagramm legt die Schnittstellenabstraktion für Zertifikate, Zertifikatssignierungsanfragen (CSR), Validierungsstrukturen (OCSP), Schlüsselinformationen sowie deren Serialisierbarkeit für Transport und Persistierung fest.

2. Komponenten, Entitäten & Schnittstellen

Wurzelschnittstelle

• Serializable («aapAPI, aapNativeInterface»): Oberste Basisschnittstelle des Kryptographie-Clusters für persistierbare und exportierbare Objekte. Definiert rein virtuelle Methoden für die Serialisierung und Deserialisierung (z. B. DER- und PEM-Codierung).

Direkte Ableitungen von Serializable

• X509PublicKeyInfo («aapAPI, aapNativeInterface»): Kapselt die SubjectPublicKeyInfo-Struktur (RFC 5280) bestehend aus Algorithmus-Identifier, Parametern und dem eigentlichen öffentlichen Schlüsselbitstring.
• X509Object («aapAPI, aapNativeInterface»): Abstrakte Basisklasse aller zusammengesetzten X.509-Strukturen; stellt allgemeine Metadaten- und Identifikationsfunktionen bereit.

Spezialisierungen von X509Object

• OcspRequest («aapAPI, aapNativeInterface»): Repräsentiert Zertifikatsstatus-Abfragen via Online Certificate Status Protocol (RFC 6960).
• OcspResponse («aapAPI, aapNativeInterface»): Repräsentiert empfangene, kryptographisch verifizierbare Statusantworten (Good, Revoked, Unknown) eines OCSP-Responders.
• X509DN («aapAPI, aapNativeInterface»): Repräsentiert Distinguished Names (X.500/X.509) zur eindeutigen Adressierung von Aussteller (IssuerDN) und Zertifikatsinhaber (SubjectDN).
• X509Extensions («aapAPI, aapNativeInterface»): Container für X.509v3-Zertifikatserweiterungen (z. B. KeyUsage, ExtendedKeyUsage, SubjectAlternativeName, BasicConstraints).
• BasicCertInfo («aapAPI, aapNativeInterface»): Abstrakte Schnittstelle zur Vereinheitlichung gemeinsamer Eigenschaften von Zertifikaten und Signieranfragen (Gültigkeitszeiträume NotBefore/NotAfter, Seriennummer, Signaturalgorithmus).

Spezialisierungen von BasicCertInfo

• Certificate («aapAPI, aapPortInterface»): Repräsentiert ein vollwertiges X.509v3-Zertifikat. Trägt als einzige Entität das Stereotyp «aapPortInterface», wodurch Instanzen über serviceorientierte Kommunikationskanäle (ara::com Service-Ports) prozessübergreifend als Payload bereitgestellt oder konsumiert werden können.
• CertSignRequest («aapAPI, aapNativeInterface»): Repräsentiert eine PKCS#10-Zertifikatssignierungsanforderung (Certificate Signing Request, CSR) inklusive Proof-of-Possession der privaten Schlüsselkomponente.

3. Dynamisches Verhalten & Sequenzablauf

Als statisches Klassendiagramm modelliert das Schaubild keinen Laufzeit-Callflow. Aus der Taxonomie leitet sich jedoch folgender normativer PKI-Lebenszyklus ab:

1. CSR-Erstellung & Export:
   • Erzeugung einer CertSignRequest-Instanz über den X509Provider.
   • Zuweisung von X509DN und X509Extensions.
   • Aufruf von Serializable::ExportPublicly() (Export als PKCS#10 PEM/DER) zur Übertragung an das Backend bzw. die CA.
2. Zertifikatsimport & Bereitstellung:
   • Deserialisierung des ausgestellten Zertifikats über X509Provider::ParseCert() in eine Certificate-Instanz.
   • Bereitstellung des Certificate-Objekts an Applikationen über ara::com (ermöglicht durch «aapPortInterface»).
3. Validierung & Statusprüfung:
   • Extraktion von X509PublicKeyInfo zur Verifikation kryptographischer Signaturen.
   • Generierung von OcspRequest und Validierung gegen OcspResponse zur Laufzeit-Prüfung von CRL/Sperrstatus.
4. Fehlerbehandlung:
   • AUTOSAR Adaptive nutzt keine C++-Exceptions; alle instanziierenden und parsenden Operationen liefern typisierte ara::core::Result<T, CryptoErrc>-Werte zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Memory- & Ownership-Modell: Alle Schnittstellen definieren abstrakte Datentypen. Entwickler instanziieren Objekte niemals direkt auf dem Stack oder via new, sondern ausschließlich über den zuständigen X509Provider (Factory-Pattern). Die Lebenszeitverwaltung erfolgt typischerweise über Smart-Pointer (std::unique_ptr<Certificate>, std::unique_ptr<const X509DN>).
• Immutability & Thread-Safety: Zertifikats- und Schlüsselobjekte sind nach dem Parsen bzw. Laden immutable. Lesezugriffe über parallele Threads sind ohne Locking auf Objektebene thread-safe.
• Schnittstellengrenzen (Native vs. Port Interface):
  • Reine aapNativeInterface-Klassen verbleiben prozesslokal im Speicherbereich des Cryptography-Treibers bzw. der Applikation.
  • Das Certificate als aapPortInterface erlaubt standardisierte Inter-Process-Communication (IPC / SOME/IP) ohne manuelle Deserialisierung auf Applikationsebene – etwa für zentrale Update- und Identitätsmanager (UCM, Identity & Access Management).
• Algorithmen-Agilität: Durch die Trennung von X509PublicKeyInfo und den kryptographischen Algorithmen-Implementierungen im CryptoProvider bleibt das Zertifikats-Parsing von konkreten asymmetrischen Kryptoverfahren (RSA, ECDSA, Ed25519) entkoppelt.