Internet Draft Ari Singer, NTRU
Document: draft-ietf-pkix-pkalgs-supp-00.txt William Whyte, NTRU
Expires: January 2002 July 2001
Supplemental Algorithms and Identifiers for the
Internet X.509 Public Key Infrastructure
Certificate and CRL Profile
<draft-ietf-pkix-pkalgs-supp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Conventions used in this document
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 RFC 2119
[RFC2119].
Abstract
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys, including
NSS digital signatures and NTRU and NSS subject public keys used in
the Internet X.509 Public Key Infrastructure (PKI). Digital
signatures are used to sign certificates and certificate revocation
lists (CRLs). Certificates include the public key of the named
subject. This document is intended to be a companion to draft-ietf-
pkix-ipki-pkalgs-03.txt [PKIX-ALGS] and may be merged with that
document in future revisions if approved by the PKIX working group.
Table of Contents
Singer INTERNET DRAFT - Expires January 2002 [Page 1]
Supplemental Algorithms and Identifiers July 2001
Status of this Memo................................................1
Conventions used in this document..................................1
Abstract...........................................................1
1. Overview........................................................3
2. Algorithm Support...............................................3
2.1 Signature Algorithms...........................................4
2.1.1 NSS Signature Algorithm......................................4
2.2 Subject Public Key Algorithms..................................6
2.2.1 NTRU Keys....................................................6
2.2.2 NSS Keys....................................................11
3. ASN.1 Module...................................................16
4. Security Considerations........................................22
5. Intellectual Property Rights...................................22
6. References.....................................................22
Authors' Addresses................................................23
Singer INTERNET DRAFT - Expires January 2002 [Page 2]
Supplemental Algorithms and Identifiers July 2001
1. Overview
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI). This specification
supplements RFC 2459 [RFC2459], "Internet Public Key Infrastructure:
X.509 Certificate and CRL Profile". Implementations of this
specification must also conform to RFC 2459 [RFC2459]. This
document is being written concurrently with the PKIX public key
algorithms Internet Draft [PKIX-ALGS] (the latest version as of this
writing is draft-ietf-pkix-ipki-pkalgs-03.txt). It is intended that
when this document is completed and approved by the PKIX working
group that it be merged with that document. The format of this
document is written to approximately match the format of that
Internet Draft.
This specification defines the contents of the signatureAlgorithm,
signatureValue, signature and subjectPubliKeyInfo fields within
Internet X.509 certificates and CRLs.
This document does not currently introduce any new one-way hash
functions, however it specifies the use of SHA-256, SHA-384 and SHA-
512 hash algorithms as defined in the draft of FIPS 180-2 [FIPS180-
2] as well as the SHA-1 hash algorithm as defined in FIPS 180-1
[FIPS180-1] with the NSS signature algorithm. It is anticipated
that future revisions will include the algorithm identifiers and
ASN.1 encoding of the FIPS 180-2 hash algorithms.
This specification describes the encoding of digital signatures
generated with the following cryptographic algorithms;
* NTRU Signature Scheme (NSS).
It is anticipated that future revisions of this document will
include the extended version of the Digital Signature Algorithm
(DSA) [FIPS186-2], which has not yet been published. In addition,
it is anticipated that the document will include the algorithm
identifiers and ASN.1 encoding of pre-existing algorithms (e.g. RSA)
when used in conjunction with the FIPS 180-2 hash algorithms.
This document specifies the contents of the subjectPublicKeyInfo
field in Internet X.509 certificates. For each algorithm, the
appropriate alternatives for the keyUsage extension are provided.
This specification describes encoding formats for public keys used
with the following cryptographic algorithms:
* NTRU Encryption Scheme (NTRU)
* NTRU Signature Scheme (NSS)
2. Algorithm Support
This section describes cryptographic algorithms that may be used
with the Internet X.509 Certificate and CRL Profile. It describes
the NSS digital signature algorithm, which may be used to sign
certificates and CRLs, and identifies OIDs and ASN.1 encoding for
public keys contained in a certificate. It is anticipated that
Singer INTERNET DRAFT - Expires January 2002 [Page 3]
Supplemental Algorithms and Identifiers July 2001
additional algorithms, such as the extended version of DSA, will be
included in future revisions.
Conforming CAs and application are not required to support the
algorithms or algorithm identifiers described in this section.
However, conforming CAs and applications that use the algorithms
identified here MUST support them as specified.
2.1 Signature Algorithms
Certificates and CRLs conforming to RFC 2459 [RFC2459] may be signed
with any public key signature algorithm. The certificate or CRL
indicates the algorithm through an algorithm identifier, which
appears in the signatureAlgorithm field within the Certificate or
CertificateList. This algorithm identifier is an OID and has
optionally associated parameters. This section identifies algorithm
identifiers and parameters that MUST be used in the
signatureAlgorithm field in a Certificate or CertificateList.
Signature algorithms are always used in conjunction with a one-way
hash function.
This section identifies OIDs for NSS. Details for the contents of
the parameters component for NSS are provided.
The data to be signed (e.g., the one-way hash function output value)
is formatted for the signature algorithm to be used. Then, a
private key operation (e.g. NSS signature primitive) is performed to
generate the signature value. This signature value is then ASN.1
encoded as a BIT STRING and included in the Certificate or
CertificateList in the signature field.
2.1.1 NSS Signature Algorithm
The NSS signature algorithm was invented by Hoffstein, Pipher and
Silverman. It is defined in Efficient Embedded Security Standard
(EESS) #1 [EESS#1]. This profile defines a single signature
algorithm, NSS signature algorithm with the SHA-1, SHA-256, SHA-384
or SHA-512 one-way hash function.
The signature algorithm is implemented using the padding and
encoding conventions described in EESS #1 [EESS#1]. The message
digest is computed using the SHA-1 Hash Algorithm [FIPS180-1] or any
of the SHA-2 algorithms [FIPS180-2] and the message digest is
encoded using the MGF1 mask generation function as specified in Std
IEEE 1363-2000 [IEEE1363].
Unlike previously defined public-key signature algorithms, the
object identifier for the NSS signature algorithm does not specify
the hash function. Rather, the parameter field in the
AlgorithmIdentifier contains an indication of the hash function as
well as the encoding methods that are to be used.
Singer INTERNET DRAFT - Expires January 2002 [Page 4]
Supplemental Algorithms and Identifiers July 2001
The ASN.1 object identifier used to identify this signature
algorithm is:
id-ntru-EESS1v1-SVSSA OBJECT IDENTIFIER ::=
{ iso(1) ISO Identified Organization(3) US Department
of Defense(6) Internet(1) Private(4) Enterprises(1)
NTRU Cryptosystems(8342) eess(1) eess-1(1) eess1-
algs(1) 2}
When this OID appears in the signatureAlgorithm field or the
signature field of an X.509 certificate, the encoding SHALL omit the
parameters field. That is, the AlgorithmIdentifier shall be a
SEQUENCE of one component: the OBJECT IDENTIFIER id-ntru-EESS1v1-
SVSSA.
The NSS parameters in the subjectPublicKeyInfo field of the
certificate of the issuer shall apply to the verification of the
signature.
When signing, the NSS algorithm generates a signature polynomial.
This polynomial SHALL be encoded as an OCTET STRING as described in
EESS #1 [EESS#1]. The signature SHALL be ASN.1 encoded using the
following ASN.1 structure:
NSSSignedData ::= NTRUPublicVector
NTRUPublicVector ::= CHOICE {
modQVector [0] IMPLICIT ModQVector,
packedModQVector [1] IMPLICIT PackedModQVector
...}
ModQVector ::= OCTET STRING
PackedModQVector ::= OCTET STRING
The field choices of type NTRUPublicVector have the following
meanings:
modQVector is the representation of the NTRUPublicVector in
unpacked form. For a polynomial of degree N-1 with
coefficients reduced mod q, each of the N bytes of the OCTET
STRING represent integers x in the range 0 <= x < q
corresponding to the coefficient values of the polynomial from
lowest degree to highest.
packedModQVector is the representation of the NTRUPublicVector
in packed form. For a polynomial of degree N-1 with
coefficients reduced mod q, each log_2(q) bits of the OCTET
STRING represent integers x in the range 0 <= x < q
corresponding to the coefficient values of the polynomial from
lowest degree to highest. The values are packed starting from
the left, without any intermediate padding, irrespective of the
byte boundaries and the final byte of the OCTET STRING is
padded on the right with zeros (if necessary).
Singer INTERNET DRAFT - Expires January 2002 [Page 5]
Supplemental Algorithms and Identifiers July 2001
Implementations that sign certificates using NSS SHOULD encode the
signature as a ModQVector.
2.2 Subject Public Key Algorithms
Certificates conforming to RFC 2459 [RFC2459] may convey a public
key for any public key algorithm. The certificate indicates the
algorithm through an algorithm identifier. This algorithm
identifier is an OID and optionally associated parameters.
This section identifies preferred OIDs and parameters for the NTRU
and NSS algorithms. Conforming CAs MUST use the identified OIDs
when issuing certificates containing public keys for these
algorithms. Conforming applications supporting any of these
algorithms MUST, at a minimum, recognize the OIDs identified in this
section.
2.2.1 NTRU Keys
This section identifies the preferred OID and parameter encoding for
the inclusion of an NTRU public key in a certificate. The NTRU
encryption algorithm is defined in EESS #1 [EESS#1].
The OID id-ntru-EESS1v1-SVES identifies NTRU public keys.
id-eess1 OBJECT IDENTIFIER ::=
{ iso(1) ISO Identified Organization(3) US Department
of Defense(6) Internet(1) Private(4) Enterprises(1)
NTRU Cryptosystems(8342) eess(1) 1}
id-eess1-algs OBJECT IDENTIFIER ::= {id-eess1 1}
id-ntru-EESS1v1-SVES OBJECT IDENTIFIER ::= {id-eess1-algs 1}
The id-ntru-EESS1v1-SVES OID is intended to be used in the algorithm
field of a value of type AlgorithmIdentifier. NTRU requires use of
certain parameters with the public key. The parameters may be
implied by context, implicitly included through reference of a
degree, implicitly included through reference of a standard
parameter set or explicitly included in the certificate.
EESS1v1-SVES-Parameters ::= CHOICE {
degree INTEGER
(CONSTRAINED BY {--must be 251,
347 or 503}),
standardNTRUParameters OBJECT IDENTIFIER
{{NTRUParameters}},
explicitNTRUParameters ExplicitNTRUParameters,
externalParameters NULL
}
When the parameters are implied by context, the parameters field
SHALL contain externalParameters, which is the ASN.1 value NULL.
Singer INTERNET DRAFT - Expires January 2002 [Page 6]
Supplemental Algorithms and Identifiers July 2001
When the parameters are specified by degree, the values are
restricted to 251, 347 and 503. For the three permitted choices,
the parameters are defined to be ees251ep1, ees347ep1 and ees503ep1
respectively as defined in EESS #1 [EESS#1]. Specifying the degree
is the preferred way for transmitting parameter information for the
scheme when the parameters are not implied by context.
When the parameters are specified by reference of a standard, the
parameters shall consist of an OID chosen from the list
NTRUParameters. The current list of NTRUParameters OIDs is:
NTRUParameters OBJECT IDENTIFIER ::= {
id-ees251ep1|
id-ees347ep1|
id-ees503ep1|
...}
The above object identifiers are specified by:
id-eess1-params OBJECT IDENTIFIER ::= {id-eess1 2}
id-ees251ep1 OBJECT IDENTIFIER ::= {id-eess1-params 1}
id-ees347ep1 OBJECT IDENTIFIER ::= {id-eess1-params 2}
id-ees503ep1 OBJECT IDENTIFIER ::= {id-eess1-params 3}
When the parameters are explicitly included, they SHALL be encoded
in the ASN.1 structure ExplicitNTRUParameters:
ExplicitNTRUParameters ::= SEQUENCE {
version INTEGER,
degree INTEGER,
bigModulus INTEGER,
smallModulus SmallModulus,
mrgm AlgorithmIdentifier
{{ntruEESS1v1MRGMs}},
db INTEGER,
bvgm AlgorithmIdentifier
{{ntruEESS1v1BVGMs}},
...}
SmallModulus ::= CHOICE {
integerValue INTEGER,
polynomialValue NTRUGeneralPolynomial
}
NTRUGeneralPolynomial ::= SEQUENCE {
degree INTEGER,
q INTEGER,
coefficients TruncatedModQVector
}
TruncatedModQVector ::= OCTET STRING
Singer INTERNET DRAFT - Expires January 2002 [Page 7]
Supplemental Algorithms and Identifiers July 2001
The fields of type NTRUGeneralPolynomial have the following
meanings:
degree is the degree of the polynomial.
q is a modulus; more generally, q is an upper bound on the
value of the coefficients.
coefficients is the list of coefficients, listed as a
ModQVector with only degree+1 coefficient entries. If q < 257,
each coefficient is stored in a single byte. If q > 256 and q
< 2^16, each coefficient is stored in two bytes.
The fields of type ExplicitNTRUParameters have the following
meanings:
version is the version number, for compatibility with future
revisions of this document. It SHALL be 0 for this version of
the document.
degree is the value N.
bigModulus is the value q. q will be 256 or less.
smallModulus is the value p. It SHALL be represented with the
SmallModulus type, defined below.
mrgm identifies the message representative generation method
using an allowed AlgorithmIdentifier.
db is the size of the random component.
bvgm identifies the blinding value generation method using an
allowed AlgorithmIdentifier.
The fields of type SmallModulus have the following meanings:
integerValue is the value of p if p is an integer.
polynomialValue is the value of p if p is a polynomial.
The AlgorithmIdentifiers used in ExplicitNTRUParameters are
specified below.
ntruEESS1v1MRGMs AlgorithmIdentifier ::= {
{NTRUMRGM1-params IDENTIFIED BY id-mrgm-ntru-1},
...}
id-eess1-encodingMethods OBJECT IDENTIFIER ::= {id-eess1 3}
id-mrgm-ntru-1 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 1}
NTRUMRGM1-params ::= AlgorithmIdentifier {{ntruEESS1v1Hashes}}
Singer INTERNET DRAFT - Expires January 2002 [Page 8]
Supplemental Algorithms and Identifiers July 2001
The identifier id-mrgm-ntru-1 identifies the message representative
generation method MRGM-NTRU1, defined in EESS #1 [EESS#1]. The
parameters identify the hashing mechanism using an allowed
AlgorithmIdentifier.
ntruEESS1v1Hashes AlgorithmIdentifier ::= {
{NULL IDENTIFIED BY id-sha1}|
{NULL IDENTIFIED BY id-sha256}|
{NULL IDENTIFIED BY id-sha384}|
{NULL IDENTIFIED BY id-sha512}|
...}
These identifiers identify the one-way hash algorithms SHA-1
[FIPS180-1] and SHA-2 [TBD].
ntruEESS1v1BVGMs AlgorithmIdentifier ::= {
{NTRUBVGM1-params IDENTIFIED BY id-bvgm-ntru-1},
{NTRUBVGM2-params IDENTIFIED BY id-bvgm-ntru-2},
...}
id-bvgm-ntru-1 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 2}
NTRUBVGM1-params ::= SEQUENCE {
c INTEGER,
prng AlgorithmIdentifier {{ntruEESS1v1PRNGs}},
dr INTEGER
}
id-bvgm-ntru-2 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 3}
NTRUBVGM2-params ::= SEQUENCE {
c INTEGER,
prng AlgorithmIdentifier {{ntruEESS1v1PRNGs}},
dr1 INTEGER,
dr2 INTEGER,
dr3 INTEGER
}
The identifier id-bvgm-ntru-1 identifies blinding value generation
method BVGM-NTRU1, defined in EESS #1 [EESS#1]. The identifier id-
bvgm-ntru-2 identifies blinding value generation method BVGM-NTRU2,
defined in EESS #1 [EESS#1].
The fields of type NTRUBVGM1-params have the following meanings:
c is the random polynomial generation constant used to select
the polynomial r.
prng identifies the pseudo-random number generation algorithm
using an allowed AlgorithmIdentifier.
Singer INTERNET DRAFT - Expires January 2002 [Page 9]
Supplemental Algorithms and Identifiers July 2001
dr is the number of 1s in the blinding value r.
The fields of type NTRUBVGM2-params have the following meanings:
c is the random polynomial generation constant used to select
the polynomial r.
prng identifies the pseudo-random number generation algorithm
using an allowed AlgorithmIdentifier.
dr1 is the number of 1s in the blinding value component r1.
dr2 is the number of 1s in the blinding value component r2.
dr3 is the number of 1s in the blinding value component r3.
The allowed pseudo-random number generation algorithms are defined
by:
ntruEESS1v1PRNGs AlgorithmIdentifier ::= {
{NTRUMGFAlgorithms}|
...}
This identifies the pseudo-random number generation algorithm to be
used when generating blinding values. The only allowed algorithms
are MGF1 (see [IEEE 1363]) using SHA-1 [FIPS180-1] or SHA-2
[FIPS180-2].
NTRUMGFAlgorithms AlgorithmIdentifier ::= {
{MGF1Parameters IDENTIFIED BY id-mgf1}|
...}
pkcs-1 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
1}
id-mgf1 OBJECT IDENTIFIER ::= {pkcs-1 8}
MGF1Parameters ::= AlgorithmIdentifier {{ntruEESS1v1Hashes}}
The NTRU public key MUST be encoded using the ASN.1 type
NTRUPublicKey.
NTRUPublicKey ::= SEQUENCE {
publicKeyVector NTRUPublicVector, -- h
ntruKeyExtensions SET OF NTRUKeyExtension
OPTIONAL}
NTRUKeyExtension ::= CHOICE {
keyID [0] IMPLICIT INTEGER,
...}
The fields of the type NTRUPublicKey have the following meanings:
Singer INTERNET DRAFT - Expires January 2002 [Page 10]
Supplemental Algorithms and Identifiers July 2001
publicKeyVector is the polynomial h. If the NTRUPublicVector
is a ModQVector, each coefficient will be represented by one
byte starting with the lowest degree and going to the highest.
If the NTRUPublicVector is a PackedModQVector, this is the
OCTET STRING representing h obtained using RE2BSP and then
BS2OSP as defined in EESS #1 [EESS#1]. All coefficients up to
X^(N-1) SHALL be explicitly included in publicKeyVector.
Representing the NTRU public key as a ModQVector is the
preferred method.
ntruKeyExtensions is provided for future extensibility. Only
one extension is currently defined.
The fields of the type NTRUKeyExtension have the following meanings:
keyID can be used to associate a unique key identifier with the
key.
If the keyUsage extension is present in an end entity certificate
that conveys an NTRU public key, any combination of the following
values MAY be present:
keyEncipherment;
dataEncipherment;
If the keyUsage extension is present in a CA certificate that
conveys an NTRU public key, any combination of the following values
MAY be present:
keyEncipherment; and
dataEncipherment.
2.2.2 NSS Keys
This section identifies the preferred OID and parameter encoding for
the inclusion of an NSS public key in a certificate. The NSS
signature algorithm is defined in EESS #1 [EESS#1].
The OID id-ntru-EESS1v1-SVSSA identifies NSS public keys.
id-ntru-EESS1v1-SVSSA OBJECT IDENTIFIER ::= {id-eess1-algs 2}
The id-ntru-EESS1v1-SVSSA OID is intended to be used in the
algorithm field of a value of type AlgorithmIdentifier. NSS
requires use of certain parameters with the public key. The
parameters may be implied by context (e.g. they may be inherited
from the issuer), implicitly included through reference of a degree,
implicitly included through reference of a standard parameter set or
explicitly included in the certificate.
EESS1v1-SVSSA-Parameters ::= CHOICE {
degree INTEGER
(CONSTRAINED BY {--must be 251,
347 or 503}),
Singer INTERNET DRAFT - Expires January 2002 [Page 11]
Supplemental Algorithms and Identifiers July 2001
standardNSSParameters OBJECT IDENTIFIER
{{NSSParameters}},
explicitNSSParameters ExplicitNSSParameters,
externalParameters NULL
}
When the parameters are implied by context, the parameters field
SHALL contain externalParameters, which is the ASN.1 value NULL.
When the parameters are specified by degree, the values are
restricted to 251, 347 and 503. For the three permitted choices,
the parameters are defined to be ees251sp1, ees347sp1 and ees503sp1
respectively as defined in EESS #1 [EESS#1]. Specifying the degree
is the preferred way for transmitting parameter information for the
scheme when the parameters are not implied by context.
When the parameters are specified by reference of a standard, the
parameters shall consist of an OID chosen from the list
NSSParameters. The current list of NSSParameters OIDs is:
NSSParameters OBJECT IDENTIFIER ::= {
id-ees251sp1|
id-ees347sp1|
id-ees503sp1|
...}
The above object identifiers are specified by:
id-ees251sp1 OBJECT IDENTIFIER ::= {id-eess1-params 4}
id-ees347sp1 OBJECT IDENTIFIER ::= {id-eess1-params 5}
id-ees503sp1 OBJECT IDENTIFIER ::= {id-eess1-params 6}
When the parameters are explicitly included, they SHALL be encoded
in the ASN.1 structure ExplicitNSSParameters:
ExplicitNSSParameters ::= SEQUENCE {
version INTEGER,
degree INTEGER,
bigModulus INTEGER,
smallModulus SmallModulus,
bounds NSSBounds,
hash AlgorithmIdentifier
{{ntruEESS1v1Hashes}},
mrgm AlgorithmIdentifier
{{nssEESS1v1MRGMs}},
...}
NSSBounds ::= SEQUENCE {
version INTEGER,
l2NormBound1 INTEGER,
l2NormBound2 INTEGER,
lInfBounds0 Bounds,
lInfBounds1 Bounds,
lInfBounds2 Bounds,
Singer INTERNET DRAFT - Expires January 2002 [Page 12]
Supplemental Algorithms and Identifiers July 2001
lInfBounds3 Bounds,
devBound0 INTEGER,
devBound1 INTEGER,
devBound2 INTEGER,
devBound3 INTEGER,
devBoundTot0 INTEGER,
devBoundTot1 INTEGER,
devBoundTot2 INTEGER,
devBoundTot3 INTEGER,
...}
Bounds ::= SEQUENCE {
minimum INTEGER,
maximum INTEGER
}
The fields of type ExplicitNSSParameters have the following
meanings:
version is the version number, for compatibility with future
revisions of this document. It SHALL be 0 for this version of
the document.
degree is the value N.
bigModulus is the value q. q will be 256 or less.
smallModulus is the value p. It SHALL be represented with the
SmallModulus type, defined in section 2.2.1.
bounds is the list of values of the bounds that are used to
check the validity of the signature.
hash identifies the hash algorithm used using an allowed
AlgorithmIdentifier.
mrgm identifies the message representative generation method
using an allowed AlgorithmIdentifier.
The type NSSBounds is used to encode the bounds used when verifying
the NSS signature. The fields of type NSSBounds have the following
meaning:
version is the version number, for compatibility with future
revisions of this document. It shall be 0 for this version of
the document.
l2NormBound1 is the L2 norm bound on a single signature
component, s or t.
l2NormBound2 is the L2 norm bound on the combined signature
s||t.
lInfBounds0 gives LInfBoundjMin and LInfBoundjMax for j = 0.
Singer INTERNET DRAFT - Expires January 2002 [Page 13]
Supplemental Algorithms and Identifiers July 2001
lInfBounds1 gives LInfBoundjMin and LInfBoundjMax for j = 1.
lInfBounds2 gives LInfBoundjMin and LInfBoundjMax for j = 2.
lInfBounds3 gives LInfBoundjMin and LInfBoundjMax for j = 3.
devBound0 is the deviation bound DevBound0.
devBound1 is the deviation bound DevBound1.
devBound2 is the deviation bound DevBound2.
devBound3 is the deviation bound DevBound3.
devBoundTot0 is the deviation bound DevBoundTot0.
devBoundTot1 is the deviation bound DevBoundTot1.
devBoundTot2 is the deviation bound DevBoundTot2.
devBoundTot3 is the deviation bound DevBoundTot3.
Within the NSSBounds type, the Bounds type encodes pairs of upper
and lower bounds on values. The fields of type Bounds have the
following meaning:
minimum is the lower bound.
maximum is the upper bound.
The AlgorithmIdentifiers for the field hash of ExplicitNSSParameters
are chosen from the set ntruEESS1v1Hashes, which is defined in
section 2.2.1.
The AlgorithmIdentifiers for the field mrgm of ExplicitNSSParameters
are specified below.
nssEESS1v1MRGMs AlgorithmIdentifier ::= {
{NSSMRGM1-params IDENTIFIED BY id-mrgm-nss-1},
{NSSMRGM2-params IDENTIFIED BY id-mrgm-nss-2},
...}
id-mrgm-nss-1 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 4}
NSSMRGM1-params ::= SEQUENCE {
c INTEGER
prng AlgorithmIdentifier
{{ntruEESS1v1PRNGs}},
di INTEGER
}
id-mrgm-nss-2 OBJECT IDENTIFIER ::=
Singer INTERNET DRAFT - Expires January 2002 [Page 14]
Supplemental Algorithms and Identifiers July 2001
{id-eess1-encodingMethods 5}
NSSMRGM2-params ::= SEQUENCE {
c INTEGER
prng AlgorithmIdentifier
{{ntruEESS1v1PRNGs}},
di1 INTEGER,
di2 INTEGER,
di3 INTEGER
}
The identifier id-mrgm-nss-1 identifies the message representative
generation method MRGM-NSS1, defined in EESS #1 [EESS#1]. The
identifier id-mrgm-nss-2 identifies the message representative
generation method MRGM-NSS2, defined in EESS #1 [EESS#1].
The fields of type NSSMRGM1-params have the following meanings:
c is the random polynomial generation constant used to select
the polynomial i.
prng identifies the pseudo-random number generation method
using an allowed AlgorithmIdentifier.
di is the number of 1's and -1's in the message representative
i.
The fields of type NSSMRGM2-params have the following meanings:
c is the random polynomial generation constant used to select
the polynomial i.
prng identifies the pseudo-random number generation method
using an allowed AlgorithmIdentifier.
di1 is the number of 1's and -1's in the message representative
component i1.
di2 is the number of 1's and -1's in the message representative
component i2.
di3 is the number of 1's and -1's in the message representative
component i3.
The allowed pseudo-random number generation algorithms are chosen
from the set ntruEESS1v1PRNGs, which is defined in section 2.2.1.
The NSS public key MUST be encoded using the ASN.1 type
NSSPublicKey.
NSSPublicKey ::= SEQUENCE {
publicKeyVector NTRUPublicVector, -- h
nssKeyExtensions SET OF NSSKeyExtension
OPTIONAL}
Singer INTERNET DRAFT - Expires January 2002 [Page 15]
Supplemental Algorithms and Identifiers July 2001
NSSKeyExtension ::= CHOICE {
keyID [0] IMPLICIT INTEGER,
...}
The fields of the type NSSPublicKey have the following meanings:
publicKeyVector is the polynomial h. If the NTRUPublicVector
is a ModQVector, each coefficient will be represented by one
byte starting with the lowest degree and going to the highest.
If the NTRUPublicVector is a PackedModQVector, this is the
OCTET STRING representing h obtained using RE2BSP and then
BS2OSP as defined in EESS #1 [EESS#1]. All coefficients up to
X^(N-1) SHALL be explicitly included in publicKeyVector.
Representing the NSS public key as a ModQVector is the
preferred method.
nssKeyExternsions is provided for future extensibility. Only
one extension is currently defined.
The fields of the type NSSKeyExtension have the following meanings:
keyID can be used to associate a unique key identifier with the
key.
If the keyUsage extension is present in an end entity certificate
that conveys an NSS public key, any combination of the following
values MAY be present:
digitalSignature;
nonRepudiation;
If the keyUsage extension is present in a CA certificate that
conveys an NSS public key, any combination of the following values
MAY be present:
digitalSignature;
nonRepudiation;
keyCertSign; and
cRLSign.
3. ASN.1 Module
-- PKIXAlgorithmOIDTBD {--TBD}
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- EXPORTS ALL;
-- IMPORTS;
pkcs-1 OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
1}
Singer INTERNET DRAFT - Expires January 2002 [Page 16]
Supplemental Algorithms and Identifiers July 2001
id-mgf1 OBJECT IDENTIFIER ::= {pkcs-1 8}
id-sha1 OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) 26}
id-sha256 OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1}
id-sha384 OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2}
id-sha512 OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) country(16) us(840) organization(1)
gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3}
-- END IMPORTS
----
---- General Types
----
ModQVector ::= OCTET STRING
PackedModQVector ::= OCTET STRING
NTRUPublicVector ::= CHOICE {
modQVector [0] IMPLICIT ModQVector,
packedModQVector [1] IMPLICIT PackedModQVector
...}
TruncatedModQVector ::= OCTET STRING
NTRUGeneralPolynomial ::= SEQUENCE {
degree INTEGER,
q INTEGER,
coefficients TruncatedModQVector
}
SmallModulus ::= CHOICE {
integerValue INTEGER,
polynomialValue NTRUGeneralPolynomial
}
Bounds ::= SEQUENCE {
minimum INTEGER,
maximum INTEGER
}
----
---- General OIDs and AlgorithmIdentifiers
Singer INTERNET DRAFT - Expires January 2002 [Page 17]
Supplemental Algorithms and Identifiers July 2001
----
id-eess1 OBJECT IDENTIFIER ::=
{ iso(1) ISO Identified Organization(3) US Department
of Defense(6) Internet(1) Private(4) Enterprises(1)
NTRU Cryptosystems(8342) eess(1) 1}
id-eess1-algs OBJECT IDENTIFIER ::= {id-eess1 1}
id-eess1-params OBJECT IDENTIFIER ::= {id-eess1 2}
id-eess1-encodingMethods OBJECT IDENTIFIER ::= {id-eess1 3}
ntruEESS1v1Hashes AlgorithmIdentifier ::= {
{NULL IDENTIFIED BY id-sha1}|
{NULL IDENTIFIED BY id-sha256}|
{NULL IDENTIFIED BY id-sha384}|
{NULL IDENTIFIED BY id-sha512}|
...}
ntruEESS1v1PRNGs AlgorithmIdentifier ::= {
{NTRUMGFAlgorithms}|
...}
NTRUMGFAlgorithms AlgorithmIdentifier ::= {
{MGF1Parameters IDENTIFIED BY id-mgf1}|
...}
MGF1Parameters ::= AlgorithmIdentifier {{ntruEESS1v1Hashes}
----
---- NSS Keys and Signatures
----
-- OID for NSS Algorithm and Public Key
id-ntru-EESS1v1-SVSSA OBJECT IDENTIFIER ::= {id-eess1-algs 2}
-- OIDs for NSS Parameter Sets
id-ees251sp1 OBJECT IDENTIFIER ::= {id-eess1-params 4}
id-ees347sp1 OBJECT IDENTIFIER ::= {id-eess1-params 5}
id-ees503sp1 OBJECT IDENTIFIER ::= {id-eess1-params 6}
-- OIDs for NSS Encoding Methods
id-mrgm-nss-1 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 4}
id-mrgm-nss-2 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 5}
-- Encoding for NSS Public Key
EESS1v1-SVSSA-Parameters ::= CHOICE {
degree INTEGER
Singer INTERNET DRAFT - Expires January 2002 [Page 18]
Supplemental Algorithms and Identifiers July 2001
(CONSTRAINED BY {--must be 251,
347 or 503}),
standardNSSParameters OBJECT IDENTIFIER
{{NSSParameters}},
explicitNSSParameters ExplicitNSSParameters,
externalParameters NULL
}
NSSParameters OBJECT IDENTIFIER ::= {
id-ees251sp1|
id-ees347sp1|
id-ees503sp1|
...}
ExplicitNSSParameters ::= SEQUENCE {
version INTEGER,
degree INTEGER,
bigModulus INTEGER,
smallModulus SmallModulus,
bounds NSSBounds,
hash AlgorithmIdentifier
{{nssEESS1v1Hashes}},
mrgm AlgorithmIdentifier
{{nssEESS1v1MRGMs}},
...}
NSSBounds ::= SEQUENCE {
version INTEGER,
l2NormBound1 INTEGER,
l2NormBound2 INTEGER,
lInfBounds0 Bounds,
lInfBounds1 Bounds,
lInfBounds2 Bounds,
lInfBounds3 Bounds,
devBound0 INTEGER,
devBound1 INTEGER,
devBound2 INTEGER,
devBound3 INTEGER,
devBoundTot0 INTEGER,
devBoundTot1 INTEGER,
devBoundTot2 INTEGER,
devBoundTot3 INTEGER,
...}
nssEESS1v1MRGMs AlgorithmIdentifier ::= {
{NSSMRGM1-params IDENTIFIED BY id-mrgm-nss-1},
{NSSMRGM2-params IDENTIFIED BY id-mrgm-nss-2},
...}
NSSMRGM1-params ::= SEQUENCE {
c INTEGER
prng AlgorithmIdentifier
{{ntruEESS1v1PRNGs}},
di INTEGER
Singer INTERNET DRAFT - Expires January 2002 [Page 19]
Supplemental Algorithms and Identifiers July 2001
}
NSSMRGM2-params ::= SEQUENCE {
c INTEGER
prng AlgorithmIdentifier
{{ntruEESS1v1PRNGs}},
di1 INTEGER,
di2 INTEGER,
di3 INTEGER
}
NSSPublicKey ::= SEQUENCE {
publicKeyVector NTRUPublicVector, -- h
nssKeyExtensions SET OF NSSKeyExtension
OPTIONAL}
NSSKeyExtension ::= CHOICE {
keyID [0] IMPLICIT INTEGER,
...}
----
---- NTRU Keys
----
-- OID for NTRU Algorithm and Public Key
id-ntru-EESS1v1-SVSSA OBJECT IDENTIFIER ::=
{ iso(1) ISO Identified Organization(3) US Department of
Defense(6) Internet(1) Private(4) Enterprises(1) NTRU
Cryptosystems(8342) eess(1) eess-1(1) eess1-algs(1) 2}
-- OIDs for NTRU Parameter Sets
id-ees251ep1 OBJECT IDENTIFIER ::= {id-eess1-params 1}
id-ees347ep1 OBJECT IDENTIFIER ::= {id-eess1-params 2}
id-ees503ep1 OBJECT IDENTIFIER ::= {id-eess1-params 3}
-- OIDs for NTRU Encoding Methods
id-mrgm-ntru-1 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 1}
id-bvgm-ntru-1 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 2}
id-bvgm-ntru-2 OBJECT IDENTIFIER ::=
{id-eess1-encodingMethods 3}
-- Encoding for NTRU Public Key
EESS1v1-SVES-Parameters ::= CHOICE {
degree INTEGER
Singer INTERNET DRAFT - Expires January 2002 [Page 20]
Supplemental Algorithms and Identifiers July 2001
(CONSTRAINED BY {--must be 251,
347 or 503}),
standardNTRUParameters OBJECT IDENTIFIER
{{NTRUParameters}},
explicitNTRUParameters ExplicitNTRUParameters,
externalParameters NULL
}
NTRUParameters OBJECT IDENTIFIER ::= {
id-ees251ep1|
id-ees347ep1|
id-ees503ep1|
...}
ExplicitNTRUParameters ::= SEQUENCE {
version INTEGER,
degree INTEGER,
bigModulus INTEGER,
smallModulus SmallModulus,
mrgm AlgorithmIdentifier
{{ntruEESS1v1MRGMs}},
db INTEGER,
bvgm AlgorithmIdentifier
{{ntruEESS1v1BVGMs}},
...}
ntruEESS1v1MRGMs AlgorithmIdentifier ::= {
{NTRUMRGM1-params IDENTIFIED BY id-mrgm-ntru-1},
...}
NTRUMRGM1-params ::= AlgorithmIdentifier {{ntruEESS1v1Hashes}}
ntruEESS1v1BVGMs AlgorithmIdentifier ::= {
{NTRUBVGM1-params IDENTIFIED BY id-bvgm-ntru-1},
{NTRUBVGM2-params IDENTIFIED BY id-bvgm-ntru-2},
...}
NTRUBVGM1-params ::= SEQUENCE {
c INTEGER,
prng AlgorithmIdentifier {{ntruEESS1v1PRNGs}},
dr INTEGER
}
NTRUBVGM2-params ::= SEQUENCE {
c INTEGER,
prng AlgorithmIdentifier {{ntruEESS1v1PRNGs}},
dr1 INTEGER,
dr2 INTEGER,
dr3 INTEGER
}
NTRUPublicKey ::= SEQUENCE {
publicKeyVector NTRUPublicVector, -- h
Singer INTERNET DRAFT - Expires January 2002 [Page 21]
Supplemental Algorithms and Identifiers July 2001
ntruKeyExtensions SET OF NTRUKeyExtension
OPTIONAL}
NTRUKeyExtension ::= CHOICE {
keyID [0] IMPLICIT INTEGER,
...}
END
4. Security Considerations
This document is entirely concerned with security mechanisms. It is
based on the Internet X.509 Public Key Infrastructure Certificate
and CRL Profile [RFC 2459], IEEE P1363.1 [P1363.1] and EESS #1
[EESS#1] and the appropriate security considerations from those
documents apply.
5. Intellectual Property Rights
NTRU Cryptosystems, Inc. has been granted U.S. Patent No. 6,081,597,
which covers aspects of the NTRU public-key encryption scheme, and
has applied for a patent (or patents) that covers the NSS public-key
signature scheme. In addition, NTRU Cryptosystems may have applied
for additional patent coverage on implementation techniques related
to the use of NTRU or NSS. This and any additional patent
information will be sent to the IETF.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to implement
the techniques in this document. Please address the information to
the IETF Executive Director.
6. References
[EESS#1] Efficient Embedded Security Standards (EESS) #1:
Implementation Aspects of NTRU and NSS, Draft Version 3, July 9,
2001, Consortium for Efficient Embedded Security Standards,
Available at http://www.ceesstandards.org.
Singer INTERNET DRAFT - Expires January 2002 [Page 22]
Supplemental Algorithms and Identifiers July 2001
[FIPS180-1] FIPS PUB 180-1, Secure Hash Standard, Federal
Information Processing Standards Publication 180-1, U.S. Department
of Commerce/National Institute of Standards and Technology, National
Technical Information Service, Springfield, Virginia, April 17, 1995
(supersedes FIPS PUB 180). Available at
http://www.itl.nist.gov/div897/pubs/fip180-1.htm.
[FIPS180-2] Draft FIPS PUB 180-2, Secure Hash Standard, Federal
Information Processing Standards Publication 180-2, U.S. Department
of Commerce/National Institute of Standards and Technology, National
Technical Information Service, Springfield, Virginia, May 30, 2001
(draft available at http://csrc.nist.gov/encryption/shs/dfips-180-
2.pdf)
[FIPS186-2] FIPS PUB 186-2, Digital Signature Standard, Federal
Information Processing Standards Publication 186-2, U.S. Department
of Commerce/National Institute of Standards and Technology, National
Technical Information Service, Springfield, Virginia, 2000.
Available at http://csrc.nist.gov/publications/fips/fips186-
2/fips186-2.pdf
[IEEE1363] IEEE Std 1363-2000: IEEE Standard Specifications for
Public-Key Cryptography, IEEE Computer Society, New York, NY, August
2000, Institute of Electrical and Electronics Engineers
[P1363.1] IEEE Draft Standard P1363.1 D2: IEEE Standard
Specifications for Public-Key Cryptographic Techniques Based on Hard
Problems over Lattices, Draft 2, May 2001, Available at
http://grouper.ieee.org/groups/1363.
[PKIX-ALGS] L. Bassham, R. Housley, W. Polk, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and CRL Profile", draft-ietf-pkix-pkalgs-03.txt, July
2001
[RFC2026] S. Bradner, "The Internet Standards Process", IETF RFC
2026, October 1996
[RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", IETF RFC 2119, March 1997
[RFC2459] R. Housley, W. Ford, W. Polk and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", IETF RFC
2459, January 1999
Authors' Addresses
Ari Singer
NTRU
5 Burlington Woods Phone: 1-781-418-2500
Burlington, MA 01803, USA Email: asinger@ntru.com
William Whyte
Singer INTERNET DRAFT - Expires January 2002 [Page 23]
NTRU Algorithms and Identifiers July 2001
NTRU
5 Burlington Woods Phone: 1-781-418-2500
Burlington, MA 01803, USA Email: wwhyte@ntru.com
Singer INTERNET DRAFT - Expires January 2002 [Page 24]
