Certificates Flashcards
Hybrid Certificate Eigenschaften
- Binding between identity and two independent public keys (primary and secondary)
- Binding certified with two signatures (primary and secondary)
- Usage of two independent signature schemes in parallel (secure as long at least one of the used schemes is secure)
Building hybrid certificates: approaches
- Concatenation
- Certificate Encapsulation
- Key-Signature encapsulation
Backwards compatibility
- During transition phase, hybrid certificates should still work if:
-> The (legacy) server does not understand hybrid
-> The (legacy) client does not understand hybrid
-> Both entities do not understand hybrid
–> Hybrid certificates should then appear as common X.509 certificates
Building hybrid certificates: approach: concatenation
- Public key: concatenation of primary and secondary key
- Signature: concatenation of a primary and secondary signature (verifiable with CA’s primary and secondary keys)
- Algorithm OID: identifies both signature schemes
Building hybrid certificates: approach: concatenation: advantages
- minimal (data) overhead
- easy to implement
- no downgrade attacks
Building hybrid certificates: approach: concatenation: disadvantages
- new OIDs for combined signature schemes required (treated as one signature algorithm)
- No backwards compatibility, “new” signature algorithm must be known to clients
Building hybrid certificates: approach: certificate encapsulation
- Standard X.509 certificate
- One additional, non-critical extension -> hybridCert extension (contains a complete X.509 certificate)
- Identical contents as hybrid certificate except:
-> Public key replaced by secondary subject public key
-> Signed with a secondary signature scheme and key by the issuer
-> Inner certificate has no hybridCert extension
Building hybrid certificates: approach: certificate encapsulation: advantages
- Easy implementation
- Backwards compatibility
Building hybrid certificates: approach: certificate encapsulation: disadvantages
- Redundant information (issuer, subject, validity period)
-> data overhead
-> consistency check required - Potential downgrade attacks to be considered during validation
Building hybrid certificates: approach: Key-signature encapsulation
- Standard X.509 certificate
- Two additional, non-critical extensions
-> hybridKey extension contains the secondary public key
-> hybridSig extension contains the secondary signature
Building hybrid certificates: approach: Key-signature encapsulation: advantages
- No redundant information -> minimal data overhead
- Backwards compatibility
Building hybrid certificates: approach: Key-signature encapsulation: disadvantages
- more complex implementation
- potential downgrade attacks to be considered during validation
Building hybrid certificates: approach: Key-signature encapsulation: hybridKey extension
- properties:
-> extension OID
-> criticality: non critical
-> hybridKey: SubjectPublicKeyInfo: algorithm OID of the secondary public key and its parameters + secondary public key of the certificate holder
Building hybrid certificates: approach: Key-signature encapsulation: hybridSig extension
- properties:
-> extension OID
-> criticality: non-critical
-> hybridSig
–> signature algorithm: algorithm OID and its parameters used for the secondary signature
–> signature value: actual signature value (over the TBS-part of the certificate)
Building hybrid certificates: approach: Key-signature encapsulation: implementation challenges
- Secondary signature value is part of final tbsCertificate, but cannot be included during creation of secondary signature
- tbsCertificate used for creating secondary signature must include hybridSig extension with correct byte length (otherwise the tbsCertificate changes when added later)
- Original tbsCertificate for secondary signature needs to be recreated during verification