Additional Public Keys and Signatures in X.509 Certificates

Abstract

This memo provides an optional extension for X.509 certificates
to provide additional public keys with different algorithms,
so that applications like TLS can slowly migrate from one public-key algorithm
to another public-key algorithm. The extensions can be marked non-critical, 
so that unsupporting applications can use the original Subject Public Key,
and new supporting applications can make use of the new keys and added security.



Introduction
Without this specification, X.509 certificates [RFC2985] could only include one public-key of a subject.
If an application would want to slowly migrate from one public-key algorithm to another public-key algorithm,
it would have to provide different certificates, and it would have to create some mechanism to actually put several certificates in place and use them.
To make migrations of public-key algorithms easier, this specification defines
in Section 2 an extension for X.509 certificates.
In Section 3, it provides rules usage about the correct usage, when the extension is present.

The usage-scenario that needs this pattern is a public webserver that uses TLS, which wants to migrate from RSA to ECC.
All of the browsers currently support RSA, some of the clients support ECC.
If the server would provide a normal ECC certificate, then all browser that do not support ECC yet could not connect to that server.




The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].



2. Definition

The AdditionalPublicKey extension has the OID 1.3.6.1.4.1.18506.7
The content of the APK extension is the same as the Subject field, which contains the algorithm ID and the public key.
It is suggested to mark the APK extension non-critical until Quantum computers have broken realistic keys.

The AdditionalSignature extension has the OID 1.3.6.1.4.1.18506.8



3. Usage rules

If the extension is marked critical, and the algorithm is not supported, a signature-verification with the key MUST fail.
If the extension 



Conforming applications that understand both public-key algorithms SHOULD calculate and verify both signatures, 
afterwards calculate the aggregation, and then accept the signature as valid only of both signatures are valid.






4. Security considerations
A potential problem that should be cared about by implementers are timing attacks, 
if e.g. one algorithm gives a negative result and the other algorithm isnīt tried anymore.
Therefore, both verification algorithms should be executed, and the results should be combined afterwards.

	
5. Example
The following certificate contains an additional public key:
-----BEGIN CERTIFICATE-----
MIIEijCCA/OgAwIBAgIJAKDqOzbBz5UOMA0GCSqGSIb3DQEBBQUAMFExCzAJBgNV
BAYTAkFUMRAwDgYDVQQIEwdQcm92aW56MQ4wDAYDVQQHEwVTdGFkdDEOMAwGA1UE
ChMFRmlybWExEDAOBgNVBAMTB1Jvb3QgQ0EwHhcNMTQwMjEyMTU0NDE5WhcNMjcw
NTAyMTU0NDE5WjBRMQswCQYDVQQGEwJBVDEQMA4GA1UECBMHUHJvdmluejEOMAwG
A1UEBxMFU3RhZHQxDjAMBgNVBAoTBUZpcm1hMRAwDgYDVQQDEwdSb290IENBMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6DhT0y6X4oLFOHbVhteS9Ysyw1Nef
kwPvyMuuemPNSVhwX8+msYhBntJHhAOixgfvkpz3LeiiAeIJVGOfaten+/WIRF53
jfWQ88Js4Hnc1zVVCxYp6iaah6KQIHBD3XWfJFtQoq6C//o8I/wdcrfWoVurRT/l
nngNPmsXUjj53QIDAQABo4ICaDCCAmQwggJgBgkrBgEEAYGQSgcEggJRMIICTTAa
BgsrBgEEAcEWAQEBAQYLKwYBBAHBFgEBAi4DggItAASCAijm5ZGp7c2X1mVYZZ/y
+AtbSjQ07tAFtCbISt+51d6Ss0St1+CHuPeXwTg5bERsDrXRX+EaeWK0t9xAV8ih
TGM5GaIRCcJSS2izWNqOIBXWrpntl5/LZ+1ME6KNasNxVBDkjXG9HjVowhsQsr7Y
8c1eadVoA4oXqMZCgXwkqliwEDCY+vgDv0WT92xyf91B+NKGTNqsrbFZfNZVoQpG
/OCJscZKKv36MZbqch605hUpDadiMTyhL0vBJ9d0r2fGeMVaMCpIwigOxxePM9l8
kfLhipHXQgLoZaruzNdCRuKpcMTBmOT3dTQ8TMQNOuEGiTskmrDE6QPnzsNMCFSc
fIKngtx7lJL5/2WF4NLjCElwJWWBa+ALii4R2wnAEBi2O3zR3VZB2T0HPFRPrWRB
uZY92A/3fo+eOvmqxShPRzX4spC62Lb8nn5MzoChKDQDRsCsQiR35l8IB21aypPW
+XyPGhHxpgSwaWbFC6vtmnWmphEo7mHvkLPV2/7h28AMIMhFQ9UG77Xx5LUqofLv
iDarSuG0YZ1h6KbZxwZ4WpWCZjQ17A7q1F0L2RjFUn9YW/FOOZQIvGC6xYQS4JlT
EMr6ykW+dvo5HnrguAJ3Bgj/yHCsAvMd/JXb0RmqGhnmgAhq3hPFSPCz2Uk/pwox
CHdBmDlOCY3yIZTHAp7szmJ0XYKudRWn9EOCs4oojWTMN4dbPpTvnueIhowzSZC4
cTw9PR6f+CVpnkAwDQYJKoZIhvcNAQEFBQADgYEAsNPJvYNtCN2p03ZQ5o6gHbW5
Ehhh06+4cghfV1egf2W2epyMq2xcZgyGKp7yT+hZJeNNdbO+pF1MW0UP7kBNwinM
8fr+1XstEIN6LkgiC6OEASNOys5L3WQfQNFb58t92ITYZXFSyLAl1WwWePFZsKLq
JNV5MArYirBP995V6LM=
-----END CERTIFICATE-----