Raj;
I including the GULS SIGNED and SIGNATURE specifications
which Warwick Ford mentioned in his message below.
As Warwick said, these are expected to supercede the
X.509 variants for SIGNED and SIGNATURE.
If what's in GULS today does not suit the needs,
we can still fix that. GULS is now under ISO DIS ballot.
I'm responsible in the US to prepare a ballot response.
We're doing this at an ANSI X3T5 meeting the week of
February 28. This is the last chance before GULS becomes an
International Standard later this year.
Please mail me any comments at:
ews(_at_)cc(_dot_)bellcore(_dot_)com (Emile Soueid)
Thanx/ Emile
-----------------------------------------------
Raj:
More seriously, does any one see a need for the following extension to
the SIGNED macro ?
A certificate signature needs to include the serial number of the
signers
public key certificate that can be used to verify it, and (/or) the
date
the signature was generated.
There is an enhanced version of the SIGNED and SIGNATURE macros defined
in the GULS standard (DIS 11586-1). These are parameterized types
(which are a macro replacement construct in the 93 ASN.1 standards)
called GULS SIGNED and GULS SIGNATURE. It is expected that these will
ultimately supercede the X.509 SIGNED and SIGNATURE.
The GULS SIGNED and SIGNATURE correct several deficiencies in the X.509
SIGNED and SIGNATURE. One is to include optional fields to convey CA
name and certificate serial number.
The GULS DIS is currently out for ballot; closing April 7 at ISO level
(earlier at ANSI level) if anyone wants to look into this more closely.
...Warwick Ford
-----------------------------------------------
...from GULS Part 1: (ISO/IEC 11586-1, also ITU-T Rec. X.830)...
(Forgive the formatting...I could also send a ps file if need be).
D.4 GULS SIGNED security transformation
The "GULS SIGNED" security transformation provides for digital signature or
sealing with appendix, with the transformed item including both the
unprotected data to be signed and the signature/seal appendix. It performs
a comparable function as the Directory SIGNED security transformation, but
has the following features:
-it can support any appendix-based signature or sealing technique, i.e., it
is not restricted to an enciphered-hash technique like Directory SIGNED;
-it removes the restriction of using Distinguished Encoding Rules only; any
single-valued encoding rules (including Canonical Encoding Rules) may be
used;
-it supports protected parameters to indicate initial encoding rules,
algorithm identifiers, algorithm parameters, and key information;
-it provides for identifying a digital signature algorithm and a hash
function by distinct algorithm identifiers;
-the encoding and decoding processes have been simplified.
Alternative protection mappings are defined in Annex E, enabling the
notation PROTECTED {BaseType, signed} to map to either the Directory SIGNED
or GULS SIGNED security transformation.
gulsSignedTransformation SECURITY-TRANSFORMATION
{KEY-INFORMATION: SupportedKIClasses} ::=
{
IDENTIFIER { securityTransformations guls-signed (4) }
INITIAL-ENCODING-RULES {joint-iso-ccitt asn1 (1) ber-derived (2)
canonical-encoding (0)}
-- This default for initial encoding rules may be overridden
-- using a static protected parameter.
XFORMED-DATA-TYPE SEQUENCE
{
intermediateValue IntermediateType
{ KEY-INFORMATION: SupportedKIClasses },
appendix BIT STRING (CONSTRAINED BY {
-- the appendix value must be generated
following
-- the procedure specified in D.4 of DIS
11586-1--})
}
}
IntermediateType { KEY-INFORMATION: SupportedKIClasses } ::= SEQUENCE
{
unprotectedItem ABSTRACT-SYNTAX.&Type
-- this type is constrained
to being
-- the type of the
unprotected item, or
-- BIT STRING if the
unprotected item is
-- not derived from an
ASN.1 abstract
-- syntax --,
initEncRules OBJECT IDENTIFIER DEFAULT
{joint-iso-ccitt asn1 (1)
ber-derived (2)
canonical-encoding (0)}
signOrSealAlgorithm AlgorithmIdentifier OPTIONAL,
-- Identifies the signing or
-- sealing algorithm, and
can convey
-- algorithm parameters --
hashAlgorithm AlgorithmIdentifier OPTIONAL,
-- Identifies a hash function,
-- for use if a hash
function is required
-- and the
signOrSealAlgorithm identifier
-- does not imply a
particular hash
-- function. Can also
convey algorithm
-- parameters.--
keyInformation SEQUENCE
{
kiClass
KEY-INFORMATION.&kiClass
({SupportedKIClasses})
keyInfo
KEY-INFORMATION.&KiType
({SupportedKIClasses)}
{(_at_)kiClass}
} OPTIONAL
-- Key information may
assume various
-- formats, governed by
supported members
-- of the KEY-INFORMATION
information
-- object class (defined at
start of the
-- definitive ASN.1 module)
}
D.4.1 Other details
Encoding process: The encoding process operates on a value of a
single ASN.1 type (the "unprotected item"), and it produces a "transformed
item" (a value of a SEQUENCE type as defined above). (If the unprotected
item is not derived from an ASN.1 abstract syntax specification, it may be
considered a value of an ASN.1 BIT STRING type.) First an "intermediate
value", of the ASN.1 type IntermediateType is generated. This is encoded
using the initial encoding rules, determined as specified in 7.1.4. The
resultant octets (the full tag-length-value encoding) are subjected to a
signing or sealing process, which may or may not employ a hash function.
This process generates an appendix value as a bit string. The transformed
item is then constructed.
Encoding process local inputs:Identifier of signing or sealing algorithm,
(optional) identifier of hashing algorithm, algorithm parameters,
signing/sealing key information.
Decoding process: The value of the unprotected item is extracted from
the transformed item and output. If the signature is to be verified, the
following process is also followed.
Signature verification requires an encoding of the intermediate value,
using the initial encoding rules. This can be obtained from the
transformed item, but may require decoding and re-encoding with the
required encoding rules. The signature or seal verification process is
performed.
Decoding process local inputs:Signature/seal verification key information.
Identifier of signing or sealing algorithm, identifier of hashing
algorithm, and/or algorithm parameters may also be needed if they were not
conveyed as protected parameters.
Decoding process outputs:Recovered unprotected item, as a value of an ASN.1
type. In addition, either or both of the following outputs may optionally
be produced:
(a) an indicator of whether or not the signature
has been verified correctly;
(b) a copy of the transformed item or of the
appendix value, for storing locally for possible subsequent signature
verification.
Parameters: Optional static protected parameters are: initial
encoding rules, identifier of signature/sealing algorithm, parameters of
signature/sealing algorithm, identifier of hashing algorithm, parameters of
hashing algorithm, key information.
Transformation qualifiers: None.
Errors: An error condition occurs if the
signature/seal verification fails.
Security Services: Data origin authentication, data integrity, and (in
certain situations) non-repudiation
D.4.2 Conformance
An implementation claiming conformance to this security exchange definition
shall satisfy the following conformance requirements:
-Statement Requirements: An implementor shall state whether the
implementation acts as an encoder, decoder, or both.
-Static Requirements: An implementation that acts as an encoder shall
be able to generate the transformed item. An implementation that acts as a
responder shall be able to process the transformed item.
-Dynamic Requirements: An implementation must implement the applicable
procedures described in this Annex.
D.5 GULS SIGNATURE security transformation
The "GULS SIGNATURE" security transformation provides for digital signature
or sealing with appendix, with the transformed item including the
signature/seal appendix but not the unprotected data to be signed. It
performs a comparable function as the Directory SIGNATURE security
transformation, but has the following features:
-it can support any appendix-based signature or sealing technique, i.e., it
is not restricted to an enciphered-hash technique like Directory SIGNATURE;
-it removes the restriction of using Distinguished Encoding Rules only; any
single-valued encoding rules (including Canonical Encoding Rules) may be
used;
-it supports protected parameters to indicate initial encoding rules,
algorithm identifiers, algorithm parameters, and key information;
-it provides for identifying a digital signature algorithm and a hash
function by distinct algorithm identifiers;
-the encoding and decoding processes have been simplified.
Alternative protection mappings are defined in Annex E, enabling the
notation PROTECTED {BaseType, signed} to map to either the Directory
SIGNATURE or GULS SIGNATURE security transformation.
gulsSignatureTransformation SECURITY-TRANSFORMATION
{KEY-INFORMATION: SupportedKIClasses} ::=
{
IDENTIFIER { securityTransformations guls-signature (5) }
INITIAL-ENCODING-RULES {joint-iso-ccitt asn1 (1) ber-derived (2)
canonical-encoding (0)}
-- This default for initial encoding rules may be overridden
-- using a static protected parameter.
XFORMED-DATA-TYPE SEQUENCE
{
initEncRules OBJECT IDENTIFIER DEFAULT
{joint-iso-ccitt asn1 (1)
ber-derived (2)
canonical-encoding (0)}
signOrSealAlgorithm AlgorithmIdentifier OPTIONAL,
-- Identifies the signing or
-- sealing algorithm, and
can convey
-- algorithm parameters --
hashAlgorithm AlgorithmIdentifier OPTIONAL,
-- Identifies a hash function,
-- for use if a hash
function is required
-- and the
signOrSealAlgorithm identifier
-- does not imply a
particular hash
-- function. Can also
convey algorithm
-- parameters.--
keyInformation SEQUENCE
{
kiClass
KEY-INFORMATION.&kiClass
({SupportedKIClasses})
keyInfo
KEY-INFORMATION.&KiType
({SupportedKIClasses)}
{(_at_)kiClass}
} OPTIONAL
-- Key information may
assume various
-- formats, governed by
supported members
-- of the KEY-INFORMATION
information
-- object class (defined at
start of the
-- definitive ASN.1 module)
appendix BIT STRING (CONSTRAINED BY {
-- the appendix value must be generated
following
-- the procedure specified in D.5 of DIS
11586-1--})
}
}
D.5.1 Other details
Encoding process: The encoding process operates on a value of a
single ASN.1 type (the "unprotected item"), and it produces a "transformed
item" (a value of a SEQUENCE type as defined above). (If the unprotected
item is not derived from an ASN.1 abstract syntax specification, it may be
considered a value of an ASN.1 BIT STRING type.) First an "intermediate
value", of the ASN.1 type IntermediateType defined in D.4 is generated.
This is encoded using the initial encoding rules, determined as specified
in 7.1.4. The resultant octets (the full tag-length-value encoding) are
subjected to a signing or sealing process, which may or may not employ a
hash function. This process generates an appendix value as a bit string.
The transformed item is then constructed.
Encoding process local inputs:Identifier of signing or sealing algorithm,
(optional) identifier of hashing algorithm, algorithm parameters,
signing/sealing key information.
Decoding process: If the signature is to be verified, the following
process is followed.
Signature verification requires an encoding of the intermediate value,
using the initial encoding rules. This requires the value of the
unprotected item, which is obtained as a local input. The protected
parameter values can be obtained from the transformed item, but may require
decoding and re-encoding with the required encoding rules. The signature
or seal verification process is performed.
Decoding process local inputs:Unprotected item, signature/seal verification
key information. Identifier of signing or sealing algorithm, identifier of
hashing algorithm, and/or algorithm parameters may also be needed if they
were not conveyed as protected parameters.
Decoding process outputs:Either or both of the following outputs may
optionally be produced:
(a) an indicator of whether or not the signature
has been verified correctly;
(b) a copy of the transformed item or of the
appendix value, for storing locally for possible subsequent signature
verification.
Parameters: Optional static protected parameters are: initial
encoding rules, identifier of signature/sealing algorithm, parameters of
signature/sealing algorithm, identifier of hashing algorithm, parameters of
hashing algorithm, key information.
Transformation qualifiers: None.
Errors: An error condition occurs if the
signature/seal verification fails.
Security Services: Data origin authentication, data integrity, and (in
certain situations) non-repudiation
D.5.2 Conformance
An implementation claiming conformance to this security exchange definition
shall satisfy the following conformance requirements:
-Statement Requirements: An implementor shall state whether the
implementation acts as an encoder, decoder, or both.
-Static Requirements: An implementation that acts as an encoder shall
be able to generate the transformed item. An implementation that acts as a
responder shall be able to process the transformed item.
-Dynamic Requirements: An implementation must implement the applicable
procedures described in this Annex.