Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft__misc/cy

Internet Message Format | 1997-07-30 | 22KB

Received: from gatekeeper.entrust.com by ietf.org id aa13147;
          29 Jul 97 13:20 EDT
Received: tid NAA07334; Tue, 29 Jul 1997 13:12:41 -0400
Received: by mail.entrust.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
    id <[e-mail]>; Tue, 29 Jul 1997 13:11:02 -0400
Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Another Submission...
Date: Tue, 29 Jul 1997 13:11:01 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC9C20.DD7DD8B0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BC9C20.DD7DD8B0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

>Hello,
>
>Attached is an internet draft entitled "draft-ietf-pkix-ipki6np-00.txt".
>
>Please do not hesitate to contact me if you need anything further or if you
>have trouble extracting the submission from this e-mail.





--------------------------------------------
Carlisle Adams
Entrust Technologies
[e-mail]
--------------------------------------------




------ =_NextPart_000_01BC9C20.DD7DD8B0
Content-Type: text/plain; name="Pkix6.txt"
Content-Transfer-Encoding: quoted-printable

PKIX Working Group                        C. Adams(Entrust Technologies)
Internet Draft                       R. Zuccherato(Entrust Technologies)
expires in six months                                      July 29, 1997



                     Internet Public Key Infrastructure
=20
                          Part VI: Notary Protocols=20

                      <draft-ietf-pkix-ipki6np-00.txt>


Status of this Memo

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.

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

Abstract

This document describes a general notary service and the protocols to
be used when communicating with it.  The Notary Authority is a Trusted=20
Third Party (TTP) that can be used as one component in building reliable =

non-repudiation services (see [ISONR]).  We also give an example of how=20
to use the notary to extend the lifetime of a signature beyond key=20
expiry or revocation.

1. Introduction

A Notary Authority (NA) is a Trusted Third Party that verifies=20
correctness of specific data submitted to it.  The Notary Authority=20
provides the notary service in order that non-repudiation evidence may=20
be constructed relating to the validity and correctness of an entity's=20
claim to possess data and/or the validity and correctness of various
types of data at a particular instant in time.  When notarizing=20
possession of data, the NA verifies the mathematical correctness of the=20
actual signature value contained in the request and also checks the full =

certification path from the signing entity to a trusted point (e.g., the =

NA's CA, or the root CA in a hierarchy) along with all relevant CRLs and =

ARLs (Authority Revocation Lists).  It then includes a trusted time and=20
creates a notary token.



Document Expiration:  Jan. 29, 1998                               Page 1

When notarizing data, the NA verifies the correctness of the data and=20
creates a notary token.  In this case, however, data "correctness" is=20
not as focused in scope as signature correctness; the particular
definition to be applied is therefore necessarily policy- and datatype-
dependent.  For example, the data may itself contain one or more=20
signatures (where "correctness" relates to the validity of these=20
signatures), or it may contain assertions (where "correctness" relates=20
to the truth value of these statements), or it may contain a contract=20
(where "correctness" relates to the legal validity of the document).

In all cases, the trust that PKI entities have in the Notary Authority=20
is transferred to the contents of the notary token (just as trust in a=20
CA is transferred to the certificates that it issues).  As a particular=20
example, a notary token pertaining to a signature may be useful for=20
extending the life of that signature beyond the expiry or subsequent=20
revocation of its corresponding verification certificate.

2. Requirements of the Notary Authority

The Notary Authority is required to:

     1. verify the correctness of the enclosed digital signature using=20
        all available and appropriate CRLs, ARLs, and public key=20
        certificates and produce a signed notary token attesting to the=20
        validity of the signature, if asked by the requester.
     2. verify the correctness of the enclosed data with respect to=20
        explicitly stated policies using all available and appropriate=20
        resources and produce a signed notary token attesting to the   =20
        validity of the data, if asked by the requester.
     3. include a monotonically incrementing value of the time of day=20
        or a time stamp token into its notary token.
     4. include within each signed notary token an identifier to=20
        uniquely determine the trust and validation policy used for its
        signature.
     5. indicate in the token whether or not the signature or data
        verified, and if not, the reason the verification failed.
     6. provide a signed receipt (i.e. in the form of an appropriately
        defined notary token) to the requester, where appropriate, as
        defined by policy.

3. Notary Transactions

As the first transaction of this mechanism, the requesting entity=20
requests a notarization by sending a request (which is or includes a=20
TimeStampReq, as defined below) including the data for which validity=20
and/or possession is to be notarized to the Notary Authority.  Upon=20
receiving the request, the Notary Authority reviews and checks the=20
validity of the request.  If the request is valid, the Notary Authority=20
performs the notarization and sends a response (which is or includes a=20
TimeStampToken, as defined below) to the requesting entity.  Otherwise,=20
the Notary Authority returns an error message (in the form of an=20
appropriately defined notary token).

Upon receiving the token, the requesting entity verifies its validity.
The requester should verify that it contains the correct time, the=20
correct name for the NA, the correct data imprint, a valid signature,=20

Document Expiration:  Jan. 29, 1998                               Page 2

and satisfactory status, service and policy fields.  The token can now=20
be used to authenticate the correctness or possession of the data.

4. Request and Token Formats

The ServiceType type indicates which type of Notary Service is required.

ServiceType ::=3D INTEGER  { npd(1), nd(2), nb(3) }

The value npd (Notarize Possession of Data) is used when only the=20
signature on the NotaryReq (i.e., possession of the data in the request) =

is to be verified.  In this case the Notary Authority would be merely=20
providing evidence that the requester possessed the data in the request=20
and a valid signature key at the time indicated.  This is really an=20
extension of the Time Stamp Authority in that we are given the=20
additional assurance about the validity of the signature, as well as the =

time before which it was applied.  The value nd (Notarize Data) is used=20
when only the data included in NotaryReqInfo is to be verified.  This=20
verification may mean verifying a digital signature contained in the=20
data, verifying the correctness of the data, or verifying the intent of=20
parties to a contract contained in the data, for example.  The exact=20
interpretation of this service must be clearly indicated in the NA=92s=20
policy statement, but is implementation and policy dependent, and thus=20
beyond the scope of this document.  The value nb (Notarize Both) is used =

when both the signature and data are to be verified.  A given NA may=20
support any subset of the above services.

A notary request is as follows.

NotaryReq ::=3D SEQUENCE  {
     notaryReqData                NotaryReqData,
     signature                    BIT STRING OPTIONAL
       --over the ASN.1 DER encoding of NotaryReqInfo, must be present
       --if the service field of NotaryReqInfo is npd or nb  =20
}

The data and information that will be notarized is contained in the=20
notaryReqData field.

NotaryReqData ::=3D SEQUENCE  {
     notaryReqInfo                NotaryReqInfo,
     data                         Data
       --the data to be notarized
       --this field must be of type Message if the service type is nd=20
       --or nb             =20
}

The notaryReqInfo field contains information pertaining to the notary=20
request.

NotaryReqInfo ::=3D SEQUENCE  {
     service                      ServiceType,
     requester                    GeneralName OPTIONAL,
      --must be present if the service field is npd or nb
    =20


Document Expiration:  Jan. 29, 1998                               Page 3

     signatureAlgorithm           AlgorithmIdentifier,
      --must be present if the service field of NotaryReqInfo is=20
      --npd or nb
     certs                        SEQUENCE OF Certificate OPTIONAL,
     reqPolicy                    PolicyInformation OPTIONAL,
     notary                       GeneralName,
     reqTime                      TimeStampToken OPTIONAL   }

In situations where the Notary Authority will verify the identity of the
requester (i.e., when the service field is npd or nb), the notary=20
request must be signed by the requester using the signature field.

Similarly, in situations where the Notary Authority will certify the=20
time included in the request (i.e., when stipulated by the policy of the =

Notary Authority), the notary request must include the reqTime field in=20
NotaryReqInfo. TimeStampToken is defined in Section 4 of PKIX Part 5=20
[PKIX5].

PolicyInformation is defined in Section 4.2.1.5 of PKIX Part 1 [PKIX1].
The reqPolicy field should indicate the policy under which the=20
notarization is requested.  This field must be checked by the NA to=20
verify agreement with its own policy.

The Data type is defined to be either the message itself or a hash of=20
the message.  This allows a signature indicating possession of private=20
data to be notarized.

Data ::=3D CHOICE  {
     message                     Message,
     messageimprint              MessageImprint  }

In order to specify the format (i.e. the type) of the message so that
it may be parsed and understood by the NA or any verifying entity, we=20
define the Message data type.

Message ::=3D SEQUENCE  {
     format                       MESSAGECLASS.&id,   --objid
     rawdata                      MESSAGECLASS.&Type  --open type =20
}

MESSAGECLASS ::=3D CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type                                                    }
WITH SYNTAX  { &Type IDENTIFIED BY &id }

If the requester prefers to send a hash of the message instead, the
MessageImprint data type should be used.

MessageImprint ::=3D SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

The hash algorithm indicated in the hashAlgorithm field should be a=20
=93strong=94 hash algorithm (that is, it should be one-way and collision =

resistant).  It is up to the Notary Authority to decide whether or not=20
the given hash algorithm is sufficiently =93strong=94.

Document Expiration:  Jan. 29, 1998                               Page 4

The hashedMessage field should contain the hash of the DER encoding of
the message expressed as a Message data type.  The hash is represented=20
as an OCTET STRING.

A notary token is as follows. =20

NotaryToken ::=3D SEQUENCE  {
     notaryInfo                   NotaryInfo,
     signature                    BIT STRING,
      --over the ASN.1 DER encoding of NotaryInfo =20
}

NotaryInfo ::=3D SEQUENCE  {
     notaryReqInfo                NotaryReqInfo,
       --must be the same value as the notaryReqInfo field in=20
       --NotaryReqData
     messageImprint               MessageImprint,
       --if the data field in NotaryReqData is MessageImprint, this
       --must contain that same value, otherwise it contains a hash of
       --the data field in NotaryReqData using the hash algorithm
       --specified in the signatureAlgorithm parameter=20
     signature                    BIT STRING OPTIONAL,
       --must be present if service field of notaryReqInfo is npd or nb
       --must be the same value as the signature field in NotaryReq
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     time                         NotaryTime,=20
     signatureAlgorithm           AlgorithmIdentifier, =20
     certId                       CertId,
       --must refer to the NA=92s public verification certificate
     certs                        SEQUENCE OF Certificate OPTIONAL,=20
       --if present, must indicate the chain of trust used to verify the =

       --signature=20
     crls                         SEQUENCE OF CertificateList OPTIONAL=20
   }

NotaryTime ::=3D CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               TimeStampToken   }

PKIStatusInfo is defined in Section 3.2.3 of PKIX Part 3 [PKIX3].  If
the PKIStatus field has value =91waiting=92 (3), then this token is a=20
receipt, as defined in Section 2.  Otherwise, the status field is=20
present to indicate whether or not the notary request was fulfilled and, =

if not, the reason it was rejected.  A valid NotaryToken will have a=20
PKIStatus field with value =91granted=92 (0).

CertId is defined in Section 3.2.4 of PKIX Part 3 [PKIX3].

The crls field (if present) should contain a sequence of certificate and
authority revocation lists that is sufficient to verify the chain of=20
trust indicated in the certs field.
=20
The signature, certs and crls fields are included as OPTIONAL.  They=20
should be present, when policy dictates, for use as supplementary=20
evidence when resolving possible disputes.  Dispute resolution would=20

Document Expiration:  Jan. 29, 1998                               Page 5

most likely be handled by one or more humans, in an off-line=20
environment, and is beyond the scope of this document.

6. Notary Protocol Using Email

This section specifies a means for conveying ASN.1-encoded messages=20
for the protocol exchanges described in Section 4 via Internet mail.=20

A simple MIME object is specified as follows.

   Content-Type: application/x-pkix6
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded PKIX-6 message, base64-encoded>>

This MIME object can be sent and received using MIME processing engines=20
and provides a simple Internet mail transport for PKIX-6 messages.

7. Security Considerations

When designing a notary service, the following considerations have been
identified that have an impact upon the validity or =93trust=94 in the=20
notary token.

     1. The requester=92s key is compromised and the corresponding=20
        certificate is revoked before the notary acts upon the request.=20
        The notary is required to validate appropriate information=20
        within the request before it constructs the notary token.  It is =

        therefore mandated that the NA have access to current
        information regarding certificate status.  In this situation,=20
        the notarization would not occur.

     2. The requester=92s key is compromised and the corresponding=20
        certificate is revoked after the notary acts upon the request.=20
        This is not a concern to the NA once the notary has constructed=20
        the token, as long as the compromise date in the CRL is not=20
        before the time of notarization.  If it is, this situation=20
        would have to be handled by off-line, possibly human-aided,=20
        means specific to the situation at hand.

3.  The notary=92s private key is compromised and the corresponding=20
        certificate is revoked.  In this case, any token signed by the=20
        notary cannot be trusted.  For this reason, it is imperative=20
        that the notary=92s key be guarded with proper security and=20
        controls in order to minimize the possibility of compromise. =20
        Nevertheless, in case the private key does become compromised,=20
        an audit trail of all the tokens generated by the NA should be=20
        kept as a means to help discriminate between genuine and false=20
        tokens. =20

     4. The NA signing key must be of a sufficient length to allow for=20
        a sufficiently long lifetime.  Even if this is done, the key=20
        will have a finite lifetime.  Thus, any token signed by the NA=20
        should be time stamped again at a later date to renew the trust=20
        that exists in the NA=92s signature.=20


Document Expiration:  Jan. 29, 1998                               Page 6

 8. References

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems. =20
Non-Repudiation Framework.

[PKIX1] R. Housley, W. Ford, W. Polk, D. Solo, =93Internet Public Key
Infrastructure, Part I:  X.509 Certificate and CRL Profile,=94 draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).

[PKIX3] C. Adams, S. Farrell, =93Internet Public Key Infrastructure, =
Part
III:  Certificate Management Protocols,=94 draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).

[PKIX5] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, =93Internet Public=20
Key Infrastructure, Part V:  Time Stamp Protocols,=94 draft-ietf-pkix-
ipki5tsp-00.txt, 1997 (work in progress).

9. Authors=92 Addresses

Carlisle Adams
Entrust Technologies
750 Heron Road, Suite 800
Ottawa, Ontario
K1V 1A7
CANADA
[e-mail]

Robert Zuccherato
Entrust Technologies
750 Heron Road, Suite 800
Ottawa, Ontario
K1V 1A7
CANADA
[e-mail]























Document Expiration:  Jan. 29, 1998                               Page 7

APPENDIX A - Storage of Data and Token

A notary token is useless without the data to which it applies.  For
this reason tokens and their related data must be securely stored=20
together.  The change of a single bit in either the data or the token=20
renders the entire notarization process for that data meaningless. =20
Storage of tokens and data in a secure (e.g., tamper proof) environment=20
is strongly recommended.

When data and notary tokens are stored together, the following ASN.1
data type may be used.

DataAndToken ::=3D SEQUENCE  {
     message                      Message,
     notaryToken                  NotaryToken  }

Note that this object does not need to be signed, as the notary token=20
already verifies the signature on the message.  Any supplementary=20
information whose integrity needs to be protected should be part of =20
the message or token.

APPENDIX B - Extending the Life of a Signature

We present an example of a possible use of this general notary service.=20
It produces a stand-alone token that can be used to extend the life of a =

signature.  This example assumes that we have total trust in the Notary=20
Authority.

Signature algorithms and keys have a definite lifetime.  Therefore,=20
signatures have a definite lifetime.  The Notary Authority can be used=20
to extend the lifetime of a signature.

In order to extend the lifetime of a signature in this way, the=20
following technique may be used.

A) The signature needs to be notarized.

     1) The signed message is presented to the Notary in the data=20
        field of NotaryReqInfo under service type nd and an appropriate
        policy.

     2) The Notary verifies that the signature and verification key are
        valid at that time by checking expiry dates, CRLs and ARLs, and=20
        returns a NotaryToken.

B)  The notarized signature must be verified.

     1) The signature of the Notary in NotaryToken shall be verified
        using the Notary=92s valid verification key.

In this situation the signer=92s signing key (and therefore, its=20
signature) is only valid until some specified time T1.  The NA=92s=20
signing key (and therefore, its signature) is valid until some specified
time T2 that is (usually) after time T1.  Without notarization, the=20
signer=92s signature would only be valid until time T1.  With=20
notarization, the signer=92s signature remains valid until time T2,

Document Expiration:  Jan. 29, 1998                               Page 8

regardless of subsequent revocation or expiry at time T1.

If the signature of the NA is valid, the trust we have in the NA allows=20
us to conclude that the original signature on the data was valid at=20
the time included in the notaryInfo field of the NotaryToken.  Notice=20
that in this example the validity of the original signature can be=20
confirmed from the verification of one signature (the NA=92s) instead of =

two signatures (the Time Stamp Authority=92s and the original), but at =
the=20
cost of putting more trust in the Trusted Third Party.
















































Document Expiration:  Jan. 29, 1998                               Page 9


------ =_NextPart_000_01BC9C20.DD7DD8B0--