[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

IPSEC Working Group
Internet Engineering Task                                John Kennedy
INTERNET-DRAFT                                           Cylink Corporation
Expires in six months                                    John Marchioni
                                                         Cylink Corporation
                                                         February 21, 1996

                               DSS Profile for X.509 Certificates

Status of this Memo

This document is a submission to the IETF Internet Protocol Security (IPSEC)
Working Group.  Comments are solicited and should be addressed to the working
group mailing list (ipsec@ans.net) or to the authors.

This document is an Internet-Draft.  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.
Comments should be sent to the IP Security WG mailing list

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.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa),  nic.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Distribution of this memo is unlimited.


This document describes the ASN.1 [1] encoding for an  CCITT 1988
X.509  [2] certificate profiled for use with the NIST Digital Signature
Standard (DSS) [3].

For details not covered in this document the reader should refer to its
base references:  X.509 (1993) | ISO/IEC 9594-8 and Amendment 1 to ITU
Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995.

1. ASN.1 Definition of Certificate

The abstract definition of the certificate is as follows:

Certificate     ::=     SIGNED { SEQUENCE {
        version         [0]     Version DEFAULT v1,
        serialNumber                    CertificateSerialNumber,
        signature                       AlgorithmIdentifier,
        issuer                  Name,
        validity                        Validity,
        subject                 Name,
        subjectPublicKeyInfo            SubjectPublicKeyInfo,
        issuerUniqueIdentifier  [1]     IMPLICIT UniqueIdentifier OPTIONAL,
                                                -- if present, must be v2 or v3
        subjectUniqueIdentifer  [2]     IMPLICIT UniqueIdentifier OPTIONAL,
                                                -- if present, must be v2 or v3
        extensions              [3]     Extensions OPTIONAL

Version ::=     INTEGER { 1(0), v2(1), v3(2) }

CertificateSerialNumber ::=     INTEGER

AlgorithmIdentifier     ::=     SEQUENCE {
        algorithm       ALGORITHM.&id ({SupportedAlgorithms}),
        parameters      ALGORITHM.&id ({SupportedAlgorithms}{ @algorithm}) OPTIONAL }

-- SupportedAlgorithms          ALGORITHM       ::=     {...|...}

-- DSA Signature Algorithm

-- The Digital Signature Algorithm (DSA) is also called the Digital Signature
-- Standard (DSS).  DSA
-- was developed by the U.S. Government, and DSA is used in conjunction with the SHA-1 one
-- way hash function (SHA-1 is described in FIPS 180-1).  DSA is described in FIPS 186.
-- The ASN.1 object identifier used to identify this signature algorithm is:

        dsaWithSHA-1 OBJECT IDENTIFIER  ::=  {
                joint-iso-ccitt(2) country(16) US(840) organization(1) us-government(101) dod(2)
                infosec(1) algorithms(1) dsa-sha1 (2)  }

-- DSA Parameters

- When this object identifier is used with the ASN.1 type AlgorithmIdentifier, the parameters
- component of that type is optional.  If it is absent, the DSA parameters p, q, and g are assumed to
- be known, otherwise the parameters are included using the following ASN.1 structure:

        Dss-Parms  ::=  SEQUENCE  {
                p       OCTET STRING,
                q       OCTET STRING,
                g       OCTET STRING  }

-- DSA Signature Block

-- Prior to the bitstring encoding of the certificate issuers DSA signature the signature block must
-- be encoded using the distinguished rules as follows:

Dss-sig  ::=  SEQUENCE  {
                r       OCTET STRING,
                s       OCTET STRING  }

Validity        ::=     SEQUENCE {
        notBefore       UTCTime,
        notAfter        UTCTime }

SubjectPublicKeyInfo    ::=     SEQUENCE {
        algorithm       AlgorithmIdentifier,
        subjectPublicKey        BIT STRING }

2. Certificate Extensions

The standard extensions are described in Amendment 1 to ITU Rec. X.509 (1993)
| ISO/IEC 9594-8 : 1995.  A subset of extension will need to be chosen
for this profile.  The extensions field allows addition of new fields
to the certificate structure without modification to the ASN.1 definition.
An extension field consists of an extension object identifier,
a criticality flag, and a canonical encoding of a data value of an
ASN.1 type associated with the object identifier already specified.

When a system processes a certificate but does not recognize an
extension, if the criticality flag is FALSE, the extension may be
ignored and the remainder of the certificate information may be
processed as valid.  If the criticality flag is TRUE, an unrecognized
extension shall cause the system to consider the entire certificate invalid.

3. An overview of the use of the Distinguished Encoding Rules (DER) in
   Certificate Signature Operations.

(1) Sign; The signing application converts the abstract value
(or internal representation) of the certificate information into a bit
representation using the DER and signs that bit representation.
The signature is then appended onto the abstract value, and both values
are then BER
(Basic Encoding Rules) encoded to provide a transfer syntax.  The same
encoder used to apply the DER may be used to apply the transfer
syntax, so the transfer syntax can also follow the DER.

(2) Authenticate; The authenticating application will decode the received
certificate (containing the certificate information and issuer signature).
This application will then have an abstract value for both the
certificate information and a signature.  The application will then take the
resulting abstract value of the certificate information and re-encode it
using the DER to produce the same bit representation that was signed.
The received signature can now be authenticated using the exact bitstring
representation used in the signing operation.

When the DER are applied to information, before that information is signed,
the authentication operation (also applying the DER) will always detect if
that information has been modified and the incidence of false
authentication failures is greatly reduced.

4. Security Considerations

Security issues are not discussed in this document

5. References

[1] CCITT Recommendation X.208 (1992),  "Abstract Syntax Notation One"

[2] CCITT Recommendation X.509 (1988),  "The Directory - Authentication

[3] FIPS 186  Digital Signature Standard

Author's Address(es)

Questions about this can be directed to:

John Kennedy
CYLINK Corporation

John Marchioni
CYLINK Corporation

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/