< draft-ounsworth-pq-composite-sigs-00.txt   draft-ounsworth-pq-composite-sigs-01.txt >
LAMPS M. Ounsworth LAMPS M. Ounsworth (Editor)
Internet-Draft S. Mister Internet-Draft Entrust Datacard
Intended status: Standards Track J. Gray Intended status: Standards Track M. Pala
Expires: September 9, 2019 Entrust Datacard Expires: January 5, 2020 CableLabs
S. Fluhrer July 04, 2019
P. Kampanakis
Cisco Systems
March 08, 2019
Composite Keys and Signatures For Use In Internet PKI Composite Keys and Signatures For Use In Internet PKI
draft-ounsworth-pq-composite-sigs-00 draft-ounsworth-pq-composite-sigs-01
Abstract Abstract
With the widespread adoption of post-quantum cryptography will come With the widespread adoption of post-quantum cryptography will come
the need for an entity to possess multiple public keys on different the need for an entity to possess multiple public keys on different
cryptographic algorithms. Since the trustworthiness of individual cryptographic algorithms. Since the trustworthiness of individual
post-quantum algorithms is at question, a multi-key cryptographic post-quantum algorithms is at question, a multi-key cryptographic
operation will need to be performed in such a way that breaking it operation will need to be performed in such a way that breaking it
requires breaking each of the component algorithms individually. requires breaking each of the component algorithms individually.
This requires defining new structures for holding composite public This requires defining new structures for holding composite public
keys and composite signature data. keys and composite signature data.
This document defines the structures CompositePublicKey, This document defines the structures CompositePublicKey,
CompositeSignatureAlgorithmParams, and CompositeSignatureValue which CompositeSignatureValue, and CompositeParams, which are sequences of
are sequences of the respective structure for each component the respective structure for each component algorithm. This document
algorithm. This document also defines algorithms for generating and also defines algorithms for generating and verifying composite
verifying composite signatures. This document makes no assumptions signatures. This document makes no assumptions about what the
about what the component algorithms are, provided that their component algorithms are, provided that their algorithm identifiers
algorithm identifiers and signature generation and verification and signature generation and verification algorithms are defined.
algorithms are defined.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2019.
This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions and notation . . . . . . . . . . . . . . . . . . 4 2. Composite Structures . . . . . . . . . . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Algorithm Identifier . . . . . . . . . . . . . . . . . . 5
3.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Composite Keys . . . . . . . . . . . . . . . . . . . . . 6
4. Composite Structures . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Key Usage Bits . . . . . . . . . . . . . . . . . . . 6
4.1. Composite Public Key . . . . . . . . . . . . . . . . . . 5 2.3. Composite Public Key . . . . . . . . . . . . . . . . . . 7
4.2. Composite Signature Algorithm . . . . . . . . . . . . . . 6 2.4. Composite Private Key . . . . . . . . . . . . . . . . . . 8
4.3. Encoding Composite Structures As Octet Strings and Bit 2.5. Composite Signature . . . . . . . . . . . . . . . . . . . 9
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Encoding Rules . . . . . . . . . . . . . . . . . . . . . 9
5. Composite Signature Algorithm . . . . . . . . . . . . . . . . 7 3. Composite Signature Algorithm . . . . . . . . . . . . . . . . 10
5.1. Composite Signature Generation . . . . . . . . . . . . . 7 3.1. Composite Signature Generation . . . . . . . . . . . . . 10
5.2. Composite Signature Verification . . . . . . . . . . . . 7 3.2. Composite Signature Verification . . . . . . . . . . . . 12
6. Mechanisms to distribute verification policy to clients . . . 9 4. In Practice . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Local verifier policy . . . . . . . . . . . . . . . . . . 9 4.1. PEM Storage of Composite Private Keys . . . . . . . . . . 14
6.2. Extra metadata in the public key or signature . . . . . . 9 4.2. Asymmetric Key Packages (CMS) . . . . . . . . . . . . . . 15
6.3. Extra metadata in the certificate . . . . . . . . . . . . 10 4.3. Cryptographic protocols . . . . . . . . . . . . . . . . . 15
6.4. Policy certificate issued by the Certificate Authority . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.5. Policy constraints in a cross-certificate . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.6. Revoked Algorithms CRL Extension . . . . . . . . . . . . 10 6.1. Policy for Deprecated and Acceptable Algorithms . . . . . 16
6.6.1. Implicit Revocation . . . . . . . . . . . . . . . . . 11 6.2. Protection of Private Keys . . . . . . . . . . . . . . . 17
7. New Algorithm Identifiers . . . . . . . . . . . . . . . . . . 12 6.3. Checking for Compromised Key Reuse . . . . . . . . . . . 17
8. In Practice . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Composite Encryption and KEMs . . . . . . . . . . . . . . 17
9. Implications for existing standards . . . . . . . . . . . . . 12 7. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. RFC 2986 . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 17
9.2. RFC 5280 . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Intellectual Property Considerations . . . . . . . . . . 19
9.3. Cryptographic protocols . . . . . . . . . . . . . . . . . 12 8. Contributors and Acknowledgements . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
12. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 21
12.1. Intellection Property Considerations . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
12.2. Comparison with draft-truskovsky-lamps-pq-hybrid-x509 . 13
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
14. Acknowledgenents . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
During the transition to post-quantum cryptography, there will be During the transition to post-quantum cryptography, there will be
uncertainty as to the strength of cryptographic algorithms; we will uncertainty as to the strength of cryptographic algorithms; we will
no longer fully trust traditional cryptography such as RSA, Diffie- no longer fully trust traditional cryptography such as RSA, Diffie-
Hellman, DSA and their elliptic curve variants, but we will also not Hellman, DSA and their elliptic curve variants, but we will also not
fully trust their post-quantum replacements until they have had fully trust their post-quantum replacements until they have had
sufficient scrutiny. Unlike previous cryptographic algorithm sufficient scrutiny. Unlike previous cryptographic algorithm
migrations, the choice of when to migrate and which algorithms to migrations, the choice of when to migrate and which algorithms to
migrate to, is not so clear. Even after the migration period it may migrate to, is not so clear. Even after the migration period, it may
be advantageous for an entity's cryptographic identity to be composed be advantageous for an entity's cryptographic identity to be composed
of multiple public-key algorithms. Even after the transition period, of multiple public-key algorithms.
a composite approach may be advantageous as a single entity may have
multiple public keys on different algorithms or strengths to address
different use-cases, and a single signature may want to compase
multiple of them together.
The deployment of composite public keys and signatures using post- The deployment of composite public keys and composite signatures
quantum algorithms will face two challenges using post-quantum algorithms will face two challenges
o Algorithm strength uncertainty: During the transition period, some o Algorithm strength uncertainty: During the transition period, some
post-quantum signature and encryption algorithms will not be fully post-quantum signature and encryption algorithms will not be fully
trusted, while also the trust in legacy public key algorithms will trusted, while also the trust in legacy public key algorithms will
also start to erode. A relying party may learn some time after also start to erode. A relying party may learn some time after
deployment that a public key algorithm has become untrustworthy, deployment that a public key algorithm has become untrustworthy,
but in the interim, they may not know which algorithm an adversary but in the interim, they may not know which algorithm an adversary
has compromised. has compromised.
o Backwards compatibility: During the transition period, post- o Backwards compatibility: During the transition period, post-
quantum algorithms will not be supported by all clients. quantum algorithms will not be supported by all clients.
This document provides a mechanism to address algorithm strength This document provides a mechanism to address algorithm strength
uncertainty by providing formats for encoding multiple public keys uncertainty by providing formats for encoding multiple public keys
and multiple signature values into existing public key and signature and multiple signature values into existing public key and signature
fields. The issue of backwards compatibility is left open to be fields, as well as an algorithm for validating a composite signature.
addressed in separate draft(s). The issue of backwards compatibility is left open to be addressed in
separate draft(s).
This document is intended for general applicability anywhere that This document is intended for general applicability anywhere that
public key structures or digital signatures are used, but where public key structures or digital signatures are used within PKIX
specific design decisions needed to be made, the authors chose the structures.
variant that caused the least disruption to existing X.509
certificates, as defined in [RFC5280].
_EDNOTE: While the scope of this document is restricted to EDNOTE: While the scope of this document is restricted to signatures,
signatures, we note that the same structure is equally applicable to we note that the same "CompositePublicKey" structure is equally
asymmetric encryption keys. Though a word of warning that the applicable to asymmetric encryption keys. Though a word of warning
corresponding "encrypt / decrypt with a composite public key" logic that the corresponding "encrypt / decrypt with a composite public
is somewhat less obvious than; a naive implementer might be tempted key" logic is somewhat less obvious; a naive implementer might be
to follow the same pattern as bellow and encrypt the message with tempted to follow the same pattern as below and encrypt the message
each public key separately and then concatenate the ciphertexts, with each public key separately and then concatenate the ciphertexts,
which is wrong. Specifying the correct implementation of such an which is wrong, they need to be nested. Specifying the correct
encryption scheme is out of scope for this document, but would be implementation of such an encryption scheme is out of scope for this
good work for someone in the standards community to pick document, but would be good work for someone in the standards
up._"CompositePublicKey" community to pick up.
2. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definitions and notation The following terms are used in this document:
3.1. Definitions ALGORITHM:
An information object class for identifying the type of cryptographic
operation to be performed. This document is primarily concerned with
algorithms for producing digital signatures, though the public key
structure could just as easily hold encryption keys.
_EDNOTE: A glossary of terms we define for this document, or terms BER:
that we borrow from other RFCs._ Basic Encoding Rules (BER) as defined in [X.690].
ALGORITHM: An information object class for identifying the type of COMPONENT ALGORITHM:
cryptographic operation to be performed. This document is A single basic algorithm which is contained within a composite
primarily concerned with algorithms for producing digital algorithm.
signatures, though the public key structure could just as
easily hold encryption keys.
COMPONENT ALGORITHM: A single basic algorithm which is contained COMPOSITE ALGORITHM:
within a composite algorithm. An algorithm which is a sequence of one or more basic algorithm, as
defined in Section 2.
COMPOSITE ALGORITHM: An algorithm which is a sequence of one or DER:
more basic algorithm, as defined in Distinguished Encoding Rules as defined in [X.690].
{{sec-composite-structs}}.
3.2. Notation PUBLIC / PRIVATE KEY:
The public and private portion of an asymmetric cryptographic key,
making no assumptions about which algorithm.
No special notation is used in this document. PRIMITIVE PUBLIC KEY / SIGNATURE:
A public key or signature object of a non-composite algorithm type.
4. Composite Structures SIGNATURE:
A digital cryptographic signature, making no assumptions about which
algorithm.
2. Composite Structures
In order for public keys and signatures to be composed of multiple In order for public keys and signatures to be composed of multiple
algorithms, the respective structures defined in [RFC2986], [RFC5280] algorithms, we define encodings consisting of a sequence of public
(AND OTHERS??) need to be extended. We define encodings of sequences key and signature primitives (aka "component algorithms") such that
of public keys and signature data which consist of a sequence of these structures can be used an a drop-in compatible way with
public keys and signatures from more basic signature algorithms (aka existing public key or signature fields such as those found in
"component algorithms") such that these structures can be places into PKCS#10 [RFC2986], CMP [RFC4210], X.509 [RFC5280], CMS [RFC5652].
any existing public key or signature structure.
This section defines This section defines the following structures:
o Composite public key: A general structure for holding multiple o The id-alg-composite is an OID identifying a composite public key
public keys within a single public key data structure. or signature object.
o Composite signature: Data structures needed to make use of the o The CompositePublicKey carries all the public keys associated with
Composite Signature signature algorithm (defined in Section 5), an identity within a single public key structure.
which encapsulates signatures made with multiple public keys.
_EDNOTE: Defining composite algorithm parameters as a sequence inside o The CompositePrivateKey carries all the private keys associated
the existing structure avoids an exponential proliferation of OIDs with an identity within a single private key structure.
that are needed for each pairwise combination of signature algorithms
in other competing schemes for achieving multi-key certificates.
This scheme also naturally extends from 2-keypair to n-keypair keys
and certificates._
4.1. Composite Public Key o The CompositeSignatureValue, carries a sequence of signatures that
are generated by a CompositePrivateKey, and can be verified with
the corresponding compositePublicKey.
A composite public key is a sequence of component public keys that EDNOTE: the choice to define composite algorithm parameters as a
are used together. A composite public key is identified by the sequence inside the existing fields avoids the exponential
object identifier proliferation of OIDs that are needed for each pairwise combination
of signature algorithms in other schemes for achieving multi-key
certificates. This scheme also naturally extends from 2-keypair to
n-keypair keys and certificates.
id-ce-compositePublicKey OBJECT IDENTIFIER ::= { OID } 2.1. Algorithm Identifier
The parameters field for this public key type MUST be absent. The The same algorithm identifier is used for identifying a public key, a
composite public key data is represented by the following structure: private key, and a signature. Additional encoding information is
provided below for each of these objects.
CompositePublicKey ::= SEQUENCE OF SubjectPublicKeyInfo id-alg-composite OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) private(4)
enterprise(1) OpenCA(18227) Algorithms(2) id-alg-composite(1) }
where each element of the sequence is a "SubjectPublicKeyInfo" of a EDNOTE: this is a temporary OID for the purposes of prototyping. We
public key that MAY be used in conjunction with the other keys in the are requesting IANA to assign a permanent OID, see Section 5.
sequence. When the public key must be provided in octet string or
bit string format, the data structure is converted as specified in
Section 4.3.
_EDNOTE: This document does not define the corresponding private key 2.2. Composite Keys
formats because the authors deemed it to be out of scope. We do note
that the draft the Max Pala on a similar topic, does define private
key formats, so there could be scope to merge these
submissions._[I-D.pala-composite-crypto]
4.2. Composite Signature Algorithm A composite key is a single key object that performs an atomic
signature or verification operation, using its encapsulated sequence
of component keys.
The Composite Signature signature algorithm defined in Section 5 is The ASN.1 algorithm object for composite public and private keys is:
identified by the following object identifier:
id-ce-compositeSignature OBJECT IDENTIFIER ::= { OID } pk-Composite PUBLIC-KEY ::= {
IDENTIFIER id-alg-composite
KEY CompositePublicKey
PARAMS ARE absent
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
PRIVATE-KEY CompositePrivateKey
}
The following algorithm parameters MUST be included when this EDNOTE1: the authors are currently unsure whether the params should
identifier is used: be absent (ie this structure simply says "I am a composite
algorithm"), or used to duplicate some amount of information about
what the component algoritms are. See Section 2.3 for a longer
ENDOTE on this.
CompositeSignatureAlgorithmParams ::= SEQUENCE OF AlgorithmIdentifier EDNOTE2: In order to reduce complexity, we are intentionally limiting
the scope of this draft to signature-type CERT-KEY-USAGEs, but we
note that it would be trivial to extend it to encryption-type keys.
When a composite signature is generated by a key with a 2.2.1. Key Usage Bits
CompositePublicKey, the signature's CompositeSignatureAlgorithmParams
sequence MUST contain the same component algorithms listed in the
same order as in the associated CompositePublicKey.
The Composite Signature algorithm output is the DER encoding of the The intended application for the key is indicated in the keyUsage
following structure: certificate extension and defined in the CERT-KEY-USAGE field of pk-
Composite.
id-ce-CompositeSignatureValue OBJECT IDENTIFIER ::= { OID } If the keyUsage extension is present in an end-entity certificate
that indicates id-alg-composite, then the keyUsage extension MUST
contain one or both of the following values:
CompositeSignatureValue ::= SEQUENCE OF BIT STRING nonRepudiation; and
digitalSignature.
Where each bit string within "CompositeSignatureValue" is a signature If the keyUsage extension is present in a certification authority
by one of the component signature algorithms. certificate that indicates id-alg-composite, then the keyUsage
extension MUST contain one or more of the following values:
The choice of "SEQUENCE OF BIT STRING" rather than "BIT STRING" is so nonRepudiation;
the type-length-value encoding can solve the problem of variable- digitalSignature;
length signature values. The signature's "CompositeSignatureValue" keyCertSign; and
sequence MUST contain the same component algorithms listed in the cRLSign.
same order as in the associated "CompositeSignatureAlgorithmParams".
4.3. Encoding Composite Structures As Octet Strings and Bit Strings As this draft only covers composite signatures, the key usage bits
specified here apply to all component keys within a composite key.
Many specifications require that the composite public key and 2.3. Composite Public Key
composite signature data structures be represented by an octet string
or bit string. When an octet string is required, the DER encoding of
the composite data structure SHALL be used directly. When a bit
string is required, the octets of the DER encoded composite data
structure SHALL be used as the bits of the bit string, with the most
significant bit of the first octet becoming the first bit, and so on,
ending with the least significant bit of the last octet becoming the
last bit of the bit string.
5. Composite Signature Algorithm Composite public key data is represented by the following structure:
The Composite Signature signature algorithm generates a single CompositePublicKey ::= SEQUENCE SIZE (1..MAX) OF SubjectPublicKeyInfo
composite signature by using multiple private keys to apply multiple
signature algorithms to the input message, with the resulting
signature effectively being the concatenation of the individual
signature values.
This algorithm addresses algorithm strength uncertainty by providing The corresponding AlgorithmIdentifier for a composite public key MUST
the verifier with parallel signatures from all the component use the id-alg-composite object identifier, defined in Section 2.1,
signature algorithms used as part of the composite signature; and the parameters field MUST be absent.
breaking the composite signature would require breaking each of the
component signatures.
5.1. Composite Signature Generation A composite public key MUST contain at least one component public
key.
The following algorithm is used to generate composite signature A CompositePublicKey MUST NOT contain a component public key which
values. itself describes a composite key; ie recursive CompositePublicKeys
are not allowed.
Input: Each element of a CompositePublicKey is a SubjectPublicKeyInfo object
K1, K2, ..., Kn Private keys for the n component signature one of the component public keys. When the CompositePublicKey must
algorithms be provided in octet string or bit string format, the data structure
M Message to be signed, an octet string is encoded as specified in Section 2.6.
Output: ~~~ Begin EDNOTE ~~~
S Signature, an octet string
Signature Generation Procedure: EDNOTE: there has been a fair amout of discussion among the authors
1. Generate the n component signatures independently, about whether the component public key should contain a full
according to their algorithm specifications. SubjectPublicKeyInfo for each component algorithm, or whether the
for i := 1 to n {algID, and algParams} should be move to the params of the PUBLIC-KEY
Si := Sign( Ki, M ) or OID, and only the BIT STRINGs of the component public key values
2. DER encode the component signatures into an ASN.1 value of type contained in the CompositePublicKey.
Signature, where the type Signature has the syntax
Signature ::= Sequence { S1, S2, ..., Sn }
Let S be the DER encoding of the Signature
3. Output S
5.2. Composite Signature Verification Using a wonky, simplified notation, the alternatives considered were:
Verification of a composite signature involves applying each Current composite:
component algorithm's verification routine according to its CompositeAlg: {
specification, and then outputting "Valid signature" (true) if a algorithm={id-alg-composite, none}
sufficient number of component algorithms were valid, and "Invalid subjectPublicKey=SEQ SPKI[{{algID1, algParams1}, value1},
signature" (false) otherwise. SPKI{{algID2, algParams2}, value2}, ..]
}
Implementations MAY include policy mechanisms for determining which Alternative 1:
and how many component algorithms must be valid in order for the CompositeAlg: {
composite signature to be considered valid. See Section 6 for algorithm={id-alg-composite, {{algID1, algParams1},
further discussion of possible standardization of such mechanisms. {algID2, algParams2}, ..}
This section assumes the existence of such a policy mechanism, subjectPublicKey=SEQ BIT STRING[value1, value2, ..]
specifically one that allows revocation of individual component }
algorithms.
This section provides a sample algorithm for validating composite Alternative 2:
signatures. Compliant implementations MUST return "Invalid CompositeAlg: {
signature" whenever the sample algorithm does, but MAY require more algorithm={id-alg-composite, {algID1, algID2, ..}}
than one signature to be valid. subjectPublicKey=SEQ SPKI[{{algID1, algParams1}, value1},
{{algID2, algParams2}, value2}, ..]
}
Input: The authors have decided, for the time being, to use the current
P Signer's composite public key approach since it A) promotes ease of modifying existing software
M Message whose signature is to be verified, an octet string whose APIs require SubjectPublicKeyInfos to be passed, and B) avoids
S Composite Signature to be verified bloating wire protocols with duplicated information.
A Composite Algorithm identifier
Output: We note that the chosen approach means that the algorithm field
Validity "Valid signature" (true) if the composite signature is essentially carries no useful information about the key it's
valid, "Invalid signature" (false) otherwise. describing. Analysis is required to see if there are any
circumstances in which this opens up cryptographic attacks, such as
algorithm substitution or stripping attacks. ~~~ End EDNOTE ~~~
Signature Verification Procedure:: 2.4. Composite Private Key
1. Parse P, S, A into the component public keys, signatures,
algorithm identifiers
P1, P2, ..., Pn := Desequence( P )
S1, S2, ..., Sn := Desequence( S )
A1, A2, ..., An := Desequence( A )
If Error during Desequencing, or the three sequences have different The composite private key data is represented by the following
numbers of elements, then output "Invalid signature" and stop. structure:
2. Check each signature individually CompositePrivateKey ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
V1, V2 , ..., Vn := BOOLEAN
for i := 1 to n
Check if Ai is a recognized algorithm, if so then,
Check if algorithm Ai has been revoked, if not then,
Verify the component signature according to the component
algorithm's specification
Vi = verify( Pi, M, Si )
3. Check policy to see whether V1, V2, ..., Vn constitutes a valid Each element is a OneAsymmetricKey [RFC5958] object for a component
signature private key.
if isValid(V1, V2, ..., Vn), then
output "Valid signature"
else
output "Invalid signature"
If "V1 = V2 = ... = Vn = false" for all "Vi", then "isValid(V1, V2, The corresponding AlgorithmIdentifier for a composite private key
..., Vn)" MUST return false. Implementations MAY include additional MUST use the id-alg-composite object identifier, and the parameters
policy mechanisms as discussed in Section 6. field MUST be absent.
6. Mechanisms to distribute verification policy to clients A CompositePrivateKey MUST contain at least one component private
key, and they MUST be in the same order as in the corresponding
CompositePublicKey.
In the traditional world of single-key public keys and signatures, 2.5. Composite Signature
the semantics of a signature and a verification are straight-forward:
if the key is trusted (via public key pinning, a PKIX revocation
check, etc) and the signature is valid, then the signed content can
be trusted. However the semantics are less obvious in a world where
public keys and signatures are composed of two or more algorithms; it
is conceivable that even though one component algorithm fails
verification, for example because the algorithm is revoked, a multi-
algorithm signature may contain enough other trustworthy component
algorithms to still be considered valid.
This section addresses how a verifier can obtain policy information The ASN.1 algorithm object for a composite signature is:
for which and/or how many component algorithms must be valid in order
for the signature as a whole to be valid. The authors ask for
community feedback about whether this needs to be specified, and if
so, how best to do it.
This section lists rough outlines for several such mechanisms that sa-CompositeSignature SIGNATURE-ALGORITHM ::= {
have come up in discussion during the drafting of this document. IDENTIFIER id-alg-composite
They are mainly focused around X.509 PKIs, and provided here merely VALUE CompositeSignatureValue
for the purposes of sparking debate. The authors believe that by PARAMS TYPE CompositeParams ARE required
specifying such a mechanism, the world will be able to more quickly PUBLIC-KEYS { pk-Composite }
react to news of algorithm compromise with a lower service disruption SMIME-CAPS { IDENTIFIED BY id-alg-composite } }
compared to the need to revoke and re-issue all certificates using }
that algorithm. However, we are not sure if the gains justify the
added complexity.
6.1. Local verifier policy The id-alg-composite object identifier MUST be used to identify when
a signature has been created by a composite private key, and te
following algorithm parameters MUST be included:
Much as we do today, this is left up to domain administrators and CompositeParams ::= SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier
software vendors to implement the guidance of governing bodies on a
system-by-system basis.
6.2. Extra metadata in the public key or signature The signature's CompositeParams sequence MUST contain the same
component algorithms listed in the same order as in the associated
CompositePrivateKey and CompositePublicKey.
This policy information could be specified by the signer at signing The output of the composite signature algorithm is the DER encoding
time. Depending on the structure of the databeing signed, this of the following structure:
metadata could go into the public key, or an extension to the
signature, or some other field provided that it is inside the signed
data blob.
6.3. Extra metadata in the certificate CompositeSignatureValue ::= SEQUENCE SIZE (1..MAX) OF BIT STRING
This policy information could be included in a certificate via an Where each BIT STRING within the SEQUENCE is a signature value
X.509 v3 extension. This gives the Certificate Authority control, produced by one of the component keys. It MUST contain MUST contain
but has the drawback that updating the policy requires revoking and one signature value produced by each componet key, and in the same
reissuing certificates. order as in the associated "CompositeParams", CompositePublicKey, and
CompositePrivateKey objects.
6.4. Policy certificate issued by the Certificate Authority The choice of "SEQUENCE OF BIT STRING", rather than for example a
single BIT STRING containing the concatenated signature values, is to
gracefully handle variable-length signature values by taking
advantage of ASN.1's build-in length fields.
Certificate Authorities have the ability to issue policy certificates 2.6. Encoding Rules
that specify the behaviour when verifying signatures performed by
keys in certificates within the scope of the policy certificate.
This method has the advantage that policy is centrally-managed, and Many protocol specifications will require that the composite public
can be updated without needing to reissue any certificates, but has key, composite private key, and composite signature data structures
the drawback that not all PKI implementations support policy be represented by an octet string or bit string.
certificates.
6.5. Policy constraints in a cross-certificate When an octet string is required, the DER encoding of the composite
data structure SHALL be used directly.
This method behaves similarly to the policy certificate method above, When a bit string is required, the octets of the DER encoded
but has better support across PKI implementations. composite data structure SHALL be used as the bits of the bit string,
with the most significant bit of the first octet becoming the first
bit, and so on, ending with the least significant bit of the last
octet becoming the last bit of the bit string.
6.6. Revoked Algorithms CRL Extension In the interests of simplicity and avoiding compatibility issues,
implementations that parse these structures MAY accept both BER and
DER.
Add an extension to CRLs so that in addition to revoking 3. Composite Signature Algorithm
certificates, they can also revoke algorithms for all certificates
within the scope of that CRL. Implemented with care, this could
allow a single PKI to do a staged algorithm migration by only
revoking the algorithm for one CRL group at a time.
id-ce-RevokedAlgorithms OBJECT IDENTIFIER ::= { OID } This section specifies the algorithms for generating and verifying
composite signatures.
RevokedAlgorithms ::= SEQUENCE OF SEQUENCE { This algorithm addresses algorithm strength uncertainty by providing
algorithms AlgorithmIdentifier, the verifier with parallel signatures from all the component
revocationDate Time, signature algorithms; thus breaking the composite signature would
crlEntryExtensions Extensions OPTIONAL require breaking all of the component signatures.
-- if present, version MUST be v2
}
_EDNOTE: do we need the crlEntryExtensions field? If so, which ones 3.1. Composite Signature Generation
from https://tools.ietf.org/html/rfc5280#section-5.3 are allowed
here?_
There may only be one "RevokedAlgorithms" extension in a CRL. This Generation of a composite signature involves applying each component
extension is OPTIONAL. If a CRL contains only composite algorithm's signature routine to the input message according to its
certificates, then this extension SHOULD be designated as critical. specification, and then placing each component signature value into
the "CompositeSignatureValue" structure defined in Section 2.5.
If a CRL contains a mixture of composite and traditional certificates The following algorithm is used to generate composite signature
then it SHOULD be designated as non-critical. values.
If the Revoked Algorithms extension is present in a CRL, then a Input:
client performing a certificate validation on an otherwise non- K1, K2, .., Kn Private keys for the n component signature
revoked certificate within the scope of that CRL MUST skip any algorithms
signatures corresponding to a revoked algorithm; thus a certificate M Message to be signed, an octet string
is valid only if it would have been valid had those Algorithm IDs and
Signature Values been omitted from the certificate.
Once a algorithm has been marked as revoked on a given CRL, it MUST Output:
remain revoked on subsequent CRLs. S The signature, a CompositeSignatureValue
_EDNOTE: Is there corresponding wording about cert serial numbers on Signature Generation Procedure:
CRLs from RFC5280? Or is this unnecessary implied?_ 1. Generate the n component signatures independently,
according to their algorithm specifications.
Note that a similar mechanism could be used on a per-certificate for i := 1 to n
basis via CRL Entry Extensions, however the authors believe that Si := Sign( Ki, M )
giving operators the ability to perform partial revocation of a
certificate (ie revoking some keys or signatures but leaving the
certificate as a whole valid) will greatly increase the complexity of
certificate validation routines, thus increasing the chance of both
human error, and implementation bugs leading to vulnerabilities,
without providing a commensurate amount of increased functionality.
By not defining a new CRL Entry Extension, the following requirement
is implied: if any key within a certificate warrant revocation, the
entire certificate MUST be revoked using the existing revocation
mechanisms (this does not apply when the algorithm is globally
revoked for the entire scope of this CRL).
6.6.1. Implicit Revocation 2. Encode each component signature S1, S2, .., Sn into a BIT STRING
according to its algorithm specification.
A Composite Signature Algorithm is considered to be "implicitly S ::= Sequence { S1, S2, .., Sn }
revoked" if the certificate is otherwise valid but one of the
following conditions are met.
o A certificate using a single-key algorithm which is revoked within 3. Output S
the scope of its CRL. In this case, signature verification SHOULD
fail when performed by a compliant client, but of course will
succeed when performed by a legacy client which is not aware of
this CRL extension.
o All of the component algorithms are revoked within the scope if Since recursive composite public keys are disallowed in Section 2.3,
its CRL. In this case, signature verification MUST fail when no component signature may itself be composite; ie the signature
performed by a compliant client, regardless of which verification generation routine MUST fail if one of the private keys K1, K2, ..,
algorithm is used. Kn is composite with the OID id-alg-composite.
At the time of an algorithm revocation, a certificate authority MAY A composite signature MUST produce and include in the output a
revoke certificates meeting one ofd the above criteria (by placing signature value for every component key in the corresponding
them in the traditional "revokedCertificates" list) with a revocation CompositePublicKey.
reason of "keyCompromise". OCSP responders SHOULD designate a
certificate as revoked if it meets the above condition.
7. New Algorithm Identifiers EDNOTE1: With NIST's position that they will standardize use-case-
specific algorithm suites, the authors are aware of potential use-
cases where a PKI entity may want to have many public keys, but only
sign with a subset for each signature. At the present time, this
draft does not allow for this because the algorithm for verifying
"subset-signatures" in a way that is secure against algorithm
stripping attacks would be very complex and prone to implementation
errors (currently, the verifier can detect omitted signatures even if
it does not recognize all the algorithm OIDs because the count will
be wrong. In a subset-signature algorithm, additional mechanisms
would be needed to specify for each component key, whether it is
meant to produce a signature or not). The draft-compliant way to
achieve a "subset-signature" behaviour would be for each PKI entity
to have multiple public keys (and certificates) with overlapping
subsets of their component keys. We welcome public opinions on
whether this is sufficient, or whether this draft should specify a
subset-signature algorithm.
_EDNOTE: This subsection will define the OIDs for the initial EDNOTE2: The authors are also aware of a potential use-case of
composite algorithm combinations we want to define. These are the combining signature and KEM keys inside a single public key /
OID that Section 10 will ask for IANA to assign._ certificate. This would give us back the "dual-usage key" property
that was so appealing about RSA. At the present time, this draft
does not allow for this because, again, the algorithm for verifying
"subset-signatures" in a secure way would be very complex. We also
welcome public opinions on this.
8. In Practice 3.2. Composite Signature Verification
_EDNOTE: This section will talk about practical issue of how these Verification of a composite signature involves applying each
certificates will be used. For example it will talk about the size component algorithm's verification routine according to its
of these certs and cert chains. It will explain that if a cert in specification, and then outputting "Valid signature" (true) if a
the chain is a Composite cert then the whole chain needs to be of sufficient number of component algorithms were valid, and "Invalid
Composite Certs. It will also explain that the root CA cert does not signature" (false) otherwise.
have to be of the same algorithms. The root cert SHOULD NOT be
transferred in the authentication exchange to save transport overhead
and thus it can be different than the intermediate and leaf certs.
It will talk about overhead (size and processing). It will also
discuss backwards compatibility. It could include a subsection about
implementation considerations._
9. Implications for existing standards In order to future-proof implementations of verifiers against
evolutions in cryptographic algorithms and attacks against them,
implementations SHOULD include a field-updatable policy mechanism for
determining which and/or how many component algorithms must be valid
in order for the composite signature as a whole to be considered
valid. This section assumes the existence of such a policy
mechanism, denoted as "checkPolicy(A1, A2, ..., An)" in the algorithm
below. The implementation of such a policy mechanism is largely the
responsibility of the verifier / client and therefore is out of scope
for this document, but at a minimum, one component signature MUST be
recognized and validated for the composite signature to be considered
valid.
9.1. RFC 2986 Modifications of the provided verification algorithm are permitted,
so long as they are strengthening, and not weakening, this algorithm.
In other words, any modified versions of this algorithm MUST return
"Invalid signature" whenever the sample algorithm does, with the one
exception noted below.
_EDNOTE: summarize the updates to RFC 2986 (CSR / PKCS#10)._ Input:
P Signer's composite public key
M Message whose signature is to be verified, an octet string
S Composite Signature to be verified
A Composite Algorithm identifier
9.2. RFC 5280 Output:
Validity "Valid signature" (true) if the composite signature
is valid, "Invalid signature" (false) otherwise.
_EDNOTE: summarize the updates to RFC 5280 (X.509)._ Signature Verification Procedure::
1. Parse P, S, A into the component public keys, signatures,
and algorithm identifiers
9.3. Cryptographic protocols P1, P2, .., Pn := Desequence( P )
S1, S2, .., Sn := Desequence( S )
A1, A2, .., An := Desequence( A )
If Error during Desequencing, or the three sequences have
different numbers of elements, then output "Invalid signature"
and stop.
2. Check client policy to see whether A1, A2, .., An constitutes an
acceptable combination of algorithms.
if not checkPolicy(A1, A2, .., An), then
output "Invalid signature"
3. Check each component signature individually, according to its
algorithm specification.
If any fail, then the entire signature validation fails.
for i := 1 to n
if not verify( Pi, M, Si ), then
output "Invalid signature"
if all succeeded, then
output "Valid signature"
Since recursive composite public keys are disallowed in Section 2.3,
no component signature may be composite; ie the signature
verification procedure MUST fail if any of the public keys P1, P2,
.., Pn or algorithm identifiers A1, A2, .., An are composite with the
OID id-alg-composite.
Exception to this algorithm: There will be circumstances in which the
verifier does not have cryptographic libraries for all of the
provided component algorithms, or where the performance gains from
omitting algorithms justifies the loss of security. In these cases,
an acceptable modification to this algorithm is to produce in step 2
one or more subsets of the algorithms "A1, A2, ..., An" which
constitute acceptable combinations, outputting "Invalid signature" if
an acceptable subset can not be found, and then in step 3 only
perform verification of the necessary component algorithms.
Implementations SHOULD verify all recognized and supported
algorithms, and output "Invalid signature" if the verification of any
component signature fails, but MAY choose to only verify a subset of
the algorithms for the reasons stated above.
4. In Practice
This section addresses practical issues of how this draft affects
other protocols and standards.
~~~ BEGIN EDNOTE ~~~
EDNOTE: Possible topics to address:
o The size of these certs and cert chains.
o In particular, implications for (large) composite keys /
signatures / certs on the handshake stages of TLS and IKEv2.
o If a cert in the chain is a composite cert then does the whole
chain need to be of composite Certs?
o We could also explain that the root CA cert does not have to be of
the same algorithms. The root cert SHOULD NOT be transferred in
the authentication exchange to save transport overhead and thus it
can be different than the intermediate and leaf certs.
o We could talk about overhead (size and processing).
o We could also discuss backwards compatibility.
o We could include a subsection about implementation considerations.
~~~ END EDNOTE ~~~
4.1. PEM Storage of Composite Private Keys
CompositePrivateKeys can be encoded to the PEM format by placing a
CompositePrivateKey into the privateKey field of a PrivateKeyInfo or
OneAsymmetricKey object, and then applying the PEM encoding rules as
defined in [RFC7468] section 10 and 11 for plaintext and encrypted
private keys, respectively.
EDNOTE: Do we really need this? Isn't it obvious?
4.2. Asymmetric Key Packages (CMS)
The Cryptographic Message Syntax (CMS), as defined in [RFC5652], can
be used to digitally sign, digest, authenticate, or encrypt the
asymmetric key format content type.
When encoding composite private keys, the privateKeyAlgorithm in the
OneAsymmetricKey SHALL be set to id-alg-composite.
The parameters of the privateKeyAlgorithm SHALL be a sequence of
AlgorithmIdentifier objects, each of which are encoded according to
the rules defined for each of the different keys in the composite
private key.
The value of the privateKey field in the OneAsymmetricKey SHALL be
set to the DER encoding of the SEQUENCE of private key values that
make up the composite key. The number and order of elements in the
sequence SHALL be the same as identified in the sequence of
parameters in the privateKeyAlgorithm.
The value of the publicKey (if present) SHALL be set to the DER
encoding of the corresponding CompositePublicKey. If this field is
present, the number and order of component keys MUST be the same as
identified in the sequence of parameters in the privateKeyAlgorithm.
The value of the attributes is encoded as usual.
4.3. Cryptographic protocols
This section talks about how protocols like (D)TLS and IKEv2 are This section talks about how protocols like (D)TLS and IKEv2 are
affected by this specifications. It will not attempt to solve all affected by this specifications. It will not attempt to solve all
these problems, but it will explain the rationale, how things will these problems, but it will explain the rationale, how things will
work and what open problems need to be solved. Obvious issues that work and what open problems need to be solved. Obvious issues that
need to be discussed. need to be discussed.
o How does the protocol declare support for composite signatures? o How does the protocol declare support for composite signatures?
TLS has hooks for declaring support for specific signature TLS has hooks for declaring support for specific signature
algorithms, however it would need to be extended, because the algorithms, however it would need to be extended, because the
skipping to change at page 13, line 20 skipping to change at page 16, line 18
o Overhead; including certificate size, signature processing time, o Overhead; including certificate size, signature processing time,
and size of the signature. and size of the signature.
o How to deal with crypto protocols that use public key encryption o How to deal with crypto protocols that use public key encryption
algorithms; this document only lists how to work with signature algorithms; this document only lists how to work with signature
algorithms. Encoding composite public keys is straightforward; algorithms. Encoding composite public keys is straightforward;
encoding composite ciphertexts is less so - we decided to put that encoding composite ciphertexts is less so - we decided to put that
off to another draft. off to another draft.
10. IANA Considerations 5. IANA Considerations
_EDNOTE: This section will include content only if new OIDs or IANA The ASN.1 module OID is TBD. The id-alg-composite OID is to be
codepoints are assigned for it._ assigned by IANA. The authors suggest to use the id-pkix arc for
this usage:
11. Security Considerations id-alg-composite OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) composite(??) }
_EDNOTE: This section includes the Security Considerations._ 6. Security Considerations
o CA implementations need to be careful when checking for 6.1. Policy for Deprecated and Acceptable Algorithms
compromised key reuse, for example as required by WebTrust
regulations; unpack the CompositePublicKey structure and compare
individual keys.
o The corresponding multi-key encryption routine is considerably Traditionally, a public key, certificate, or signature contains a
more prone to implementation errors that will result in a single cryptographic algorithm. If and when an algorithm becomes
catestrophic loss of security, as compared with the signature deprecated (for example, RSA-512, or SHA1), it is obvious that
algorithms specified in this document. structures using that algorithm are implicitly revoked.
12. Appendices In the composite model this is less obvious since a single public
key, certificate, or signature may contain a mixture of deprecated
and non-depricated algorithms. Moreover, implementers may decide
that certain cryptographic algorithms have complementary security
properties and are acceptable in combination even though neither
algoritm is acceptable by itself.
12.1. Intellection Property Considerations In Section 3.2, we specify that the signature verification routine
must include a step to check that the combination of algorithms is
acceptable under local policy:
The authors claim no IPR associated with any of the content of this 2. Check policy to see whether A1, A2, ..., An constitutes a valid
draft. combination of algorithms.
if not checkPolicy(A1, A2, ..., An), then
output "Invalid signature"
12.2. Comparison with draft-truskovsky-lamps-pq-hybrid-x509 While intentionally not specified in this document, implementors
should put careful thought into implementing a meaningfull policy
mechinism within the context of their signature verification engines.
_EDNOTE: This section will explain the differences from . IPR Claims 6.2. Protection of Private Keys
should be mentioned here if necessary. Other things to consider are
the things like simplicity and format, inadvertnt implementation
errors, algorithm agility._[I-D.truskovsky-lamps-pq-hybrid-x509]
13. Contributors This structures described in this document do not protect the private
keys information in any way unless combined with a security protocol
or encryption properties of the objects (if any) where the
CompositePrivateKey is used (see next Section).
Protection of the private key information is vital to public key
cryptography. The consequences of disclosure depend on the purpose
of the private key. If a private key is used for signature, then the
disclosure allows unauthorized signing. If a private key is used for
key management, then disclosure allows unauthorized parties to access
the managed keying material. The encryption algorithm used in the
encryption process must be as 'strong' as the key it is protecting.
6.3. Checking for Compromised Key Reuse
CA implementations need to be careful when checking for compromised
key reuse, for example as required by WebTrust regulations; when
checking for compromised keys, you MUST unpack the CompositePublicKey
structure and compare individual component keys.
6.4. Composite Encryption and KEMs
This document deals only with signature keys. While the
CompositePublicKey and CompositePrivateKey structures could equally
be used to hold encryption or KEM keys, the authors warn that there
are non-trivial design decisions to be made when constructing a
multi-key public key encryption or KEM algorithm. Some of these
design and implementation decisions, if done incorrectly will result
in a catastrophic loss of security. We leave it to the community to
standardize analogous composite encryption and KEM schemes.
7. Appendices
7.1. ASN.1 Module
<CODE STARTS>
Composite-Signatures-2019
{ TBD }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009 -- RFC 5912 [X509ASN1]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
SubjectPublicKeyInfo
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) }
OneAsymmetricKey
FROM AsymmetricKeyPackageModuleV1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0)
id-mod-asymmetricKeyPkgV1(50) } ;
--
-- Object Identifiers
--
id-alg-composite OBJECT IDENTIFIER ::= { TBD }
--
-- Public Key
--
pk-Composite PUBLIC-KEY ::= {
IDENTIFIER id-alg-composite
KEY CompositePublicKey
PARAMS ARE absent
CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
PRIVATE-KEY CompositePrivateKey
}
CompositePublicKey ::= SEQUENCE SIZE (1..MAX) OF SubjectPublicKeyInfo
CompositePrivateKey ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
--
-- Signature Algorithm
--
sa-CompositeSignature SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-composite
VALUE CompositeSignatureValue
PARAMS TYPE CompositeParams ARE required
PUBLIC-KEYS { pk-Composite }
SMIME-CAPS { IDENTIFIED BY id-alg-composite } }
CompositeParams ::= SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier
CompositeSignatureValue ::= SEQUENCE SIZE (1..MAX) OF BIT STRING
END
<CODE ENDS>
7.2. Intellectual Property Considerations
The authors are aware that Massimiliano Pala and CableLabs have
applied for Intellectual Property Rights around composite key,
signatures, and certificates. We have a verbal agreement with Max
that this IP will be made freely available to the community.
As of this version of the draft, the authors have reviewed and
provided feedback on the March 24, 2019 version of the IPR
disclosure, available at https://datatracker.ietf.org/ipr/3481/, and
are awaiting the posting of an updated version that covers this
draft.
EDNOTE: remove this section once the IPR disclosure is posted and
tagged against this draft.
8. Contributors and Acknowledgements
This document incorporates contributions and comments from a large This document incorporates contributions and comments from a large
group of experts. The Editor would especially like to acknowledge group of experts. The Editors would especially like to acknowledge
the tireless dedication of the following people, who attended many the expertise and tireless dedication of the following people, who
long meetings and generated millions of bytes of electronic mail over attended many long meetings and generated millions of bytes of
the past 3 years months in pursuit of this document: electronic mail and VOIP traffic over the past year in pursuit of
this document:
John Gray (Entrust Datacard), Serge Mister (Entrust Datacard), Scott
Fluhrer (Cisco Systems), Panos Kampanakis (Cisco Systems), Daniel Van
Geest (ISARA), and Tim Hollebeek (Digicert).
We are grateful to all, including any contributors who may have been We are grateful to all, including any contributors who may have been
inadvertently omitted from this list. inadvertently omitted from this list.
14. Acknowledgenents This document borrows text from similar documents, including those
referenced below. Thanks go to the authors of those documents.
"Copying always makes things easier and less error prone" -
[RFC8411].
_EDNOTE: this section include all those that need to be acknowledged 9. References
in the draft_
15. References 9.1. Normative References
15.1. Normative References [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC 1421, DOI 10.17487/RFC1421, February
1993, <https://www.rfc-editor.org/info/rfc1421>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
Request Syntax Specification Version 1.7", RFC 2986, "Internet X.509 Public Key Infrastructure Certificate
DOI 10.17487/RFC2986, November 2000, Management Protocol (CMP)", RFC 4210,
<https://www.rfc-editor.org/info/rfc2986>. DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References 9.2. Informative References
[I-D.pala-composite-crypto] [I-D.pala-composite-crypto]
Pala, M., "Composite Public Keys and Signatures", draft- Pala, M., "Composite Public Keys and Signatures", draft-
pala-composite-crypto-00 (work in progress), February pala-composite-crypto-03 (work in progress), March 2019.
2019.
[I-D.truskovsky-lamps-pq-hybrid-x509] [I-D.truskovsky-lamps-pq-hybrid-x509]
Truskovsky, A., Geest, D., Fluhrer, S., Kampanakis, P., Truskovsky, A., Geest, D., Fluhrer, S., Kampanakis, P.,
Ounsworth, M., and S. Mister, "Multiple Public-Key Ounsworth, M., and S. Mister, "Multiple Public-Key
Algorithm X.509 Certificates", draft-truskovsky-lamps-pq- Algorithm X.509 Certificates", draft-truskovsky-lamps-pq-
hybrid-x509-01 (work in progress), August 2018. hybrid-x509-01 (work in progress), August 2018.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the
Cryptographic Algorithm Object Identifier Range",
RFC 8411, DOI 10.17487/RFC8411, August 2018,
<https://www.rfc-editor.org/info/rfc8411>.
Authors' Addresses Authors' Addresses
Mike Ounsworth Mike Ounsworth
Entrust Datacard Limited Entrust Datacard Limited
1000 Innovation Drive 1000 Innovation Drive
Ottawa, Ontario K2K 1E3 Ottawa, Ontario K2K 1E3
Canada Canada
Email: mike.ounsworth@entrustdatacard.com Email: mike.ounsworth@entrustdatacard.com
Serge Mister Massimiliano Pala
Entrust Datacard Limited CableLabs
Email: serge.mister@entrustdatacard.com
John Gray
Entrust Datacard Limited
Email: john.gray@entrustdatacard.com
Scott Fluhrer
Cisco Systems
Email: sfluhrer@cisco.com
Panos Kampanakis
Cisco Systems
Email: pkampana@cisco.com Email: director@openca.org
 End of changes. 130 change blocks. 
436 lines changed or deleted 676 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/