<draft-ietf-ipsec-dss-cert-00.txt>

[John Kennedy <[e-mail]>]

Attached is a copy of a new draft for the working group's review.
Comments should be sent to the IPSEC mailing list ([e-mail]) 
and/or directly to me ([e-mail])

Title: Digital Signature Standard (DSS) Profile for X.509 Certificates
       <draft-ietf-ipsec-dss-cert-00.txt>

Abstract:

This document describes the ASN.1 [1] encoding for a CCITT 1988 X.509 [2]
certificate profiled for use with the U.S. Government's Digital Signature
Standard (DSS) [3].

This profile aligns with the base standards and profile references
listed below.  It is intended to provide guidelines for those developing
software that will be used to issue and use DSS certificates.  This is
to insure that DSS-specific certificate information will be handled
consistently throughout the public key infrastructure.

        X.509 (1993) | ISO/IEC 9594-8
        Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995
        DoD Secure Data Network System (SDNS) SDN.702 Revision 2.7 : 1994
        USPS Postal ECS X.509 Certificate and CRL Profile, Rev. 0.5.: 1996


-----------------------------<begin attachment>---------------------------

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


      Digital Signature Standard (DSS) Profile for X.509 Certificates 
                   <draft-ietf-ipsec-dss-cert-00.txt> 
 
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 ([e-mail]) 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  ([e-mail]) 
 
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. 
 
 
Abstract 
 
This document describes the ASN.1 [1] encoding for a CCITT 1988 X.509 [2]
certificate profiled for use with the U.S. Government's Digital Signature 
Standard (DSS) [3].  

This profile aligns with the base standards and profile references 
listed below.  It is intended to provide guidelines for those developing 
software that will be used to issue and use DSS certificates.  This is 
to insure that DSS-specific certificate information will be handled 
consistently throughout the public key infrastructure.

	X.509 (1993) | ISO/IEC 9594-8
	Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995
	DoD Secure Data Network System (SDNS) SDN.702 Revision 2.7 : 1994
	USPS Postal ECS X.509 Certificate and CRL Profile, Rev. 0.5.: 1996
 
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 { v1(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.  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 issuer's 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 these extensions 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 Framework" 
[3] FIPS 186  Digital Signature Standard 


Author's Addresses

Questions about this document can be directed to:


	John Kennedy
	CYLINK Corporation
	910 Hermosa Court
	Sunnyvale, CA  94086
	[e-mail]
	408-735-5885

	John Marchioni
	CYLINK Corporation
	910 Hermosa Court
	Sunnyvale, CA  94086
	[e-mail]
	408-735-5800