Subject: PKCS 7 + PKCS 10 Proposal
From: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 31 Jul 1997 19:39:46 -0600

All--

Back in San Jose and again in Memphis the PKIX WG expressed interest in
considering the use of PKCS 7 and PKCS 10 for PKI administrative
messaging.  The draft below follows up on this topic from Memphis.

The question naturally emerges:  How does this relate to PKIX Part 3,
considering that PKIX Part 3 accepted changes at the last IETF which
accomodate PKCS 7 and PKCS 10?

Carlisle and I today discussed the issues surrounding this question, in
the context of the draft below.  We concluded it proposes a reasonable
approach towards leveraging the installed base of PKCS 7 capabilities. 
To that end, I propose we consider this framework in Munich and determine
if and how it should move forward.

The authors also feel that this work merits attention within the IPSEC
Working Group, hence it cross-posting to that list.

Carlisle had the following specific observations:

1.  The draft continues to promote the notion that one need only have a
single key.

2.  It provides no means to certify a D-H key.  Recognizing that the WG
has received a proposal to do so using PKCS 10 constructs, there still
remains a problem of coordinating parameters between the client and the
CA.

3.  It does not adequately address the subscriber bootstrapping 
problem.

4.  More generally, the current draft clearly falls short of addressing
the entire set of capabilities provided by Part 3.

For each of these there exists a reasonable counter position.  It's
tempting to rebut each, but in the interest of brevity I will address
only the last point, leaving the others to the list and Munich.

To the last point, I would observe that the draft is intended to address
only the most essential elements of a PKI service, with the thought in
mind that additional work would be needed to expand upon these basic
services.

Lastly, I apologize to the members of both lists for missing the deadline
and dumping this directly onto the lists.

(Carlisle, if I've misrepresented your position, I'm sure you'll have no
reservation whatsoever in correcting the public record!)

--Mike

Michael Myers

VeriSign, Inc.

[email-masked]

(415) 429-3402

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

PKIX Working Group                            Michael Myers (VeriSign)

Internet Draft                                  Alex Deacon (VeriSign)

                                                    Xiaoyi Liu (Cisco)

<bigger>

                   Internet Public Key Infrastructure

</bigger>

1. 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),
munari.oz.au Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

2. Abstract

Part 3 of the Internet Public Key Infrastructure (PKIX Part 3) series of
draft PKI standards defines an application-level protocol for use 
between PKI clients and PKI service providers.  While Part 3 amply
addresses a robust set of PKI requirements, a need exists to more fully
leverage existing implementa-tion investment in the PKCS7 security
protocol and PKCS10 certification request specification.  PKCS10 fails
however to address the full range of requirements addressed by PKIX Part
3.  This draft combines PKIX Part 3 concepts and PKCS10 in the context of
PKCS7 security encapsulation to propose an alternative Certificate
Management Protocol (CMP).

3. Protocol Overview

3.1 Transaction-Based Services

A CMP Transaction is composed of the exchange of two or more messages
between a CMP Server and a CMP Client.  This interaction is best
illustrated by the Certification Request transaction.  The most complex
variation involves certification requests arriving at a Server when the
Server is operated in a manner that requires manual authentication of the
certification request.

The following figure illustrates the interactions.  In this illustration,
the client produces a certification request and transmits it to a Server
config-ured for manual authentication.  The Server immediately returns a
response message that indicates the certification request is pending
manual authentication.  When a PENDING message is received for a
certificate request it sent, the client periodically polls for the
availability of the certificate.  During the interval while a Certificate
Request is pending manual authentication, an individual at the CA hosting
the server is involved in authenticating the identification information
contained in the request.  When the certificate is available, the Server
responds with a SUCCESS response message that contains the Client’s
certificate.

(The authors recognize that polling is sub-optimal for secure enclaves of
even modest scale.  Future revisions of this draft will address Client
state management logic that enables more efficient utilization of
bandwidth in large scale situations.)

              Client                           Server

                |                                 |

                |----- Certification Request ---->|

                |                                 |

                |<<------- PENDING Response -------|

                |                                 |

                |------------- Poll ------------->|

                |                                 |

                |<<------- PENDING Response -------|

                |                                 |

                |------------- Poll ------------->|

                |                                 |

                |<<------- PENDING Response -------|

                |                                 |

                |------------- Poll ------------->|

                |                                 |

                |<<------- SUCCESS Response -------|

All other CMP currently defined transactions complete with a single
request and response interchange.  These include an immediate SUCCESS
response when the Server is configured for automatic authentication, and
transactions to retrieve certificates and CRLs.  Section 8 of this draft
identifies areas where further work can be expected.

3.2 Transaction Synchronization

Each CMP transaction is identified and tracked using a transaction
identifier.  Clients generate transaction identifiers and retain their
state until the server responds with a message that closes the
transaction.  When the Server receives a message from a client, the
transaction identifier is also retained in the Server while the request
is being processed.  During the processing of the request, if it is
necessary that the client and server exchange messages regarding the
state of the transaction, the transaction identifier is included in these
intermediate messages.  When the Server completes processing of a
request, the transaction identifier is included in the response message
to the Client.  If a Client receives a message for which it has no
retained transac-tion identifier, the message is discarded.

3.3 Replay Prevention

The CMP incorporates a Sender and Recipient nonce for the purpose of
replay prevention.  Nonce values are random numbers.  The message that
initiates a transaction contains only a Sender nonce.

The recipient of an initial message retains the Sender nonce and uses it
as the value of Recipient nonce in the next message back to the
transaction originator.  The original recipient in turn generates its own
Sender nonce and includes this in the response message as the value for
Sender nonce.

Upon receipt of intermediate messages, the recipient compares the value
of the message’s Recipient nonce against a local store of Sender nonces
generated by the Recipient.  If a match is not found, the message is
rejected.  If a match is found, the recipient retains the value of Sender
nonce in the message for inclusion as Recipient nonce in any intermediate
messages back to the message originator.  The recipient also generates a
new value for its Sender nonce and includes it as the value of message
Sender nonce.

Continuing with the Certification Request transaction example above, the
following figure illustrates CMP nonce state management.  The column
labeled "Msg" corresponds to a message in the prior illustration.

The "Client Retains" and "Server Retains" columns are logically { (the
nonce I most recently sent you), (the nonce I most recently received from
you) }.  

The "Client Sends" and "Server Sends" columns correspond to the {sender
nonce, recipient nonce} values in the message.  Finally, the sequential
values in the table are for illustrative purposes only.

  Msg      Client     Client      Server      Server

           Retains    Sends       Sends       Retains

|-----------------------------------------------------|

|Request | {1,-}      {1,-}                           |

|-----------------------------------------------------|

|PENDING |                        {2,1}       {2,1}   |

|-----------------------------------------------------|

|Poll    | {3,2}      {3,2}                           |

|-----------------------------------------------------|

|PENDING |                        {4,3}       {4,3}   |

|-----------------------------------------------------|

|Poll    | {5,4}      {5,4}                           |

|-----------------------------------------------------|

|PENDING |                        {6,5}       {6,5}   |

|-----------------------------------------------------|

|Poll    | {7,6}      {7,6}                           |

|-----------------------------------------------------|

|SUCCESS |                        {8,7}       {8,7}   |

|-----------------------------------------------------|

3.4 Transport Model

This specification makes no assumptions about the underlying transport
mechanism.  The use of PKCS 7 specifically is not meant to imply an
email-based transport.  A prototype of this protocol currently in
operation demonstrates that HTTP is well suited to the CMP transaction
model.

3.5 Security Encapsulation

A CMP message is composed of a message body and one or more Service
Indica-tors. CMP Service Indicators are encoded as a set of authenticated
attributes of a PKCS7 SignedData construction. CMP message bodies are
first encrypted to become EnvelopedData and then included as the content
of SignedData. The message digest of the encrypted message body is then
signed together with the Service Indicators.

By separating the encryption and signing transformations, message
handling decisions based on the signed service indicators can be
determined prior to invoking security procedures specific to the message
body. 

The following figure illustrates the essential characteristics of a CMP
message. Many interior details and fields have been omitted for clarity. 
Not all of the indicated fields are present in every CMP message type.

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|    content                            |

|        Message Encryption Key (MEK)   | encrypted under Recipient’s
public

|        encrypted CMP message body     | encrypted under MEK

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           |

|        Hash of Content                |

|        message type                   | indicates msg body syntax

|        transaction identifier         |

|        transaction status             |

|        sender nonce                   |

|        recipient nonce                |

|---------------------------------------|

|    Message Signature                  |produced using originator’s
private

|---------------------------------------|operating on hash of AUTH.
ATTR.

3.6 Message Body

A CMP message encapsulated by PKCS7 syntax is constructed as follows. 

The contentInfo field of a signedData type is populated with the
envelopedData content type. The encryptedContent of this envelopedData
may contain one of the following CMP message bodies:

- PKCSReq              -- Request for a certificate

- CertRep              -- Response to a certificate request

- GetCertInitial       -- A means to poll for a pending certification

- GetCert              -- A means to query for others’ certificates

- GetCRL               -- A means to query for a CA’s CRL(s)

A PKCSReq message consists of a PKCS10 certificate signing request. It is
sent from the client to the CA.  As currently specified, the request
shall contain the subject name, the subject public key and a
ChallengePassword attribute.  It may contain an optional ExtensionReq
attribute used to indicate to the CA one or more certificate extensions. 
Additional extensions to PKCS10 content should be anticipated as this
draft standard evolves.

A CertRep message is the CA’s response to a PKCSReq, GetCertInitial or
GetCert GetCRL.  It may contain a certificate but always contains one or
more Service Indicators.

A GetCertInitial message is used to poll a CA for a requested certificate
in the circumstance when the PKIStatus of prior CertRep message indicates
PENDING.

Clients may use a GetCert or GetCRL message to access a CA’s repository
of certificates or CRL(s) respectively.

3.7 Service Indicators

Service indicators are included with a message body to form a complete
CMP message.  The SignerInfos portion of the signedData content type
conveys additional information needed to complete the protocol.  The
authenticatedAt-tributes element of the SignerInfos syntax is used to
identify an enveloped-Data content type carrying one of the following CMP
service indicators:

- transactionId

- messageType

- pkiStatus

- failinfo

- senderNonce

- recipientNonce

Each service element is uniquely identified by an OID that signals the
syntax following the OID.  CMP processing systems would first detect the
service element OID and process the corresponding service indicator value
prior to processing the message body.

The transactionId service indicator identifies a given transaction.  It
is used between client and server to manage the state of an operation.

The messageType service indicator identifies the syntax carried in the
message body.

The PKIStatus service indicator is used to convey information relevant to
a requested operation.

The failInfo service indicator conveys information relevant to the
interpreta-tion of a failure condition.

The senderNonce and recipientNonce service indicator can be used to
provide application-level replay prevention.

4. Protocol Elements

4.1 PKCS7 Encapsulation

The following syntax specifies the general content of CMP messages. 
Required values for certain fields are specified as comments to selected
protocol elements.  For the purposes of interoperability, CMP-compliant
applications shall implement these required values for the indicated
protocol elements.  Applications may also implement additional values for
these fields to accommodate other operational environments.

PKIMessage ContentInfo ::= SEQUENCE {

  contentType OBJECT IDENTIFIER               -- {pkcs-7 2}, SignedData

  content [0] }                               -- data to be signed

The data to be signed into a PKCS7 encapsulated CMP message shall be
struc-tured as follows.

With the exception of the response to a GetCRL request message, the
optional CRL component of a signedData content type shall not be included
in a CMP message.

SignedData ::= SEQUENCE {

  version INTEGER,

  digestAlgorithms AlgorithmIdentifier,

  contentInfo SEQUENCE {

    contentType OBJECT IDENTIFIER             -- {pkcs-7 3},
EnvelopedData

    content [0] } OPTIONAL                    -- encrypted message body

  certificate  [0] Certificate,               -- signer’s certified
public key

  signerInfos SignerInfos }                   -- contains Service
Indicators

The SignerInfos portion of SignedData carries one or more CMP Service
Indicators. SignerInfo shall be composed as follows:

SignerInfo ::=            SEQUENCE {

  version INTEGER,

  issuerAndSerialNumber     SEQUENCE {

    issuer                    Name, 

    serialNumber              INTEGER }

  digestAlgorithm           AlgorithmIdentifier,

  authenticatedAttributes   SET OF Attributes,

  digestEncryptionAlgorithm AlgorithmIdentifier,

  encryptedDigest           OCTET STRING }

The value of authenticatedAttributes is hashed using the algorithm
specified by digestAlgorithm, signed using the originator’s private key
corresponding to digestEncryptionAlgorithm, the result encoded as an
OCTET STRING and assigned to the encryptedDigest field.

Since PKCS 7 requires the presence of a digest of the message content in
AuthenticatedAttributes, message content is indirectly bound to the
signature through the digest of AuthenticatedAttributes.

Specification of the syntax and semantics of the CMP service indicators
that can be included as AuthenticatedAttributes are presented in section
4.3.

Some CMP messages do not carry a contentInfo block in SignedData.  These
messages are composed as SignedData consisting of version,
digestAlgorithm, certificate(s) and SignerInfo.  When a CMP message
conveys additional content, this content is conveyed as an EnvelopedData
content type within the Con-tentInfo block of SignedData and is
structured as follows.

EnvelopedData ::=         SEQUENCE {

  version INTEGER,

  recipientInfos            SET OF SEQUENCE {

    version                   INTEGER,

    issuerAndSerialNumber     SEQUENCE {

      issuer                    Name, 

      serialNumber              INTEGER }

    keyEncryptionAlgorithm    AlgorithmIdentifier,

    encryptedKey              OCTET STRING }

  encryptedContentInfo        SEQUENCE {

    contentType                 ContentType,

    contentEncryptionAlgorithm  AlgorithmIdentifier,

    encryptedContent            [0] IMPLICIT OCTET STRING }

4.2 Object Identifier Base

The OIDs for CMP objects stem from the PKIX arc.  PKIX Part 1 establishes
the following value as the base of the PKIX object identifier space:

pkix  OBJECT IDENTIFIER ::= { 1 3 6 1 5 5 7 }

Objects associated with PKIX Certificate Management Protocol are
established under the following identifer space:

pkix-cmp OBJECT IDENTIFIER ::= { pkix X }    --Get with Tim Polk on 
this

4.3 Use of Authenticated Attributes

CMP Service Indicators are encoded as AuthenticatedAttributes within
Signed-Data. In accordance with PKCS7, when included in a PKCS7 message,
Authenticat-edAttributes must consist of at a minimum:

- A PKCS #9 content-type attribute having as its value the content type
of the ContentInfo value being signed.

- A PKCS #9 message-digest attribute, having as its value the message
digest of the content.

For the first, CMP chooses to use the PKCS9 attribute OID ContentInfo to
signal additional content interpretation information.  This is the first
in the SET OF Attributes defining CMP’s AuthenticatedAttributes. 
Following the ContentInfo OID, CMP includes the mandatory message digest
attribute.  In addition to this required syntax, CMP currently defines
six authenticated attributes:

Service Indicator      OID              Syntax

-----------------      -------------    ---------------

TransactionId          pkix-cmp 1       PrintableString

messageType            pkix-cmp 2       PrintableString

pkiStatus              pkix-cmp 3       PrintableString

failinfo               pkix-cmp 4       PrintableString

senderNonce            pkix-cmp 5       OCTET STRING

recipientNonce         pkix-cmp 6       OCTET STRING

The TransactionID, messageType, pkiStatus and failInfo service indicators
are decimal values expressed as a string.

The TransactionID Service Indicator uniquely identifies a transaction; it
is used to match responses to requests. To be effective, its value must
be unique within any reasonably chosen context. In the certificate
enrollment transac-tion, this requirement may be met by producing a
Certification Request transactionID using a hash on the end entity public
key value.  CMP Servers SHALL NOT rely upon NOR enforce this behavior.

This attribute is required in all PKI messages.

The messageType service indicator specifies the type of operation
performed by the  transaction. This attribute is required in all PKI
message. The following message types defined:

PKCSReq           (19)  -- Permits use of PKCS#10 certificate request

CertRep           (3)   -- Response to certificate request 

GetCertInitial    (20)  -- Certificate polling in manual enrollment

GetCert           (21)  -- Retrieve a certificate

GetCRL            (22)  -- Retrieve a CRL

All response messages will include transaction status information which
is defined as pkiStatus service indicator:

SUCCESS           (0)   -- request successful

FAILURE           (2)   -- request rejected

PENDING           (3)   -- request pending

This PKIStatus service indicator is required for all PKI messages.

If the status in the response is FAILURE, then the failinfo service
indicator will contain one of the following failure reasons:

BADALG            (0)  -- Unrecognized or unsupported algorithm ident

BADMESSAGECHECK   (1)  -- integrity check failed

BADREQUEST        (2)  -- transaction not permitted or supported

BADTIME           (3)  -- Message time field was not sufficiently close

                             -- to the system time

BADCERTID         (4)  -- No certificate could be identified matching
the

                             -- provided criteria

The attributes of senderNonce and recipientNonce are random numbers
generated per transaction to prevent replay attack.  This attribute is
required for all PKI messages.

In the first message of a transaction, no recipientNonce is transmitted;
a senderNonce is instantiated by the message originator and retained for
later reference.  The recipient of a senderNonce reflects this value back
to the originator as a recipientNonce and includes it’s own senderNonce. 
Upon reciept by the transaction originator of this message, the
originator compares the value of recipientNonce to its retained value. 
If the values match, the message can be accepted for further security
processing.  The received value for senderNonce is also retained for
inclusion in the next message associated with the same transaction.

4.4 Messages

4.4.1 PKCSReq Message Format

Clients shall produce a PKCS10 message body containing an unambiguous
identity and public key. The exact structure of this identity and the
means by which it is determined is a matter of operational policy.

PKCSReq CertificationRequest ::= SEQUENCE {

  certificationRequestInfo         SEQUENCE {

    version                          INTEGER,

    subject                          Name,

    subjectPublicKeyInfo             SEQUENCE {

      algorithm                        AlgorithmIdentifier,

      subjectPublicKey                 BIT STRING }

    attributes                     [0] IMPLICIT SET OF Attribute }

  signatureAlgorithm               AlgorithmIdentifier, 

  signature                        BIT STRING }

The client may incorporate one or more standard X.509 v3 extensions in
the request as PKCS 9 attributes. This information shall be expressed in
the Attributes field of a PKCSReq as a iteration of individual objects of
the form EXTENSION as defined in X.509.

CMP-compliant CAs are not required to be able to process every v3 X.509
extension transmitted, nor are they required to be able to process other,
private extensions.  However, in the circumstance when a CA denies the
certification request due to the inability to handle a requested
extension, the CA shall respond with a error that unambiguously
identifies the error condition.

Service Indicator		OID		                  Value

-----------------       --------------------------    -----------------

contentType              pkcs-9 3

messageDigest		    pkcs-9 4                      

transaction-id           pkix-cmp 1

messageType		    pkix-cmp 2                    PKCSREQ

senderNonce              pkix-cmp 5

4.4.2 CertRep

Clients receive CertRep messages in response to a prior PKCSReq message. 
The response may be one of:

--PENDING

--SUCCESS

--FAILURE

The general structure of a CertRep message is as follows.  An "inner"
SignedData content type is encrypted and then encapsulated as
EnvelopedData.  This encapsulation becomes the contentInfo of an "outer"
SignedData content type which is signed by the message originator.  This
final encapsulation is then passed on to the intended message 
recipient.

The figure below schematically illustrates the essential data structure
relationships.  Specific content will vary by context.  Some fields
omitted for clarity.

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|    ENVELOPED DATA                     |

|        MEK                            | - encrypted under Client’s
public

|        encrypted content:             | - encrypted under MEK

|            SIGNED DATA                | - content varies

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           |

|        Hash of Content                |

|        message type                   | 

|        transaction identifier         |

|        transaction status             |

|        failure info                   |

|        sender nonce                   |

|        recipient nonce                |

|---------------------------------------|

|    MESSAGE SIGNATURE                  | - produced using CA’s private
key

|                                       |     operating on hash of AUTH.
ATTR.

|---------------------------------------|

4.4.2.1 PENDING

When the CA decides to manually authenticate the end entity, the CA
returns CertRep with pkiStatus set to PENDING and proceeds to perform the
required authentication.

The PENDING CertRep message is a SignedData content type with no
ContentInfo block.  The SignerInfo block contains the following
Authenticated Attributes as indicated:

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           |

|        Hash of Content                |

|        message type                   | - CERTREP

|        transaction identifier         | - from prior request

|        transaction status             | - PENDING

|        sender nonce                   | - prior client nonce

|        recipient nonce                | - current server nonce

|---------------------------------------|

|    Message Signature                  | - produced using CA’s private
key

|                                       |     operating on hash of AUTH.
ATTR.

|---------------------------------------|

4.4.2.2 FAILURE

CAs transmit a CertRep messages with a PKIStatus of FAILURE if the
certifica-tion request or its subsequent processing fails to meet the
requirements of the CA’s practices.

The message is a SignedData content type with no ContentInfo block.  The
SignerInfo block contains the following Authenticated Attributes as
indicated:

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           |

|        Hash of Content                |

|        message type                   | - CERTREP

|        transaction identifier         | - from prior request

|        transaction status             | - FAILURE

|        failInfo                       | - reason code

|        sender nonce                   | - prior client nonce

|        recipient nonce                | - current server nonce

|---------------------------------------|

|    Message Signature                  | - produced using CA’s private
key

|                                       |     operating on hash of AUTH.
ATTR.

|---------------------------------------|

Failure reason codes are specified in Section 4.2.

4.4.2.3 SUCCESS response 

When used to deliver a certificate, the Client’s certificate shall be
conveyed to the Client in the SignerInfo portion of a degenerate
SignedData content type.  This is encapsulated by an EnvelopedData
content type which is in turn encapsulated by an outer SignedData.  The
outer SignedData is signed by the originator of the CertRep message.

Schematically, the relationship among these elements is as follows (some
interior details omitted for clarity):

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|    ENVELOPED DATA                     |

|        MEK                            | - encrypted under Client’s
public

|        encrypted content:             | - encrypted under MEK

|        SIGNED DATA                    | - degenerate, no content

|             Client’s certificate      | - includes client cert in
SignerInfo

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           |

|        Hash of Content                |

|        message type                   | - CERTREP

|        transaction identifier         | - from prior request

|        transaction status             | - SUCCESS

|        sender nonce                   | - prior client nonce

|        recipient nonce                | - current server nonce

|---------------------------------------|

|    Message Signature                  | - produced using CA’s private
key

|                                       |     operating on hash of AUTH.
ATTR.

|---------------------------------------|

4.4.3 GetCertInitial

The GetCertInitial message is used to poll for the certificate associated
with prior request if the response to that prior request was a CertRep
message with a status of PENDING.

Certificates are normally referenced using the CA DN and the certificate
serial number.  In this case however a certificate has not yet been
issued.  Thus the CA and Subject DNs are present in the message as a
means to identify the requested certification.

The following syntax shall be included as the message body:

IssuerAndSubject ::= SEQUENCE {

   issuer Name,

   subject Name }

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|    ENVELOPED DATA                     |

|        MEK                            | - encrypted under CA’s public

|        encrypted content:             | - encrypted under MEK

|            SIGNED DATA                | - degenerate, no content

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           |

|        Hash of Content                |

|        message type                   | - GETCERTINITIAL

|        transaction identifier         | - from previous request

|        sender nonce                   | - new

|        recipient nonce                | - current server nonce

|---------------------------------------|

|    Message Signature                  | - produced using Client’s pvt
key

|                                       |     operating on hash of AUTH.
ATTR.

|---------------------------------------|

4.4.4 GetCRL

This operation is used to retrieve CRLs from a CA’s repository.  It
comple-ments PKIX Part 2 in that this function as specified is an
integral component of CMP and thus forms a standalone solution to
essential Certificate Management services.

It assumes the target CA maintains one and only one CRL relative to a
given private signing key.  In order to provide Client a convenient means
of determining the network address needed to acquire a CA’s CRL,
PKIX-compliant CMP Servers and Clients should be capable of producing and
processing, respectively, the CRLDistributionPoints certificate
extension.  The CRLDistributionPoint shall contain a URL that Clients
reference when directing a query for the CRL of a given certificate’s
Issuer.  Alternatively, the Client may be pre-configured with the CMP
Server’s URL.

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|    DATA                               |

|        GetCRL message body            |

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           | - See Appendix A for OIDs.

|        Hash of Content                | - binds requestor to request

|        message type                   | - GETCRL

|        transaction identifier         | - new transaction

|        sender nonce                   | - new sender nonce

|---------------------------------------|

|    Message Signature                  | - produced using Client’s pvt
key

|                                       |   operating on hash of AUTH.
ATTR.

|---------------------------------------|

The GetCRL message body shall consist of the following syntax:

GetCRL ::= SEQUENCE {

    issuerName	Name,

    time          GeneralizedTime }

4.4.5 GetCert

When CMP Clients have no external configuration function to provide them
the network address of a CA’s Repository, CMP Clients may attempt the
value for CRLDistributionPoints as the value for a CA’s Repository
generally.  CMP Servers should be configured to provide this 
capability.

|---------------------------------------|

|SIGNED DATA                            |

|---------------------------------------|

|    DATA                               |

|        GetCert message body           |

|---------------------------------------|

|    ORIGINATOR’S CERTIFICATE           |

|---------------------------------------|

|    AUTHENTICATED ATTRIBUTES           | - See Appendix A for OIDs.

|        Hash of Content                | - binds requestor to request

|        message type                   | - GETCRL

|        transaction identifier         | - new transaction

|        sender nonce                   | - new sender nonce

|---------------------------------------|

|    Message Signature                  | - produced using Client’s pvt
key

|                                       |   operating on hash of AUTH.
ATTR.

|---------------------------------------|

The GetCert message body shall consist of the following syntax:

GetCert ::= SEQUENCE {

    issuerName	Name,

    serialNumber  INTEGER }

5. PKI Transactions

5.1 Client Requests Certification of a Public Key

To obtain a certificate, a client creates a PKCS10 certificate signing
request (CSR) and signs it using the private key corresponding to the
public contained in the CSR.  A content-encryption key is generated and
the CSR encrypted under this key.  The result is placed into the
EncryptedContent portion of En-velopedData.  The content encryption key
is in turn encrypted under the public key of the recipient CA and
included in the recipientInfo of envelopedData.

The client next generates a transactionID and a 16-byte random number for
senderNonce.  The transactionID should be unique to guard against
transaction replay.  A good source of uniqueness is a hash of the public
key contained in the CSR.  Recipient CAs should make no assumptions about
this structure of transactionId.

PKCS7 requires that the signerInfo contain a issuerNameSerialNumber
value; however for this transaction, the certificate has yet to be issued
and therefore the serialNumber has not yet been assigned.  Thus the
issuerName and SerialNumber value in the signerInfo are set to NULL and
zero, respectively. 

Upon receipt of this message, the CA must first determine that the
signature validates using the supplied public key, thereby proving
possession of the private key.  This check also provides integrity
assurance.  Given the nature of this particular message however, this
check does not provide authentica-tion.

Alternatively, for those who do not have the ability to alter the DER
encoding of the PKCS7 message, (i.e. those using the toolkits such as
TIPEM) the end entity may generate a self-signed certificate and use it
to build the envelope PKCSReq message. In this self-signed certificate
the subject DN and issuer DN should both be the DN which has been
specified in the PKCS10 request. The serialNumber of this self-signed
certificate should be zero.

The client then constructs a SignedData object using the self-signed
certifi-cate, with the transactionId, senderNonce and message digest as
authenticated attributes.  The attributes should be signed using the end
entity’s private key, completing the SignedData.

If the operational relationship between the client and the CA requires
manual identity confirmation, an operator must verify the end entity’s
request information in some out-of-band method before the request can be
granted. Examples of this out-of band method may include calling someone
on the phone to compare the hash values or via a pre-authenticated list
of entities. In this manual case, the end entity will receive a CertRep
message with status set to PENDING. If the end entity is not entitled to
the key usage it requested (via ExtensionReq), the request should be
rejected as part of the identity confirmation process.

5.1.1 Exception handling

Errors can occur during the enrollment phase that cause requests to be
placed in a partially fulfilled state from either the end entities or
CA’s perspec-tive. In such cases, the transactions must be
"re-synchronized" according to the following rules:

5.1.1.1 End entity does not receive a response

If a response to a PKCSReq is not received, the end entity should send
GetCertInitial request to the server with the same transactionID as the

original PKCSReq until a valid response is received or the number of
retries has been exceeded. In the latter case, the transaction is marked
as failed, and a new PKCSReq message will be sent to the CA with the same
transaction ID as the previous (failed) PKCSReq. When the CA receives the
new request, it will recognize that the new transaction has a pending
equivalent and will "cancel" the previous transaction.

5.1.1.2 User cannot open enveloped message:

Because the response is encrypted with the user’s public key, this error
would only occur if the message or private key is corrupt. This should be
treated as a protocol error and the user should request that the
certificate be revoked through the manual revocation process.

5.1.1.3 User cannot verify CA signature:

It may be issued from the CA’s perspective, but was never successfully
delivered to the user. The user should request that the certificate be

revoked through the manual revocation process.

5.1.1.4 Other abnormal errors

These are protocol errors where the user does not receive a response from
the CA to complete the transaction. In general, the user should retry
until it exceeds the retry limit, then "re-synchronize" by starting a new
transaction with the same transactionID. When the CA sees this duplicate
transaction, it should re-synchronize by canceling all equivalent pending
transactions. A transaction is considered to be "equivalent" if it is the
same message type from the same entity, and has the same transaction 
ID.

5.2 End entity polls for its initial certificate

If the status in the CertRep is PENDING, the end entity creates and
transmits a GetCertInitial message.  The encryptedContentInfo of this
message contains the IssuerAndSubject data structure that refers to the
end entity. The end entity repeats this request until the CertRep it
receives has a status of SUCCESS or FAILURE.

If the CA receives multiple GetCertInitial request from an end entity
with the same transactionID it will simple process the request as
normal.

5.3 Revocation 

To revoke a certificate, the client communicates to the operator of the
CA Management System. That is, a user will communicate the revocation to
the CA operator, who will ask for the challenge phrase included in the
original certification request to confirm the identity of the user. 
Additional confirmation steps may be necessary to ensure that the
revocation request is genuine and is the clear intent of the client to
whom the certificate was issued.

6.  Security Considerations

7.  Author’s Addresses

Michael Myers

VeriSign, Inc.

Xiaoyi Liu

Cisco Systems

Date: Wed, 30 Jul 1997 15:56:58 -0400
From: Dwight Arthur <[email-masked]>
To: Peter Williams <[email-masked]>
CC: "G. Mack Hicks, VP Bank of America" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: CRL Push over S/Mime

Peter, if I understand correctly what you have
described, I would agree that a CRL pull from
a _LOCAL_ repository which has been receiving
signed sessionless crl pushes, is the
functional equivalent of what I asked for
when I argue for "push".

However, next question is this: in order to cap
the ca's liability due to revocation latency, the
pushing ca would need to receive a receipt for
the pushed crl. Is there anything about the
current proposal that would particularly enable
or defeat this requirement? -Dwight

From: Ingmar Camphausen <[email-masked]>
Date: Thu, 31 Jul 97 15:20:08 +0200
To: [email-masked] (Olivier Onimus)
Subject: Re: X.509-Certificate-Decoder
Cc: [email-masked]
Reply-To: [email-masked]
Priority: normal

on Thu, 31 Jul 1997, [email-masked] (Olivier Onimus) wrote:

> Does somebody know where I can find some

> X.509-Certificate-Decode-Programs to check | X.509-CRL-Decode-Programs to check

> that our Certificate-Encoding-Software

> is OK ?

Olivier,

you might want to try the "dumpasn1" utility from Peter Gutmann (his original announcement is attached below). It can be found at

http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c

Furthermore, you could get the beta version of the security software

toolkit "SECUDE" from the German Research Center for Information

Technology (GMD), Darmstadt, via http://www.darmstadt.gmd.de/secude/51b/

(Sorry, no source code, but binaries for the most common platforms are

available.) It comprises -- among others -- the utilities 'asn1show' and 'asn1dump' which could be useful for you.

Then, you could have a look at SSLeay (recent version is 0.81). The "master location" of SSLeay is ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL. In the SSLeay FAQ on http://psych.psy.uq.oz.au/~ftp/Crypto/ you can find a list of ftp mirrors. 

SSLeay offers two commands 'crl' and 'x509' that might be suitable for your purposes.

Hope this helps,

	Ingmar Camphausen

__________________________________________________________________

Internet : [email-masked]

Phone    : ++49 / (0)30 / 25 499 - 357

Fax      : ++49 / (0)30 / 25 499 - 202

Address  : Research Institute for Open Communication Systems

           GMD FOKUS, Hardenbergplatz 2, D-10623 Berlin, Germany

> From: [email-masked] (Peter Gutmann)

> To: [email-masked], [email-masked], [email-masked]

> Subject: ASN.1 dump/diagnostic utility updated

> Reply-To: [email-masked]

> Date: Tue, 3 Jun 1997 11:22:48 (NZST)

> 

> [I've had quite a few requests for this so I'm sending this annoucement to the 

>  three most appropriate lists, apologies if you see it more than once]

>  

> I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit 

> better, which means you can now display things like PKCS #7 objects and (in 

> general) anything else which mixes BER and DER-encoded data.  The program is 

> aware of most of the common crypto-related object identifiers and types, so 

> it'll give you a proper description of what it is you're looking at.  Here's 

> some sample output from the start of a cert:

>  

>    0 30  618: SEQUENCE 

>    4 30  467:   SEQUENCE 

>    8  2    4:     INTEGER 830525701

>   14 30   13:     SEQUENCE 

>   16  6    9:       OBJECT IDENTIFIER

>             :         md5withRSAEncryption (1 2 840 113549 1 1 4)

>   27  5    0:       NULL

>             :       

>   29 30  125:     SEQUENCE 

>   31 31   11:       SET 

>   33 30    9:         SEQUENCE 

>   35  6    3:           OBJECT IDENTIFIER countryName (2 5 4 6)

>   40 13    2:           PrintableString 'Ca'

>             :           

>             :         

>   [etc]

>  

> Hopefully the program will prove useful for picking apart certs and data 

> objects for debugging and diagnostic purposes, especially now that it handles 

> BER data properly.  You can get it from 

> http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.

>  

> Peter.

> 

From: Stefan Kelm <[email-masked]>
Date: Thu, 31 Jul 1997 12:01:53 +0200 (MET DST)
To: [email-masked]
Subject: Re: Reflections on the PKIX Part 1 Draft
Reply-To: [email-masked]

Alan,

> The following is a paper that several of us have drafted to make some
> suggestions,
> mainly in regard to PKIX Part 1.
>
> Comments are welcome.  Some time discussing some or all of these thoughts
> at
> the upcoming meeting may be fruitful, and some of the authors hope to be
> present
> there.

just a short comment concerning the German digital signature legislation
you mention below.

[...]

> Support for Data Protection Legislation
>
>      Data protection legislation protects individuals' privacy in
> many legal systems.[n^^12]  Such legislation restricts the widespread
> use of personally identifying data records such as certificates.
> One approach, taken in the German digital signature
> legislation,[n^^13] is to leave out information in the certificate
> identifying the subject and to include instead an identifying
> number meaningful to the issuer or the subjectInfoAccess point.[n^^14]
> The issuer or subjectInfoAccess provider can then arbitrate
> requests for further information according to the subject's
> privacy rights.

[...]

> 13.  See Informations- und Kommunikationsdienste-Gesetz (IuKDG), art.
> 3, s 4(1) (1997) ("Der Diensteanbieter hat dem Nutzer die
> Inanspruchnahme von Telediensten und ihre Bezahlung anonym oder
> unter Pseudonym zu erm?glichen, soweit dies technisch m?glich und
> zumutbar ist. Der Nutzer ist ?ber diese M?glichkeiten zu
> informieren.").

This is a misquotation. The paragraph you quote is the same as note
No. 12. but it is not an excerpt from the Digital Signature Law. There
is, however, a paragraph on using pseudonyms in certificates which I'm
sure you're referring to.

Here are the complying paragraphs from the Signature Law
(http://www.iid.de/rahmen/iukdgebt.html):

        § 5: Issue of Certificates

        [...]

        (3) At an applicant's request the certification authority shall indicate a pseudonym
        instead of the applicant's name in the certificate.

        § 12: Data Protection

        [...]

        (2) Where the owner of a signature key uses a pseudonym, the certification authority
        shall be obliged to communicate, upon request, to the competent bodies any data
        pertaining to his identity which is required for the prosecution of criminal or
        administrative offences, for averting danger to public safety or order or for the
        discharge of statutory duties by the Federal and State authorities for the protection of
        the Constitution, the Federal Intelligence Service [Bundesnachrichtendienst], the
        Military Counter-Intelligence Service [Militärischer Abschirmdienst] or the Customs
        Criminological Office [Zollkriminalamt]. Such disclosures shall be documented. The
        requesting authority shall inform the owner of the signature key about disclosure of the
        pseudonym as soon as this no longer interferes with the discharge of its statutory duties
        or if there is an overriding interest of the owner of the signature key in being given such
        information.

Hope this helps!

Regards,

        Stefan.

______________________________________________________________________________
Stefan Kelm                                                  <[email-masked]>
DFN-PCA, University of Hamburg                    http://www.pca.dfn.de/~kelm/
Vogt-Koelln-Str. 30             "finger [email-masked]" to get my PGP key
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

Date: Thu, 31 Jul 1997 10:17:13 +0200
To: [email-masked]
From: [email-masked] (Olivier Onimus)
Subject: X.509-Certificate-Decoder

Hi !

Does somebody know where I can find some
X.509-Certificate-Decode-Programs to check
that our Certificate-Encoding-Software
is OK ?

Does somebody know where I can find some
X.509-CRL-Decode-Programs to check
that our CRL-Encoding-Software
is OK ?

Does somebody know where I can find some examples of
BER-encoded X.509-Certificates and CRLs (without
private extensions),
to check that our Certificate/CRL-Decoding-Software
is OK ?

Thanks in advance for your response !

Olivier
                        
Olivier Onimus
Danet GmbH, Business Unit Telecommunications Technology
P.O.Box 10 04 03, D-64204 Darmstadt
Tel:    +49-6151-868-127  
Fax:    +49-6151-868-264
X.400:  CÞ;AÔ00;PÚnet;OÚnet-GmbH;S=Onimus
e-mail: [email-masked]

Date: Wed, 30 Jul 1997 16:26:01 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: PKIX-1 new draft/Last Call?

I have submitted a new draft of PKIX Part 1.  I will attempt to summarize
the changes in the document.

1. It's bigger.  (Are you sitting down?) We're up to 107 pages - 45 of
which are appendices.  The main culprit is the two ASN.1 modules - one in
1988 syntax, the other 1993.

2. We have an RSA patent statement!

3. We have two example certificates and one CRL.  (Together, they comprise
a certificate path of length two.)  Thanks to David Kemp and Michael Quinn
from NSA for putting this together on *extremely* short notice.

4. There were a handful of unaddressed comments from Peter Williams and
Charlie Gardiner as of Memphis.  They are all taken care.  (Well, I think
they are taken care of.  I should wait to hear from Peter and Charlie.)

5. KEA was removed and I have submitted a separate I-D profiling KEA
certificates with respect to Part 1.  The goal is an Informational RFC.
(Part 1 could not be considered for standard status if it included a
classified algorithm.)

That takes care of the "old business".  There were a number of new issues
that arose on the list since the Memphis meeting.  I never seemed to catch
up before the threads died down, so I just read each thread and did my best
to accomodate the "sense of the group." Here is an overview:

6. Key Usage - ISO added two new values: encipherOnly and decipherOnly.
They are only defined if the keyAgreement value is asserted. Part 1 now
includes these values as well.

In addition, there was an extended discussion regarding which combinations
of keyUsage values "make sense." The Part 1 text makes no general
statements, but it does explicitly specify which combinations are
appropriate when the subjectPublicKeyInfo field contains a key for
algorithm X for any algorithm in section 7 (DSA, RSA, D-H).

7. ASN.1 tweaks. There are a couple.  Thanks to Dean Povey and John Pawling
in particular.

One should be highlighted. Charlie Gardiner noticed an ambiguity in the
encoding of a certificate without extensions.  It could be encoded as
version 3 with an empty SEQUENCE of extensions instead of version 1 or 2.

The ASN.1 for Extensions
	Extension ::=  SEQUENCE of Extension
hads been modified to state
	Extension ::= SEQUENCE SIZE (1..MAX) of Extension

This prevents a CA from issuing a version 3 certificate without extensions.
 In this case, the certificate should be version 1 or 2.

8. Path Validation
Check this one closely!  I re-wrote the path validation section, describing
a path that begins with a self-signed certificate (containing the public
key of your most trusted CA, for example).  I believe this text explicitly
addresses comments on the list (from Denis, Peter, and others) about use of
local certificates to impose security policy, and it also describes
extending the algorithm for multiple trusted certificates.

(I believe this text will be more helpful for readers who are not path
validation experts than repeating the X.509 text.  However, I worry that
some error crept in, making it incompatible with the X.509 text.)

9. Year 2000/Certificate validity
A thread on year 2000 evolved into the differences between the latest ISO
and PKIX-1 texts on validity dates.  ISO was clearer and more acceptable to
the group.  I made the appropriate changes.

10. Subject Names
The text now states that the subject and issuer distinguished name fields
(where they are used) are X.500 Distinguished Names, not just some sequence
of RDNs.  I also added text from Warwick stating "The DN, when non-null,
must be
unique for each subject entity certified by the one CA.  A CA may issue
more than one certificate with the same DN to the same subject entity."

11. The Certificate Issuer CRL entry was added.

Now - on to the "stuff we didn't do"

A. unique ids
There is no change here. The draft states that conforming CAs shall NOT
populate this field; clients are required to process this field or reject
certificates that include it.

A vocal minority would like unique ids *required*.

There is good reason the CA vendors are against unique ids. No one wants to
use them, since we have no idea how to use or manage them. In addition,
everything the minority wanted to do with the unique id could be done with
the distinguished name or an alternative name.

As you can tell, I am against unique ids and in the absence of a clear
majority for using them, the text was not changed.

B. ECDSA
There seems to be support for a profile of ECDSA for PKIX.  I would prefer
a new document, though, instead of adding to Part 1.

I am volunteering to work with Don Johnson from Certicom to prepare an I-D
(like the KEA document) before the December meeting.

(Note: there were several mildly negative comments on ECDSA regarding
exclusion of Weil Theorem and complex multiplication methods for random
number generation. These limitations were removed in the last ANSI X9.62
draft.)

C. The SET Root CA extension
There was thread of 16 messages regarding this extension.  The group was
pretty divided on this one.  Since it is a critical extension, all PKIX-1
conforming clients would be required to implement it.  I'm inclined to
exclude it on that basis, but we should probably examine it a little more
closely.

D. Combination certificates
There has been a recent thread on certificates containing both signature
and confidentiality keys.  Part 1 doesn't preclude this.  The only
recognized OIDs  for subjectPublicKeyInfo fields correspond to one key (one
RSA key, one DSA key OR one Diffie-Hellman key).  I believe this is an
acceptable compromise, especially since the biggest consumer of combination
certificates (MISSI) is transitioning to separate certificates.

Finally, I believe the document is ready for WG Last Call.  I will make
that request of the chairs.  So, if you've been waiting to read this whale,
now is the time!

Regards,

Tim Polk

Date: Wed, 30 Jul 1997 10:25:17 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: X509Info: addition to PKIX part 1
Cc: [email-masked]

> Please excuse my ignorance, but are there any thoughts about including arls 
> in this as well?

The authorityRevocationList, certificateRevocationList, and
attributeCertificateRevocationList attribute definitions all contain:

   WITH SYNTAX  CertificateList

In other words, they are three distinct attributes and contain three
different types of information, but the information is all represented
using the same ASN.1 syntax.  And although the CertificateList
structure is labeled with the comment

   -- certificate revocation list (CRL)

in reality "CRL" is used as a shorthand notation to include CRLs,
iCRLs, ARLs, ACRLs, and any other type of revocation list that might
come up.

From: "Miklos, Sue A." <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: X509Info: addition to PKIX part 1
Date: Wed, 30 Jul 97 09:28:00 EDT
Encoding: 70 TEXT

Please excuse my ignorance, but are there any thoughts about including arls 
in this as well?

Sandi
 ----------
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: X509Info: addition to PKIX part 1
Date: Tuesday, July 29, 1997 11:04AM

Tim,

Section 6 of PKIX part 1 describes Certificate Path Validation, and
says:

   "The inputs to the certification path processing procedure are:

     (a) a set of certificates comprising a certification path;

     (b) ..."

No mention is made of CRLs in the list of inputs, so I propose that
an item be added to the list after item (a):

     (b) the set of revocation lists applicable to the certification path;

or amending (a) to read:

     (a) a set of certificates and revocation lists comprising a
          certification path;

Also, there is no ASN.1 syntax for a certification path.  I propose
adding the following definition in section 6:

   The X509Info object is a collection of certificates, attribute
   certificates, and revocation lists.  X509Info may represent a
   (full or partial) certification path.  It may also represent
   one or more base certificates and their associated attribute
   certificates.

   X509Info ::= SEQUENCE OF X509Item

   X509Item ::= CHOICE {
     [0] Certificate,
     [1] CRL,
     [2] AttributeCertificate }

The syntax of X509Info is from the July 18 draft of PKCS #7 version 2,
which is (IMHO) a remarkably elegant replacement for the earlier versions
of PKCS #7.  I believe that X509Info is so useful that it should be
incorporated into the PKIX profile regardless of whether the IETF decides
to do anything with the PKCS series.

In order to use X509Info, we would also have to include the 1997
X.509 definition of AttributeCertificate (in a new section 6, pushing
the current sections 6-9 down by 1).  Including attribute certs in
PKIX part 1 is a good thing anyway, regardless of whether X509Info calls
them out.

      dpk

Date: Wed, 30 Jul 1997 13:49:18
From: plipp <[email-masked]>
To: [email-masked], [email-masked]
Subject: CFP: SEC '98

Sorry if you get multiple copies.......

-----------------------------------------------------------------------
SEC '98: IFIP TC11 14th International Information Security Conference 
August 31 - September 4 in Vienna and Budapest, Austria and Hungary

Sponsors: 
IFIP TC11
Austrian Ministry of Science and Research

SEC '98 covers a wide range of security related topics. It comprises both emphasis in technical as well as commercial aspects of information security. The conference is held within the framework of the the IFIP World Computer Congress. 

Important dates 

-	Deadline for submission of papers: January 16, 1998 
-	Notification on acceptance: March 27, 1998 
-	Deadline for the final version: May 8, 1998

More Information:
http://www.ifip.tu-graz.ac.at/TC11/SEC98/index.html

Contact: 
Prof. Dr. Reinhard Posch
IAIK Klosterwiesgasse 32/I A-8010 Graz, AUSTRIA 
Tel: +43 316 8735510 Fax: +43 316 873520 e-mail: [email-masked] 

Dr. György Papp
Prime Minister's Office Republic of Hungary
Kossuth ter 4 Budapest HUNGARY 
Tel: +36 1 269 4826 Fax: +36 1 269 0314 e-mail: [email-masked] 

Dr. Peter Lipp, IAIK, University of Technology, Graz
Institute for Applied Information Processing and Communications
Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513
________________________________________________________________________
Was nützt die beste Erziehung, die Kinder machen uns ja doch alles nach.

Date: Tue, 29 Jul 1997 17:09:55 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: X509Info: addition to PKIX part 1

Peter,

There seem to be at least three questions buried in your message - I'll
try to paraphrase and address them as I understand them.  Let me know
if I missed anything.

> From: Peter Williams <[email-masked]>
> 
> This looks like a whole new work item, depending upon the stability of
> other draft materials. 

i.e. should attribute certs be added to PKIX part 1 at this late stage?

Certainly not before 5:00 tomorrow!  (the deadline for I-D's before
Munich).  I don't have any operational reason to propose attribute certs
at all, it's just that they are already included in X.509, so I thought
for completeness they should be profiled in PKIX.

The options are:
 a) ignore attribute certs entirely in PKIX.
 b) profile them in part 1 draft -06 or later (draft -05 being the
    one Tim will post tomorrow.
 c) profile them in a new part 5.

I have no preference between b) and c), but I believe that a) would lead
to an undesirable disconnect between X.509 and PKIX, and could sacrifice
some interesting capability.

> But, why does PKIX-1 - a non-operational protocol, and profile - need
> such a declaration? Surely it does not.

The previous two times I raised the question of a path syntax, I got
no answer (except for Tim's suggestion that it might be appropriate for
part 2).  Nice to see someone's listening now :-).

X.509 itself has not one but two ASN.1 syntaxes for representing
certification paths.  Netscape has a different (non-ASN.1) syntax for
SSL and yet another ASN.1 syntax (PKCS #7 v1.5) for S/MIME.  As noted,
PKCS #7 v2.0 has yet a different syntax.  I need a cert path syntax for
my own pet protocol (draft-kemp-auth-pklogin-03.txt, now expired, but
soon to be refreshed), which is why I'm interested in the issue.  I'm
sure other network and application protocols will also need to pass
cert paths over the wire.  Should they all roll their own formats?

I'm not in favor of saying either:
a) everyone must use an ASN.1 cert path syntax, or
a) everyone must use the particular PKIX-chosen syntax.

I'm just saying that PKIX should identify the "best" syntax from a
crowded field and document it for those who have no compelling reason
to use something else.

I happen to believe that PKCS #7 X509Info would be the best structure
for the widest variety of applications.  Not only could it be used
to contain certification paths, the identical syntax can be reused for
an entirely different purpose: containing a collection of related
certificates.  The relationship is not constrained to that of
issuer-subject as in a path, it could also be a collection of certs
for the same subject (example: signature and key management certs),
or a base cert and it's associated attribute certs.  Whenever I see
the opportunity to do something in a general-purpose manner instead
of having multiple different special-purpose mechanisms, I get excited.
Sorry.

> I note that standard forms of certificate path processing have
> NO requirements or assumptions upon attribute certs (last time I looked
> anyway). Have things changed since standard-status was assigned
> to the X.509 v3 AM?

As far as I know, no.  Hoyt's draft of X.509-1997 defines
AttributeCertificationPath, ACPathData, and AttributeCertificate.  He
can answer whether those definitions are consistent with the AM you
mention.

> Hoyt Kesterson  tells me we can all search for crossed-ts and dotted-i
> at this stage to support ITU-T on X.5xx final edit, but we should
> beware of abusing committee or ISOC/ISO formal protocol here - on
> anything which may have major technical repercussions.

I hadn't considered the possibility of adding X509Info to X.509, but
since AttributeCertificate is already present, X509Info would be a
truly small addition.  Hoyt and Warwick can decide whether it is 
small enough to be considered through the defect report process at
this stage.

If X509Info can't be added to X.509, then PKIX could either define it
(as it does with it's own private extensions), or it could suggest that
Certificates or CertificationPath or AttributeCertificationPath should
be used to contain certification path information.  I would note that
none of those three X.509 structures contain a place to put CRLs, that
CRLs (including iCRLs) are used as input to the path validation process,
and that X509Info does include CRLs.  Sounds like a case could be made
for a defect report.

Summary:
 1) should PKIX define or profile a syntax for path validation info?
     I say yes.

 2) should the path syntax include a space for optional CRLs?
     I say yes.

 3) is there an X.509 path syntax that includes CRLs?
     No, none of the three existing structures do.

 4) should PKIX remain in sync with X.509?
     Yes.

 5) should PKIX profile attribute certs?
     No hurry, but do it somewhere, sometime (see #4).

 6) should PKCS #7 X509Info be added to X.509?
     open for discussion, but it does have some benefits, and it
     reconciles issues 1-4.

From: "Alan B Asay"<[email-masked]>
To: [email-masked]
cc: [email-masked]
Date: Tue, 29 Jul 1997 13:41:31 -0400
Subject: Reflections on the PKIX Part 1 Draft

The following is a paper that several of us have drafted to make some
suggestions,
mainly in regard to PKIX Part 1.

Comments are welcome.  Some time discussing some or all of these thoughts
at
the upcoming meeting may be fruitful, and some of the authors hope to be
present
there.
---------------------------------------------------------------------------
--
Reflections on the IETF PKIX Part 1 Draft
     Richard Ankney, CertCo LLC[n^^1]
     Alan Asay, CertCo LLC [^^n2]
     Mack Hicks, Bank of America [n^^3]
     Scott Lowry, Digital Signature Trust [n^^4]
     Ira Parker, Alston & Bird [n^^5]

Abstract:  While the core content of a certificate seems
fairly well settled, some questions remain about the
extensions listed in the draft of PKIX Part 1.  In particular,
the certificatePolicies field needs further definition, and the
requirements of data protection legislation and privacy
need to be addressed.  In addition, the limits of the
effectiveness of PKIX Part 1 as a technical standard need
to be made explicit, lest Part 1 give the erroneous
impression that its "constraints" and the like are
enforceable without a supporting legal infrastructure.

Note on applicability:  These suggestions may relate more
to some applications of public key infrastructure-
electronic commerce applications, for example-than to
others.  The authors assume certain uses of public key
infrastructure and have attempted to keep these
suggestions open as optional enablements rather than
universally required specifications.

     Seeking to make PKIX Part 1 and similar standards work in
running code and actual practice has been our goal in these past
years.  Our focus has for the most part not been on any
particular business application; rather, we have endeavored to
provide public key infrastructure for a wide range of potential
uses as its generally accepted role and significance expands.
     From this practical, make-it-work point of view, we have a
few suggestions. That some issues remain to be resolved perhaps
surprises no one, but above all, we want to emphasize that the
emerging public key infrastructure is generally on the right
track, at least as we perceive that track and the world in which
it is being laid. Therein, however, lies room for inquiry about
the degree of certainty possible at this juncture.

Taking Stock of Where We Are

     Standards inevitably reflect the assumptions and world-
views of the people who make them, but they nevertheless apply
to future generations regardless of whether they participate in
the standards-making or even knew that it was going on.  This
observation is not a criticism of standards-making-the same is
true of many political and regulatory processes.[n^^6]   Rule-making
by one generation for the next is simply the way a stable,
evolving society works.
     Intergenerational rule-making is a perilous venture in an
industry as immature as secure electronic commerce.  In
particular, very little is now known about the mature ecology of
the public-key trust infrastructure we envision.  The world's
existing trust infrastructure is dominated by tall timber
Institutions trusted to hold value and return it on demand, in
the future, or when misfortune happens, are large and well
established.  These institutions earned this trust by their
performance and the depth of their provable risk-bearing
capacity.  No such tall timber towers over the public key
infrastructure realized so far.  Caution, extensibility, and
flexibility are dictated in these developing circumstances, as
well as a recognition that nothing can truly be considered
settled until it is widely deployed in a mature implementation.
     Pioneering is needed now, but the value of pioneering lies in
opening up possibilities rather than in assuming too soon that
all is more settled than it is, and thereby creating impediments
to further development.  Various concepts and models for public
key infrastructure exist. Standards must avoid settling onone
particular point of view in an industry still too immature to have
ever been widely implemented in a commercial-grade
application.  The electronic commerce field is broad and
complex, and it affects multiple disciplines.  With few
substantial players and large-scale implementations in the field
now, it seems advisable to regard all conclusions as best-guess
working hypotheses and remain open to change as experience is
gained.[n^^7]

Certificate Policies

     This lack of a settled environment is apparent from trying to
make the certificatePolicies field work.  We have three main
suggestions:  (1) the  certificatePolicies field should include
provisions for specifying an address, protocol, document format,
type, title, adopter(s), version, and date (2) it should include
standardized but open-ended provisions for accreditation
between cross-certifying certifiers, and (3) the policyQualifier field
needs to be fleshed out and structured in a more robust way in
order to handle its additional data content.  The approach we
recommend expands and elaborates beyond what ITU X.509
provides while remaining consistent with the basic structure it
prescribes.

     Policy Address, Protocol, and Format

     The ITU X.509 certificatePolicies field breaks down indirectly
into possibly multiple instances of a policyInfo subfield, which in
turn contains an object identifier for the policy and a further
subfield comprised of one or more policy qualifiers.
     The importance of the policy fields lies in the fact that few
legal systems will hold a person bound by rules which she does
not know and cannot readily ascertain.  Citing a rule and
intending that it apply are pointless if the person to whom it is
cited and who is intended to be bound by it cannot readily
recognize the policy and look it up.  The object identifier
required in ITU X.509 and PKIX Part 1 is an unambiguous label,
but it is not a reference, which would imply a location and a way
of reaching it.
     PKIX Part 1 includes a workable, helpful proposal for
remedying this deficiency by including a uniform resource
identifier (URL) pointing to a certification practice statement
(cPSuri) as a mandatory policy qualifier.  It is preferable,
however, to call this field a "policyURI" or another more all-
encompassing term.  Not every policy cited in the certificate will
be a certification practice statement.  A statute, treaty,
regulation, or other legal instrument may establish important
rules applicable to the certificate that should be noted for the
relying party's benefit.[n^^8]
     Besides policyURI, a new subfield is needed to specify the
format of the cited policy.  To develop what that format
specification might be (aside from the rather obvious choice of
HTML), further work is needed.[n^^9]  With address, retrieval
protocol (both combined into a URI), and format specifications
listed in the certificate, conforming applications have the
critical information needed to obtain and display the policy.
     Besides this information for making the policy available to a
user from the certificate, the user also needs to identify the
policy.  The policyID effectively disambiguates a policy from
every other (assuming no errors in OID registration), but it does
not identify the policy in a user-friendly way.  A user needs to
know, not simply that this policy is distinct from every other but
also who adopted the policy and which one of that adopter's
perhaps multiple policies it is.  In a sense, policyIDs are like IP
addresses, in that they are unique but so nonmnemonic,
unconnected to easily recognizable concepts, and strange (from
a user's point of view) that a human-intelligible label is needed.
Besides a  policyID, a certificate should list its adopter(s), title,
version, and date.  A user can thereby readily ascertain if the
policy is the same as one already known, without having to
retrieve the policy and examine it (which could well involve a
manual process, especially if the policyFormat lacks, like HTML, a
high degree of structure and precision.

     Policy Type and Taxonomy

     Besides address, protocol, format, and identification
subfields within policyQualifiers, it may also aid a relying party to
indicate what type of policy is referenced.  Policies such as
statutes can be quite different in their content and effect than
issuer-declared certification practice statements or a contract
that the relying party entered into and at least conceivably
could terminate or amend.
     However, listing a policy type and formulating a taxonomy
are problematic propositions.  Terse statements about a policy
apart from actually reading it may not always be helpful, and
could perhaps be misleading or put a user in a position to jump
to conclusions.  Furthermore, the multiple criteria exist
according to which a taxonomy could be defined (such as means
of imposing the rule (statutes, regulations, private law, etc.), its
applicability (governs reliance, mandates certain CA conduct,
specifies choice of law and/or jurisdiction, etc.), and those
multiple, non-discrete criteria would make a taxonomy complex
and difficult to understand, and therefore perhaps of rather
little utility.  Moreover, it may also be unwise to go too far
toward representing the policy's content in the certificate, since
it increases the bulkiness of the certificate and current
protocols anticipate passing certificates with a rather large
number of messages.
     Perhaps further thought about a taxonomy and a type field
could be fruitful, but nothing is proposed here along those lines.
Accreditation
     In considering cross-certification, the act of a certifier in
issuing a certificate to another certifier, it is useful to
distinguish between two very different concepts, authentication
and accreditation.  For authentication purposes, a cross-
certifying certificate means the same as any digital signature
certificate, essentially that the subject holds a particular private
key.  In addition to that authentication significance, cross-
certification can mean-and is often thought to imply-accredi-
tation, a representation that the subscriber-certifier satisfies
some criteria specified by the accrediting issuer.[n^^10]  It is critical
to distinguish between certification of a certifier's public key
for authentication purposes and certification as effecting an
accreditation, since the undertaking of the issuer and the
resulting legal duties and risk of liability are very different for
each of those two sorts of certification.
     In order to accredit meaningfully, the issuer must specify a
measuring stick, one or more criteria that will provide the basis
for distinguishing between the accredited and the unaccredited.
Those criteria must be specified in a policy, statute, certification
practice statement, or similar document, although they may also
be specified, perhaps more generally and broadly, in a
technological standard.
     Thus, to indicate accreditation, the issuer would make a
statement in the certificate in relation to one or more of its
policies.  Since the meaning of that statement is defined by the
policy, the statement could well be a special type of policy
qualifier.  To make accreditation easy to spot in certificates
from varying issuers, its fields need standardized fields in the
certificate, perhaps a specially named substructure within
policyQualifiers.[n^^11]  That substructure will need to include qualifiers
of its own applicable to the accreditation, when it is being given.
Furthermore, if the issuer of a certificate is accredited by
another certifier when a certificate is issued, a statement of and
reference to that accreditation (or more precisely, to the
certificate evidencing it) will assist the relying party in
ascertaining the issuer's qualifications and making a judgment
regarding the issuer's soundness and suitability for the relying
party's purposes.
     The accreditation field could in time be adapted for many
uses in addition to cross-certification.  For example, the
accreditation field may point to another certificate attesting to
any attribute, qualification, or characteristic of the subscriber.
Proposal:  A New policyInfo
     As a straw man for further discussion, consider a
specification such as this as defining the content of
policyQualifiers:

SupportedQualifiersCERT-POLICY-QUALIFIER ::= { policyDetails |
accredDetails |
policyParams }

PolicyDetails ::= SEQUENCE {
     policyURI	IA5String,     -- typically a URL
     userNotice	UserNotice,   -- as in current PKIX-1
     policyFormat	CHOICE {
                    html	[0]  NULL
                    sgml	[1]  IA5String --URL of doc type definition
                         ... },
     policyAdopter	Name	 --a substructure of multiple
                         --Names may well be useful
     policyTitle	   IA5String
     policyVersion	 INTEGER
     policyDate	    PolicyDateSyntax }

AccredDetails ::= SEQUENCE {
     accredGiven	   BOOLEAN DEFAULT FALSE,
     accredGivenQualifiers	OCTET STRING,           --
     accredHeld	    AccredHeldSyntax  }

AccredHeldSyntax::= SEQUENCE {
     issuer	        Name,
     serialNumber	  INTEGER }

PolicyParams ::= SEQUENCE OF SEQUENCE {
     paramID	       OBJECT IDENTIFIER OPTIONAL,
     paramTag	 IA5String,
     paramValue	    IA5String }

policyDetails CERT-POLICY-QUALIFIER ::= {
     POLICY-QUALIFIER-ID      id-policyDetails
     QUALIFIER-TYPE	     PolicyDetails }

policyParams CERT-POLICY-QUALIFIER ::= {
     POLICY-QUALIFIER-ID	id-policyParams
     QUALIFIER-TYPE	     PolicyParams }

accredDetails CERT-POLICY-QUALIFIER ::= {
     POLICY-QUALIFIER-ID	id-accredDetails
     QUALIFIER-TYPE	     AccredDetails }

PolicyDateSyntax  ::= CHOICE {
     utcTime  UTCTime,
     generalTime GeneralizedTime }

-- need OID definitions too
}
The principal new fields proposed above and their content are
described in the following table:

SupportedQualifiers-Cert-Policy-Qualifier:
In order to contain the open-ended and policy-specific information
within a particular data area, and to distinguish accreditation from
other, more general policy information, this field would be substan-
tially all the content of policyQualfiers.

policyDetails:
Standardized policyQualifier content items not indicating an
accreditation.

accredDetails:
Standardized policyQualifier content indicating accreditation or its
limits or qualifications.

policyParams:
Policy parameters, values needed for applying a policy in specific
instances or otherwise needed for a particular policy or a particular
vendor's approach to policy issues.  Confining this application-
specific space to a defined area within policyQualifiers helps
distinguish between what is standardized and readable interoperably
across varying applications from content for which interoperability
and interpretation capabilities may be more limited.

policyURI:
The URI of the policy, certification practice statement, statute, etc.
labeled by the policyIdentifier (if any) or otherwise applicable to the
certificate.  This field is essentially the same as "cPSuri", but its
label "policyURI" is preferable because the policy may or may not be
a CPS.  As a URI, this field includes the protocol (e.g. http) and
address (e.g. www.certs4u.com) subfield as advocated above,
although not defined according to ASN.1.  Perhaps other address and
protocol specifications could be also be, such as rfc822Name (which also
implies a protocol), and which could involve a sessionless, S/MIME
mail-back
approach to obtaining and distributing a policy.

policyFormat:
An indication that the document is in HTML, or a reference to the
SGML document type definition or other format specification in
which the policy at the designated address is written.  Certificate
policies could be made much more readable and machinable if
marked up in ways that exceed the scope of plain HTML but which
are nevertheless processable by Web browsers.  The principal,
standardized methodology for document processing is SGML.
Interesting additional possibilities, such as XML, could also be
considered.  Besides or in lieu of the URL for obtaining the DTD, the
DTD could be specified as an OID or as the very similar "public text"
common in SGML environments.

policyAdopter:
The name of the person imposing the policy.  It would be unwise to
conclude, with statutes and regulations in electronic commerce
increasing at a rapid pace, that all applicable policies will be
imposed by issuers.  It may be important or helpful to notify relying
parties of as many applicable policies as possible in certificate, so
that the relying party can be adequately informed of the operative
rules.

policyTitle:
A string indicating the title of the document.

policyVersion:
The version number of the policy.

policyDate:
The date of the policy.

AccredGiven:
A binary indication whether accreditation has been granted by the
certifier.  If so, the instant certificate is evidence of that
accreditation.

AccredGivenQualifiers:
A specification of the type, level, or other value of accreditation
according to a scheme defined in the issuer's policy.  The content of
this field could be more structured than the suggested OCTET
STRING, but a simple parameter string parsable by an application is
a start.

AccredHeld:
An indication that the issuer received still-valid accreditation in the
certificate indicated.

Support for Data Protection Legislation

     Data protection legislation protects individuals' privacy in
many legal systems.[n^^12]  Such legislation restricts the widespread
use of personally identifying data records such as certificates.
One approach, taken in the German digital signature
legislation,[n^^13] is to leave out information in the certificate
identifying the subject and to include instead an identifying
number meaningful to the issuer or the subjectInfoAccess point.[n^^14]
The issuer or subjectInfoAccess provider can then arbitrate
requests for further information according to the subject's
privacy rights.
     Current certificate content specifications do not include
adequate support for certificates listing no information
identifying the subscriber other than a code or account number
meaningful only to an arbiter of privacy restrictions.  The
general names do not include such an identifier.  A
distinguished name could be envisioned indicating the
certificate issuer's name space, with the arbiter's reference code
in the common name field.  However, such a near-meaningless
name is a very different sort of name than a standard
distinguished name.  Even if it is permitted by X.500, it should
be distinguished from a more effectively identifying type of
name.
     In accommodating data protection policies in this manner,
the issuer has a compelling need to indicate that a label
intended to be meaningful only to a few has no further meaning.
The issuer is legally responsible for the accuracy of content of
the certificate; otherwise, it has no value.  Including a
pseudonym or arbitrary quasi-identifier, without indicating that
it is such, could expose the issuer to potential liability for
misidentification.
     To satisfy legal data protection requirements, a field,
perhaps named dataProtCode, could be added to subjectAltName, or
to general names (although the main need is related only to the
subject, not to every entity for which general names could be
used).

"Constraints" and the Role of Standards

     A final, perhaps cautionary, question is whether the aims of
PKIX Part 1, and the standard extensions of ITU X.509 for that
matter, come across perhaps a little grander than IETF can
realistically hope to achieve.  The effective role of standards is
to govern the operation of information technology-devices and
their performance-but not to govern people or societies.  It is
the law's task to govern people, societies, commerce, and econ-
omies.  The distinction between technological operations and
human, social, and economic engineering is difficult to grasp
fully and apply in actual cases, but the consequences are very
significant.  Society is not likely to enforce or give real, practical
meaning to a technological standard that oversteps its bounds of
prescribing the mode of operation for devices.  Meanwhile,
before that day of reckoning, the technological standard may
give false comfort to technologists who look to it for guidance.
     Consider, for example, what the constraints in the ITU X.509
standard extensions-which are essentially repeated in PKIX
Part 1-really mean in light of the technology-law distinction.
The basicConstraints field in a certificate purports to preclude a
subject from subcertifying based on the certificate containing
the prohibitive basicConstraints.  However, the certificate has
little power to impose such a requirement on the behavior of the
subject.  Whether the subject may subcertify is an appropriate
topic for a contract between the issuer and the subject, but the
certificate is a weak means of establishing such a contract.  It
essentially a one-party instrument, is not authenticated by the
subject, and contains no indication that the subject assented to
its terms or agreed to be bound by them.  No existing statutes
fill in for the absence of such contractual constraints and
mandate that certificate subjects behave in the manner
indicated by the basicConstraints of the certificate.  Although they
cannot impose any such requirement as a matter of right, the
basicConstraints could reflect a requirement imposed elsewhere.
However, the real difficulty in this regard is that the
descriptions of the "constraint" fields fail to make clear that
they do not really impose any constraint but rather merely
report about one imposed elsewhere.
     In other words, it is problematic to see a certificate as
imposing a firm, well-defined obligation on its subject or on a
relying party.  Rather, a public key certificate is simply a
representation of fact to a relying party.  The scope of the facts
represented can be limited, but most other ways the certificate
is at best a cumbersome means of limiting rights and imposing
affirmative duties.  Duties and limitations of rights can be made
binding the subject and relying party by other legal means, and
their rights can be restricted, but not merely by telling them so
in a certificate.  One could as well tell them that their
possessions have been transferred to someone else-telling
simply does not legally make it so.  A statute, validly created
contract, or other means of imposing legal obligations is
necessary for the relying party to be legally bound.  A
certificate can effectively give notice to a relying party, but at
most, notice merely limits in an uncertain way the right of a
party to rely on the representation.
     If no contract or statute applies, the right of a party to rely
on a representation is defined by the general law applicable to
misrepresentations.  Ordinarily, an issuer will not have
knowingly intended to commit a fraud in issuing a false
certificate, so the fault of the issuer will be based on its
negligence.  The scope responsibility for negligent
misrepresentation and the effect of notice on that responsibility
are both highly uncertain.[n^^15]   The prevailing notion that a
certificate becomes binding on relying parties simply by giving
them notice of it, without a supporting statute or valid contract,
is therefore highly uncertain.
     Contracts and statutes can impose obligations, but valid
contracts are not made simply by giving notice of them.
Contract formation generally requires a manifestation of assent,
some observable, affirmative indication that the party in
question agrees to be bound.  Action in ignorance of a
contractual offer is a manifestation of assent only under
exceptional and narrowly limited circumstances.  Generally in
the United States, for example, the following rules are applied:
  Acceptance by Silence or Exercise of Dominion
     (1) Where an offeree fails to reply to an offer, his
  silence and inaction operate as an acceptance in the
  following cases only:
          (a)  Where an offeree takes the benefit of offered
  services with reasonable opportunity to reject them and
  reason to know that they were offered with the expectation
  of compensation.
          (b)  Where the offeror has stated or given the
  offeree reason to understand that assent may be
  manifested by silence or inaction, and the offeree in
  remaining silent and inactive intends to accept the offer.
          (c)  Where because of previous dealings or
  otherwise, it is reasonable that the offeree should notify
  the offeror if he does not intend to accept.
     (2)  An offeree who does not act inconsistent with the
  offeror's ownership of offered property is bound in
  accordance with the offered terms unless they are
  manifestly unreasonable.[n^^16]
Even if receipt of a certificate is somehow deemed tantamount
to receipt of an offer by the certifier to the receiver to enter into
a contract, reliance on the representations in that certificate
may well not amount to an acceptance of the terms of that offer,
especially if the offeror cannot demonstrate that the offeree
even knew of the offer.[n^^17]  In limited situations, such as if the
certificate is a known but unpaid-for benefit or service for the
receiving party, subsection (1)(a) would imply acceptance of an
obligation to pay for it.[n^^18]  Subsection (1)(b) would apply only if
the offeror can demonstrate that the offeror communicated to
the offeree "reason to understand that assent may be
manifested by silence or inaction."[n^^19]  In that event, the offeree
retains the right of later contesting contract formation by
demonstrating that he never intended his silence and inactivity
to constitute acceptance.  The point here is that it is quite
possible for contracts to be made by assent, including assent
manifested online,[n^^20] but they are not made simply by posting an
opportunity to contract somewhere on the Internet.  Assent
ordinarily requires an affirmative act by the assenter.  That
principle applies with even greater force when the offeree,
"assenter," and eventual defendant is a consumer.
     Besides the failure to acknowledge contractual or statutory
dependencies, a further difficulty with basicConstraints lies in the
fact that the relying party is in a weak position to enforce the
obligation not to subcertify owed by the subject to the issuer.
The relying party is quite limited, for example, in its right to sue
the subcertifier for violating a contractual duty owed by the
subcertifier to its issuer.  To illustrate, suppose that Ivan issues
a certificate to Scott, who in turn issues a certificate to Susan
contrary to the basicConstraints in the certificate from Ivan to
Scott (basicConstraints/certifier was set to false).  Susan sends the
certificate issued by Scott with her digital signature to Reggie.
Reggie could interpret the basicConstraints field to mean that
Ivan, the issuer, is thereby stating that Ivan does not intend for
Scott to be subcertifying.  However, Reggie is not the enforcer
of the contract between Scott, or even interested in what that
contract might say, unless it affects the reliability of a
representation in an important certificate.  Reggie can infer
little about the accuracy of Scott's representation, for example,
that Susan holds the specified public key, from the fact that
Scott appears to be subcertifying when Ivan thought he would
not be.  Scott and Ivan appear to have conflicting expectations
of each other, and there appears to be at least a
misunderstanding, but none of that is Reggie's business.  Even if
Scott broke a promise (which will not be clear from the face of
the certificate), promise-breaking does not equate to
misrepresenting the fact that Susan holds a specified public key.
     It therefore accomplishes little for the issuer to say, in
effect, "I hereby certify that the subject is constrained from
acting as a certifier" even if basicConstraints make that intent
entirely clear.  The relying party is, in the absence of a valid
promise otherwise, simply not an enforcer of a reported
obligation between the issuer and the subject, and may well
have a reason to proceed notwithstanding basicConstraints to the
contrary.
     Of course, the relying party's computer may, consistent with
its interpretation of the basicConstraints, preclude an opportunity
to rely on the offending certificate or its progeny.  Such
technological enforcement of the basicConstraints may be useful in
precluding reliance as a matter of fact, but it is significant that
the program is operating without regard to the real legal
obligations of the parties.   Setting computers in motion with
such scant regard to the rules that actually govern behavior in
society is a questionable course from a public-policy standpoint.
     Like the constraints, the criticality flag is a functional device
capable of controlling program execution, but it is not a self-
sufficient means of limiting the true right to rely.  The
criticality flag essentially seeks to prevent a party from relying
on a certificate extension that the party does not understand or
accept.  However, the criticality flag resembles the constraints
in that it assumes legal duties apart from the certificate, but its
descriptions in standards such as PKIX Part 1 are less than
explicit about this dependency.  It is another example of
implying restrictions on human behavior without recourse to or
even apparent consideration of the applicable law.
     Perhaps the worst lack of explicit correlation with external
legal infrastructure is the nameConstraints field.  An issuer filling
in the nameConstraints is likely to be powerless to affect the
subject's real legal rights to give and take names.  The issuer
could opine in nameConstraints about subject's power right to use
a name, but perhaps with some reticence, since that right will in
fact be determined by trademark and other naming laws.  It was
this sort of oversight that led to the domain naming mess,[n^^21]
which demonstrates that, in addition to the technological utility
of a name, naming also involves important, valuable legal rights
that should be respected in accordance with external legal rules.
PKIX Part 1 provides no process to assure that legal name
restrictions are observed.  Worse, it gives an issuer the issuer's
apparent ability to constrain name misuse, so for every legal
name misuse stemming from a certificate, the issuer can be sued
on the theory that the issuer could have taken steps using
nameConstraints to prevent the misuse.
     In sum, the difficulty with PKIX Part 1 and similar standards
is that they do not clearly indicate their dependence on external
legal infrastructure to impose obligations and constraints.  Since
that external legal infrastructure has a mind of its own, the
issuer has a need to correlate the certificate with that
infrastructure, as the nameConstraints demonstrate in relation to
trademark and other naming laws.  PKIX Part 1 fails to
acknowledge how it relates symbiotically with supporting legal
infrastructure.  Consequently, it is not only possible but likely
that readers of PKIX Part 1 conclude, for example, that the
basicConstraints actually constrain, and that the criticality flag
actually precludes reliance when set to "true."  In giving that
impression, PKIX Part 1 is a dangerous oversimplification.  It
should more clearly state that it assumes duties imposed
elsewhere, and that its purpose is to prescribe certificate
content conventions but not to make them legally effective in
governing anyone's conduct or forbearance.  To solve this
problem, a paragraph like the following could be inserted into
the "Requirements and Assumptions" section of PKIX Part 1:
  This standard describes the form and content of a
  certificate in order to facilitate the processing of
  certificates by technological systems and components.  It
  does not in itself prescribe legally binding rules or duties

  for electronic commerce and similar business applications.
  Whether the effects described for some items of content in
  a certificate are legally enforceable and whether, in
  creating such content, the issuer complies with the laws of
  various legal systems are issues not resolved in this
  technical standard.
     Such a disclaimer simply skirts real issues and needs without
resolving them. To achieve a resolution, the PKIX effort needs
to be much more interdisciplinary. Greater efforts should be
made to involve all relevant disciplines and to use simple means
of expression that can facilitate rather than hinder an
interdisciplinary exchange of perspectives.
Conclusion
     Concerning specific fields in a certificate, greater degree of
definition will help make certificatePolicies more useful, and will
enable certificates to comply with data protection (privacy)
restrictions imposed in many of the world's larger legal systems.
Beyond these specific suggestions, the PKIX Part 1 standard
should clearly indicate its dependencies on outside legal
infrastructure to impose enforceable requirements, and indicate
where well-known, mandatory legal duties may affect the use of
a field.
     More remains to be said about all aspects of certificate
content.  This area of technology differs from others in that it is
not simply about making devices go but about making commerce
go, and that is a much broader and more challenging objective
than the purely technological one.   As the implementation of
public key infrastructure increases, much will come to light
about how secure electronic commerce needs to work.  In these
interesting times part of the way through that process, perhaps
the greatest error may be to be too sure about anything too
soon.

Notes
1.  Richard Ankney has authored many standards of ANSI and ASTM.
>From 1991 until joining CertCo in 1996 Richard was Chief Scientist for
Fischer International Systems Corporation.  He has worked in
computer communications and networking since 1983 for firms
including SWIFT.

2.  Alan Asay was the principal author of the Utah Digital Signature Act
and the first version of the American Bar Association Information
Security Committee's Digital Signature Guidelines.

3.  Mack Hicks is a vice president in the Interactive Banking Division of
Bank of America, and specializes in electronic commerce and public
key infrastructure.  He has been with Bank of America since 1979, and
was formerly with Wells Fargo Bank and IBM's T.J. Watson Labs.  He
graduated from Carnegie Mellon University.

4.  Scott Lowry is president of Digital Signature Trust, an affiliate of
Zions Bancorporation.  He has extensive experience in commerce as a
professional banker.

5.  Ira Parker is a partner in Washington D.C. office of the law firm of
Alston & Bird and is the head of its electronic commerce practice.  Ira
is also the editor-in-chief of the Electronic Banking Law and Commerce
Report and is a frequent speaker on these issues. Before joining Alston
& Bird, Ira was the Assistant General Counsel for litigation and policy
at the Federal Deposit Insurance Corporation.

6.  The comparison of standards-making to law-making has limits.  Law-
making takes even greater pains than standards-making to assure that
it affords the governed an opportunity to be represented and voice
their opinions.  If representativeness is limited, as in judicial dispute
resolution, legal process strives to work from experience and carefully
weaves the future out of the past.  If no directly applicable rule from
experience is available, the law will draw heavily on analogy and
principles generalized from rules established in experience and
perhaps also in an electoral process.  Perhaps the greatest dissimilarity
is, as the latter part of this paper notes, that standards by themselves
lack the force of law.

7.  Perhaps nothing in the history of public key infrastructure
demonstrates its developing nature better than the course of its core
standard, ITU X.509.  In the decade of its existence, it has been
amended three times before being widely implemented.  Such
responsiveness to the need for change is necessary.  Moreover, even
though the current version 3 undoubtedly represents the best technical
thought of its time on the subject of certificate content, there is no
reason to believe that a history of learning as we go is at an end,
especially for the extensions new to version 3.

8.  The definition of "policy" is best left a broad enough to encompass all

of the useful content of the certificatePolicies field.  That content could

and will probably include other rules applicable to the certificate,
whether adopted as a technical security ruleset, CPS, contract, statute,
or any form defined according to its means of imposition.  PKIX Part 4
uses "policy" in a somewhat different sense perhaps better termed a
"security policy" or "security profile," a description or prescription of
technological systems processes relating to computer and network
security intended for a technical audience and implementation.
Perhaps "application security profile" is a more fitting label for a
concept defined as "A named set of rules that indicates the
applicability of a certificate to a particular community and/or class of
application with common security requirements."
  The current conceptual delimitations and labeling-the definitional
work-in the policy area (broadly defined) is none too clear or
comprehensive.

9.  To the extent that the structure and topical content of a policy can be

anticipated, markup technologies such as the Standard Generalized
Markup Language ("SGML," ISO 8879 (1986, as amended)) can make
the content more usable and useful. See, e.g., Utah Administrative
Rule R154-10-202 (draft, 1995) (proposing an HTML-based format
specification defined according to SGML (as HTML also is)).

10.  Accreditation could consist of governmental licensing, private-sector
recognition, rating, or audit reports, or the judgments or findings of
similar evaluations.

11.  Alternatively, accreditation information could be listed in an
extension.  In a sense, all information in the certificate, not just
information about accreditation, is dependent on the policy for its
precise meaning.

12. E.g. Teledienstedatenschutzgesetz s 4(1) (1997) ("Der Diensteanbieter
hat dem Nutzer die Inanspruchnahme von Telediensten und ihre
Bezahlung anonym oder unter Pseudonym zu ermoeglichen, soweit dies
technisch m?glich und zumutbar ist. Der Nutzer ist ?ber diese
Moeglichkeiten zu informieren." (An online service provider must
include an option to set up and pay for services anonymously or under
a pseudonym, and must inform users of the option.));
Bundesdatenschutzgesetz ss 19, 33-34 (disclosure to affected persons),
ss 20, 35 (justification, destruction, or blockage of data) (1990); 19
LLOYD & SIMPSON, LAW ON THE ELECTRONIC FRONTIER 41-59 (British
law).  For the relatively modest U.S. legislative and case-law attention
to privacy, see H.H. PERRITT, JR., LAW AND THE INFORMATION
SUPERHIGHWAY 87-159 (1996) and L. ROSE NETLAW, YOUR RIGHTS IN THE
ONLINE WORLD 165-85 (1995), J. ROSENOER, CYBERLAW:  THE LAW OF
THE INTERNET 129-60 (1996); T. SMEDINGHOFF, ED., ONLINE LAW: THE
SPA'S GUIDE TO DOING BUSINESS ON THE INTERNET 267-81 (1996).
Even if legislation does not mandate data protection, privacy
protection is a service that subjects may desire and issuers may
provide, perhaps as a preventive measure to alleviate the need for
legislation.

13.  See Informations- und Kommunikationsdienste-Gesetz (IuKDG), art.
3, s 4(1) (1997) ("Der Diensteanbieter hat dem Nutzer die
Inanspruchnahme von Telediensten und ihre Bezahlung anonym oder
unter Pseudonym zu erm?glichen, soweit dies technisch m?glich und
zumutbar ist. Der Nutzer ist ?ber diese M?glichkeiten zu
informieren.").

14.  For an examination of anonymity and pseudonymity under United
States law using the Internet, see Froomkin, Regulation of Computing
and Information Technology, 15 JOURNAL OF LAW AND COMMERCE 395,
295-449 (1996).  It is noteworthy that, although the United States has
relatively little statutory or case-law elaboration of a right to privacy,
the right to communicate anonymously has been constitutionally
recognized by the Supreme Court in McIntyre v. Ohio Elections
Commission, 115 S.Ct. 1511 (1995), analyzed in Froomkin, supra, at 427-
43.

15.  The effect of notice on the relying party, in the absence of a
contract
prescribing the effect of the notice, is governed by the law applicable
to misrepresentations.  In the United States, that law is highly
uncertain. See Froomkin The Essential Role of Trusted Third Parties in
Electronic Commerce, 75 ORE L. REV. 49, 91-104 (1996).  It is not much
clearer in British law either.  See W.V.H. ROGERS, WINFIELD AND
JOLOWICZ ON TORT 303-306 (14th ed. 1994).

16.  RESTATEMENT SECOND OF CONTRACTS s 69 (1981).  To translate the
legalese, "offeror" is the person proposing to enter into the contract
and "offeree" is the person receiving that proposal.  "Acceptance" is
the objectively evaluated manifestation of assent by the offeree that
forms a contract (provided that "consideration" or a valid substitute is
present, assuming that U.S. law applies).

17.  1 A.L. CORBIN & J.M. PERILLO, CORBIN ON CONTRACTS  3.5 (rev. ed.
1993) ("There is no power of acceptance by one to whom the offer is
wholly unknown.").  The section cites many cases in which someone
published an offer to pay a reward, and another person satisfied the
requirements for the reward without knowing of the offer.[n^^17]  Such cases

hold that the published offer is not accepted by the unknowing actor,
so no contract is created.

18.  The obligation to pay is not implied when the benefit has already
been paid for by somebody else.  In particular, if the subject has
already paid for the certificate, the relying party may be a third-party
beneficiary of the subject-issuer arrangement, but such a beneficiary
receives benefits at the pleasure of the party conferring the benefit,
without incurring obligations of her own.

19.  Simply broadcasting or publishing one's intentions to treat silence as

assent probably do not suffice to give "reason to understand."
Comment c of the RESTATEMENT SECOND OF CONTRACTS  69 explains:
  The mere fact that an offeror states that silence will constitute
  acceptance does not deprive the offeree of his privilege to remain
  silent without accepting.  But the offeree is entitled to rely on
  such a statement if he chooses.
The prospect for convenient, after-the-fact "discovery" of one's intent
is evident in the following illustration following the same comment of
the Restatement:
  2.  A offers by mail to sell to B a horse already in B's
  possession for $250, saying:  "I am so sure that you will
  accept that you need not trouble to write me.  Your silence
  alone will operate as acceptance."  B makes no reply, but
  he does not intend to accept.  There is no contract.

20.  See R.T. Nimmer, Electronic contracting: Legal Issues, 16 JOHN
MARSHALL J. COMPUTER & INFORMATION LAW, 3, 6-12 (1996); L. ROSE,
NETLAW: YOUR RIGHTS IN THE ONLINE WORLD 78-81 (1996); T.
SMEDINGHOFF, ED., ONLINE LAW 77-83 (1996).

21.  Some of the more notorious cases of the DNS-trademark problem are
listed in T. SMEDINGHOFF, ONLINE LAW 230-31 (1996).

Date: Tue, 29 Jul 1997 11:50:46 +0100
From: Peter Williams <[email-masked]>
To: [email-masked]
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: X509Info: addition to PKIX part 1

Tim,

This looks like a whole new work item, depending upon the stability of
other draft materials. Given we were last IETF attempting to get PKIX-1
document
stable for IESG evaulation in the *current* session, perhaps we really
ought not to change matters so drastically. Adding requirements for
two new large functional groups at this stage would change an
implementors
and evaulators schedule very drastically, and adding syntaxes &
procedures (other than
in pre-noted extension areas) would not constitue "a profile" in any
case.

(when we created the SET profile, we were very careful to stay within
the bounds allowed by the ISO spec, and therefore maintain the ability
for implementations to be certified as conforming under international
conformance test procedures, and standardised criteria)

But assuming it goes foward, why do we need an "ASN.1" syntax to
pass locally-collected data to a certificate path validation module?

Do we wish to signal a requirement  that *all* implementors use ASN.1,
and
possibly a binary encoding, as the interface structure for this
function? (My own
experience of ASN.1 in the Internet is one should use it economically as
possible,
and only, largely, for interworking communication, otherwise developers
revolt.)

Protocols which pass certification paths may have different assumptions
& needs for indications of data - in such as the ASN.1 form David
suggests. But,
why does PKIX-1 - a non-operational protocol, and profile - need
such a declaration? Surely it does not.

I note that standard forms of certificate path processing have
NO requirements or assumptions upon attribute certs (last time I looked
anyway). Have things changed since standard-status was assigned
to the X.509 v3 AM?

If there is something broken in X.509 in this area, then IETF PKIX WG
should
support David/MISSI in the raising of an ISO/ITU defect report, and
amendment.
Profile groups should not, I suggest, make up for ISO/ITU mistakes, if
any; it only
lead to version conflicts down the road.

Hoyt Kesterson  tells me we can all search for crossed-ts and dotted-i
at this stage to
support ITU-T on X.5xx final edit, but we should beware of abusing
committee or
ISOC/ISO formal protocol here - on anything which may have major
technical
repercussions.

David P. Kemp wrote:

> Tim,
>
> Section 6 of PKIX part 1 describes Certificate Path Validation, and
> says:
>
>    "The inputs to the certification path processing procedure are:
>
>      (a) a set of certificates comprising a certification path;
>
>      (b) ..."
>
> No mention is made of CRLs in the list of inputs, so I propose that
> an item be added to the list after item (a):
>
>      (b) the set of revocation lists applicable to the certification
> path;
>
> or amending (a) to read:
>
>      (a) a set of certificates and revocation lists comprising a
>           certification path;
>
> Also, there is no ASN.1 syntax for a certification path.  I propose
> adding the following definition in section 6:
>
>    The X509Info object is a collection of certificates, attribute
>    certificates, and revocation lists.  X509Info may represent a
>    (full or partial) certification path.  It may also represent
>    one or more base certificates and their associated attribute
>    certificates.
>
>    X509Info ::= SEQUENCE OF X509Item
>
>    X509Item ::= CHOICE {
>      [0] Certificate,
>      [1] CRL,
>      [2] AttributeCertificate }
>
> The syntax of X509Info is from the July 18 draft of PKCS #7 version 2,
>
> which is (IMHO) a remarkably elegant replacement for the earlier
> versions
> of PKCS #7.  I believe that X509Info is so useful that it should be
> incorporated into the PKIX profile regardless of whether the IETF
> decides
> to do anything with the PKCS series.
>
> In order to use X509Info, we would also have to include the 1997
> X.509 definition of AttributeCertificate (in a new section 6, pushing
> the current sections 6-9 down by 1).  Including attribute certs in
> PKIX part 1 is a good thing anyway, regardless of whether X509Info
> calls
> them out.
>
>       dpk

Date: Tue, 29 Jul 1997 14:27:40 -0400
To: Mike Smith <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: X509Info: addition to PKIX part 1
Cc: [email-masked]

Mike, David, and list...

The (long awaited) new draft of PKIX Part 1 will be posted tomorrow and
will include a new Section 6 for path validation.  It will note the
requirement for status information, with CRLs called out as one
possibility.  The type of CRL is not addressed in that section but indirect
CRLs are supported by PKIX-1.

On David's second topic, I believe that a certification path structure
could be added to Part 1, and it could be consistent with X509Info, but
attribute certificates should not be added to Part 1.  This is a
significant change in scope; if the group wants attribute certificates it
should be a new part.  (I think it's a good idea, and would volunteer some
time to the project.  The topic hasn't come up too much before, though.)
Let's discuss that one in Munich.

Tim Polk

At 11:59 AM 7/29/97 -0600, Mike Smith wrote:
>Will "indirect" CRLs be included in the validation path descriptions?  If
a set of certificates are gathered from a single source (i.e., recognized
repository) and they were issued from a various CAs, then the central
source could issue one CRL with all the related entries necessary for
complete path validation in one step.
>
>Michael
>
>>>> David P. Kemp <[email-masked]> 07/29/97 09:04AM >>>
>
>Tim,
>
>Section 6 of PKIX part 1 describes Certificate Path Validation, and
>says:
>
>   "The inputs to the certification path processing procedure are:
>
>     (a) a set of certificates comprising a certification path;
>
>     (b) ..."
>
>
>No mention is made of CRLs in the list of inputs, so I propose that
>an item be added to the list after item (a):
>
>     (b) the set of revocation lists applicable to the certification path;
>
>or amending (a) to read:
>
>     (a) a set of certificates and revocation lists comprising a
>          certification path;
>
>
>Also, there is no ASN.1 syntax for a certification path.  I propose
>adding the following definition in section 6:
>
>
>   The X509Info object is a collection of certificates, attribute
>   certificates, and revocation lists.  X509Info may represent a
>   (full or partial) certification path.  It may also represent
>   one or more base certificates and their associated attribute
>   certificates.
>
>
>   X509Info ::= SEQUENCE OF X509Item
>
>   X509Item ::= CHOICE {
>     [0] Certificate,
>     [1] CRL,
>     [2] AttributeCertificate }
>
>
>
>The syntax of X509Info is from the July 18 draft of PKCS #7 version 2,
>which is (IMHO) a remarkably elegant replacement for the earlier versions
>of PKCS #7.  I believe that X509Info is so useful that it should be
>incorporated into the PKIX profile regardless of whether the IETF decides
>to do anything with the PKCS series.
>
>In order to use X509Info, we would also have to include the 1997
>X.509 definition of AttributeCertificate (in a new section 6, pushing
>the current sections 6-9 down by 1).  Including attribute certs in
>PKIX part 1 is a good thing anyway, regardless of whether X509Info calls
>them out.
>
>      dpk
>

    !
>!
>

    !
>!
>

                                          
>
>

Date: Tue, 29 Jul 1997 11:59:27 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: X509Info: addition to PKIX part 1

Will "indirect" CRLs be included in the validation path descriptions?  If a set of certificates are gathered from a single source (i.e., recognized repository) and they were issued from a various CAs, then the central source could issue one CRL with all the related entries necessary for complete path validation in one step.

Michael

>>> David P. Kemp <[email-masked]> 07/29/97 09:04AM >>>

Tim,

Section 6 of PKIX part 1 describes Certificate Path Validation, and
says:

   "The inputs to the certification path processing procedure are:

     (a) a set of certificates comprising a certification path;

     (b) ..."

No mention is made of CRLs in the list of inputs, so I propose that
an item be added to the list after item (a):

     (b) the set of revocation lists applicable to the certification path;

or amending (a) to read:

     (a) a set of certificates and revocation lists comprising a
          certification path;

Also, there is no ASN.1 syntax for a certification path.  I propose
adding the following definition in section 6:

   The X509Info object is a collection of certificates, attribute
   certificates, and revocation lists.  X509Info may represent a
   (full or partial) certification path.  It may also represent
   one or more base certificates and their associated attribute
   certificates.

   X509Info ::= SEQUENCE OF X509Item

   X509Item ::= CHOICE {
     [0] Certificate,
     [1] CRL,
     [2] AttributeCertificate }

The syntax of X509Info is from the July 18 draft of PKCS #7 version 2,
which is (IMHO) a remarkably elegant replacement for the earlier versions
of PKCS #7.  I believe that X509Info is so useful that it should be
incorporated into the PKIX profile regardless of whether the IETF decides
to do anything with the PKCS series.

In order to use X509Info, we would also have to include the 1997
X.509 definition of AttributeCertificate (in a new section 6, pushing
the current sections 6-9 down by 1).  Including attribute certs in
PKIX part 1 is a good thing anyway, regardless of whether X509Info calls
them out.

      dpk

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        

Date: Tue, 29 Jul 1997 11:04:43 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: X509Info: addition to PKIX part 1
Cc: [email-masked]

Tim,

Section 6 of PKIX part 1 describes Certificate Path Validation, and
says:

   "The inputs to the certification path processing procedure are:

     (a) a set of certificates comprising a certification path;

     (b) ..."

No mention is made of CRLs in the list of inputs, so I propose that
an item be added to the list after item (a):

     (b) the set of revocation lists applicable to the certification path;

or amending (a) to read:

     (a) a set of certificates and revocation lists comprising a
          certification path;

Also, there is no ASN.1 syntax for a certification path.  I propose
adding the following definition in section 6:

   The X509Info object is a collection of certificates, attribute
   certificates, and revocation lists.  X509Info may represent a
   (full or partial) certification path.  It may also represent
   one or more base certificates and their associated attribute
   certificates.

   X509Info ::= SEQUENCE OF X509Item

   X509Item ::= CHOICE {
     [0] Certificate,
     [1] CRL,
     [2] AttributeCertificate }

The syntax of X509Info is from the July 18 draft of PKCS #7 version 2,
which is (IMHO) a remarkably elegant replacement for the earlier versions
of PKCS #7.  I believe that X509Info is so useful that it should be
incorporated into the PKIX profile regardless of whether the IETF decides
to do anything with the PKCS series.

In order to use X509Info, we would also have to include the 1997
X.509 definition of AttributeCertificate (in a new section 6, pushing
the current sections 6-9 down by 1).  Including attribute certs in
PKIX part 1 is a good thing anyway, regardless of whether X509Info calls
them out.

      dpk

From: Charles Moore <[email-masked]>
To: [email-masked], "Fillingham, David W." <[email-masked]>
Cc: [email-masked]
Subject: RE: Combo DSS/ElGamal keys
Date: Tue, 29 Jul 1997 07:31:36 +1000

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Tuesday, 29 July 1997 3:22
> To:	Fillingham, David W.
> Cc:	[email-masked]
> Subject:	Re: Combo DSS/ElGamal keys
> 
> Dear folks,
> 
> Placing my two cents in the balance, so that it goes on the right side
> 
> :-) I would simply say that having two keys within the same
> certificate
> is not appropriate and should not be supported by the PKIX series of
> documents.
> [Charles Moore]  Having implemented this approach once, I agree.
> 
> Denis
> 
> -- 
> 
>       Denis Pinkas     Bull S.A.         E-mail :
> [email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 28 Jul 1997 16:37:23 -0400
From: John Lowry <[email-masked]>
To: [email-masked]
Subject: Re: Combo DSS/ElGamal keys
Cc: [email-masked], [email-masked]

Peter,

	I can't discern the point you are trying to make.

	You seem to want two keys in a single certifiate
	and haven't addressed how you are going to provide
	the management flexibility required.  One key, one cert
	is the only technically feasible approach today.
	Two keys in one cert cannot be managed independently.

	I note that non-repudiation is a tricky issue
	and not likely to be supported by any number of keys
	in a certificate.  There are other requirements
	to establish non-repudiation like a trusted time 
	reference and waiting until the _next_ CRL is issued.

	Finally, I believe that the burden lies with you
	to produce a definitive statement of what you
	wish to accomplish and build supporting arguments.
	It is unfair to present a novel idea and defend it
	by forcing others to defend their existing approach.
	I think you should write and publish the paper.

Regards,

John Lowry

Date: Mon, 28 Jul 1997 12:29:03 +0100
From: Peter Williams <[email-masked]>
To: [email-masked]
CC: "Fillingham, David W." <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Combo DSS/ElGamal keys

David Fillingham argues that multi-key certificates do not aid
acceptance of "proof or origin with non-repudiation service. This
I would agree with, though such agreement is incidental to my argument.

Denis Pinkas states (simply) an opinion, which goes in the same
category as a claim made by the Entrust folk for
at least 5 years (from Carlise and Douglas, recently) that "something"
about rekeying and security service validity gets "upset".

[One should note that I do not object to Entrust notions, as
an available option to users of Netscape and Microsoft
software for example; whatever else that the technique does
(or does not do), it enables key recovery and crypto registration
based on access to asymmetric encryption keys  and for that there
is certainly demand in many, many camps.]

Please both, recall the nature of the discussion, and the schema
I pictured figuratively in my commentary mail:

"NB the difference between regimes
(a) solemn-signing + (single-key Key Agreement)
(b) solemn-signing + (dual-key Key Agreement)
(c) no-solemn-signing-capability + (dual-key Key Agreement)"

There is an emerging proposal (which PKIX may not credit, though
cannot discredit in its current policy-independent formulation) in
which a party may have two certificates, one for solemn-signing,
and another for establishing connection or connectionless
security, when using non-reversible algorithms, or when
using conforming X.509 algorithms such as RSA.

It was the purpose of the figure to demonstrate that a
solemn-signing key (certified), and a key agreement
key(set) (also certified) might be proposed as a PKIX
policy to enable (once certified) the execution and provision
of  the claimed semantics . Depending on the latter
algorithm, the key(set) (which does not serve
the purposes of "proof of origin with non-repudiation")
may u practice have one or more keys. The algorithm
underlying MISSI KEA procedure (a shared-secret
algorithm) is itself a four-key design (one from KEA cert
another from self-signed UKM "cert", for each party) one
notes, in passing,and an algoirithm-using design might
enjoy benefits from such a  policy when used in environments
without directories or ISAKMP.)

Based on David Kemp's non-partisan observation that there
is *logical* merit in a creating a key*set* for a key-agreement
procedure in which a proof of origin signature (WITHOUT
NON-REPUDIATION) is used to assist a DH exchange,
I argued that we have a significant case for continuing to support
not only the Entrust policy scheme, the MISSI policy scheme(s), and
the 1422 policy meta-scheme in PKIX (as expressely required by our
PKIX scope) but there are yet other policy schemes  to be invented by
private or public organizations.

I can see currently no value in denying scope for policy innovation
given PKIX does not mandate any form of policy. I find the comment
of Denis largely unacceptable, as it would require repudiation
in PKIX of v1 certs and could label X.509 conforming systems
non-conforming
to PKIX.

I really do not wish to argue further on this list. I would first ask
the
academic end of the Entrust group (and any secure telephone making
friends), which has historically made the "vital" commercial claim for
dual key, dual cert systems, that they write an objective paper in a
an appropriate journal in which the technical claims and
vulnerabilities are laid out once and for all. I for one will
not be impressed if the underlying argument  (express or
otherwise) is to enable a uniform migration of older and deploying
systems to a world of *mandatory* key-recovery. I will be
similarly be unimpressed if the argument presumes
an environment of classical secure telephones or
ISAKMP in the data-networks enviornment, where the
Internet is infact a multi-context, multi-layer, multi-algoiorhtm,
multi-policy environment. I will be yet
further unimpressed if the argument seems to aim to merely
suppress the features of the RSA algorithm which can,
if desired by policy, conventionally enable a simple, minimal,
standard X.509-conforming infrastructure, in full compliance
with the Authentication Framework of X.509 at minimal
infrastructure cost, with or without conforming use of ISO-registered
signature algorithms with message recovery modes.

If the paper would also declare that the authors find
the  X.509 Authentication Framework as
originally designed, standardized and widely
deployed in both propreitary and conforming products
(e.g. Lotus Notes, PEM, S/MIME, X.400, X.500),
then this would also be a useful action enabling the
issue to be so declared by the parties for all to
authoratively use, rely upon and quote as evidence
in inevitable non-repudiation disputes - as with MISSI prioir
designs and US Govt appropriation and procurement acts
implicitely endorsing the validity of such (classically) standard
designs.

Conclusion: my own opinion is that we are here discussing,
in reality, the notion of key purpose, and the role of _open_
infrastructure elements to enforce purpose. This is a difficult
technical and policy subject, as evidenced by the ISO group doing
X.509, and not one to be arbitarily decided
by whim, or vendor marketing or positioning.

Denis Pinkas wrote:

> Dear folks,
>
> Placing my two cents in the balance, so that it goes on the right side
>
> :-) I would simply say that having two keys within the same
> certificate
> is not appropriate and should not be supported by the PKIX series of
> documents.
>
> Denis
>
> --
>
>       Denis Pinkas     Bull S.A.         E-mail :
> [email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "MCP 43a1, J Alyson" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Mon, 28 Jul 1997 13:41:42 -0000

help ietf-pkix

************************************************************************
*************************
John Hughes
SOS-TDP project.
[email-masked]
(UK) 0117 91 33178
************************************************************************
*************************

From: "MCP 43a1, J Alyson" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
CC: "'John Hughes (TIS)'" <[email-masked]>
Subject: PKIX presentation
Date: Mon, 28 Jul 1997 12:55:11 -0000

As part of the next phase of the SOS-TDP, i.e. demo 2,  we are looking
at "intercepting"  PKIX and using it in a multi vendor PKI environment.

As part of understanding PKIX and to gain an appreciation of PKIX
"profiles" necessary for multi-vendor inter-operability a slide set
describing various elements of PKIX has been produced.  The slides can
be found at 

	http://sostdp.mod.uk/transfers/pkix_v7.ppt

The slide set is not completely finished - in particular we would like
to add notes to each page.  If you have comments on the slides and/or
suggestions for improvement we would appreciate feed back.   If you have
any please e-mail me at my MOD or TIS e-mail addresses.

Enjoy (or not)

John
************************************************************************
*************************
John Hughes
SOS-TDP project.
[email-masked]
(UK) 0117 91 33178
************************************************************************
*************************

Date: Mon, 28 Jul 1997 10:22:06 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Fillingham, David W." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Combo DSS/ElGamal keys

Dear folks,

Placing my two cents in the balance, so that it goes on the right side 
:-) I would simply say that having two keys within the same certificate
is not appropriate and should not be supported by the PKIX series of
documents.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Fillingham,  David W." <[email-masked]>
To: Douglas Stell-P27604 <[email-masked]>, Peter Williams <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Combo DSS/ElGamal keys
Date: Sun, 27 Jul 97 15:03:00 EDT
Encoding: 220 TEXT

Peter:

I can't see where the supposed MISSI shortcomings in non-repudiation and 
dispute resolution have anything to do with the notion of putting a key 
management and signature key in a single certificate.  If anything, putting 
a signature and key management key in a single certificate creates policy 
complexities that will weaken the signatures associated with the signature 
public key in the certificate.  Compromise of the Diffie-Hellman key, for 
example, requires the certificate containing the signature key to be revoked 
as well, increasing the likelihood of unwanted rejection of otherwise valid 
signatures.  Key management and signature certificates would normally have 
different validity periods.

I believe Douglas is simply trying to warn the community that MISSI has in 
the past taken the route of the "jumbo" or "combined" key 
management/signature certificate.  We're moving away from this concept, and 
not looking back.  Contrary to the opinions expressed in your message, 
(legal) non-repudiation of message origination and receipt have always been 
MISSI requirements, and multi-level protection is much less a MISSI 
design-driver than in the past.  We do intend to interoperate with the 
commercial sector, which means we have to wrestle with the same legal issues 
(non-repudiation, archival, liability, etc.) as the rest of the community. 
 While the commercial community has long been concerned with 
non-repudiation, as you indicate, I'm not convinced you commerically-driven 
folks have got all the answers nailed down either.  Certainly, I do not 
currently see how "dual-key" certificates contribute to solving the 
non-repudiation problem.

Dave Filllingham
 ----------
From: Peter Williams
To: Douglas Stell-P27604
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: Combo DSS/ElGamal keys
Date: Wednesday, July 23, 1997 10:41AM

I tried hard not to argue in my orignal mail, as Im familiar with all
these old arguments.
Part of the shift which MISSI has yet to address, which commercial
certificate
management has begun to solidy addressed, concerns the notion of
validity for
certs, and for security mechanisms such as digital signatures, when
offered
as adequate basis for a public signatures process on commercial
documents, transactions,
notices etc and other forms of potential recorded evidence during
dispute handling.

A solemn-signature is valid once made, given a valid
and operational certificate. (These legalistic notions do not even seem
to
exist in MISSI policy concepts, not being commercially driven). Should
a certificate be suspended or revoked, this does not affect
the validity of the signature made which would historically
quote the certificate. Period (under ABA style governing
terms for certificate policies). There is some vulnerability
due to compromise (of course) and this relying parties
must bear ,and CAs and other shall guarantee so as to manage
the residual risks, as with conventional signatures and frauds
due to impersonation. Again such notions do not
exist in MISSI world with multi-level control objectives , not legal
objectives.

 Douglas Stell-P27604 wrote:

> >To force every STS-like terminal to validate 2 chains of
> >cert controls, and revocation status, whereas one will do, and
> >no vulnerabilities in conforming systems are introduced by enabling
> >double-key key distribution via a single certificate
> >mechanism, seems an unreasonable engineering assumption.
>
> This is a little close to a red herring argument. One seldom has need
> to
> validate the signature and encryption certificates of the same
> subject.

Here we all need to get legally minded, and differentiate beween use and
reliance - two
aspects of validation procedures. A party cannot accept and act on a
signature
as a solemn binding act unless s/he "relies upon" it, and its supporting
instruments for
authentication.  A signature, and validation act which is less rigorous
is of
course possible, and is known as "use" of the various data;
unfortunately the
signing act does not make the signature binding when validated. Such
object is
usually the intent of bothering to validate solemn-signatures to
contract and other
law holds. This is what I picked up from the Baum and Ford book ,
anyway!

Of course, solemn signature are present not only on the contract
document, but
also on the certificates, and CRLs. One cannot rely upon a signature
without
validating the supporting certificate, which one cannot rely upon
without
verifying its digital signature, which one...

Of course, these solemn signature rules are a little paranoid, and do
not
naturally fit with the classical sort of regimes where
authetication-only signatures are
used to protect a key-agreement algorithm (versus sign a contract). Yet,

the signature even on these certificates (your DH keys for example) may
be
expected by users to be reliable in this paranoid sense if their
privacy is at stake, and the certs are expected to exist and be issued
in order
to induce reliance on the mechanism to ensure company-sensitive data is
not disclosed to unauthorized recipients, say ( a "secret" signed
contract)

One can be sure that if a DH cert is issued, and causes loss of
confidentiality
due to compromise visible when detemrining the status of a
certificate, the signature on the certificate and its issuing process
will be held to reliability criteria in the courts, when considering a
claim.

Again such issues are unlikely to have been discussed in a MISSI forum
planning for a private military network in which governing military  law

idemnifies everyone against failures ,assuming good faith and
best-effort
manufacturing. The law in the real world of suit-ready commerce is
however
a little different, and the policies for issuance need to understand
these facts
when transferring technology from military to commercial use.

I find (not suprisingly) my argument stands (for the commercial
enviornment). **MISSI
in its simpler versions knew of no purely technical or crypto
vulnerability caused by the
designs we are here discussing, and this represents a techncial data
point usable in court
as valid design**.  Policy options are of course a function
of understanding the environments in which the four parties are
operating (CA, creator, verifier, judge). I dont know, but Im sure
Warwick
was tailoring his comments to the environment at risk, and tailors
his comments to other enviornments with a legal axis more in CPS/ABA
terms
than military messaging design terms.

>

>
> >> do you really want all your signatures to become invalid simply
> because
> >> your key-transfer key was compromised (or, worse yet, was only
> >> *suspected* to have been compromised)?

Such FUD is really quite damaging; though your signing authority is
revoked
to create NEW solemn signatures, previously created solemn signature are
NOT affected
by a suspension or revocation act, under ABA policy regimes.  You are
obliged to
ensure you revoke your certificate ASAP, just as relying parties are
obligated
to check revocation status, before acting to induce or perform a
reliance.

Conclusion.

"One seldom has need to
validate the signature and encryption certificates of the same subject.
"

I suggest in the world of lawyers, which most of are subject to, you
have a need to
act reasonably to check the instruments you rely upon each and every
time you use
them particularly when they are known to have dynamic reliability
status. Whilst no
harm is necesarily done if you fail such a standard, you may find you
have little basis for
claming the other party did you damage which you had the means to limit
if
you had only taken care to re-validate the certs all the way up the
chain
EACH  time you were likely to suffer a potential and significant loss of
message
integrity and  authenticity, or loss of privacy of proprietary data
confidentiality.

Doug - I used to think as you are clasically thinking about private
networks
or regulated public networks bound by subscriber agreements or legal
indemnities.
Then I met comon law lawyers and their 400 years of  case law in public
signatures,
frauds, risk of loss and common duties/obligation!

 http://www.news.com/News/Item/0,4,12716,00.html?owv

                "By Howard Hill
                July 23, 1997, 7:30 a.m. PT

                About 180 lawyers meeting in San Francisco earlier
                this week to discuss evolving legal ramifications of
                the Internet concluded that cyberspace was virtually
                no different from "terra firma" when it comes to the
                applicability of the law."

I cannot wait to look back in 10 years time and see what actually
happened
to one of the principle institutions (signatures) of society when
embracing
crypto!

Date: Thu, 24 Jul 1997 16:26:17 -0500
From: Chris Harman-P28518 <[email-masked]@[160.12.2.1]@austx.tandem.com>
Subject: RE: Combo DSS/ElGamal keys
To: [email-masked], [email-masked]
Cc: [email-masked]

As I used to work PGP, let me clarify a little.  In PGP 5.0, only the   
signature key is independently certified.  The key management key is   
signed by (and only by) its matching signature key.  This way, the key   
owner can theoretically replace key management keys at will.  There isn't   
much motivation for someone to sign someone else's public key management   
key, so independent certification and proof of possession checks are   
really not needed.

Simply bundling both keys together in the same X.509 cert obviously would   
not have the same effect.  The format of the cert would need to be   
changed (with the CA sig would not covering the entire cert), or a new   
format (e.g. a Key Management Key Certificate) could be defined.

One problem is that a CA could not enforce backup of key management keys   
as a prerequisite to certification.  Revocation is another issue (the CA   
could revoke the master signing key, but that seems a little drastic).

Regards,
Chris Harman

 -----Original Message-----
From: [email-masked]
Sent: Thursday, July 24, 1997 4:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Combo DSS/ElGamal keys

Let me second David's comments.  The notion of puitting both a key
management and a signature key into the same cert is a tempting hack, to
minimize cert overhead.  However, it has its downsides, irrespective of   
the
standards situation.  Specifically, one might well wish to change key
management keys more frequently than signature keys, and by binding both
together in the same cert this issue is muddied.

Steve

Date: Thu, 24 Jul 1997 12:28:12 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: RE: Combo DSS/ElGamal keys

>If the DH public value is in a
>*certificate*, why would another public value (in this case a DSS value)
>_in_the_same_certificate_ be useful for authenticating the DH exchange?
>
>In other words, if you trust the certificate to tie the DSS public value
>to an entity, why can you not trust the certificate to tie the DH public
>value to an entity?  What further authentication assurance does the DSS
>key (in the same certificate as the DH value) have?
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------

The DH public value, might be the approved corporate key (used in message recovery) and in the same cert (in order to save time, money and administrative hassle), is your private DSS 'signing' public key for recipient to validate your sig on a document that was encrypted (and maybe readable by your company).

With one cert having two public keys (very different purposes) is preferable to eliminate the need for further authentication.

cb

Date: Thu, 24 Jul 1997 15:23:10 -0400
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Combo DSS/ElGamal keys
Cc: [email-masked]

Let me second David's comments.  The notion of puitting both a key
management and a signature key into the same cert is a tempting hack, to
minimize cert overhead.  However, it has its downsides, irrespective of the
standards situation.  Specifically, one might well wish to change key
management keys more frequently than signature keys, and by binding both
together in the same cert this issue is muddied.

Steve

From: Carlisle Adams <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Douglas Stell-P27604'" <"[email-masked]@[160.12.2.1]"@austx.tandem.com>
Subject: RE: Combo DSS/ElGamal keys
Date: Thu, 24 Jul 1997 14:03:55 -0400

Peter,

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	Wednesday, July 23, 1997 11:01 AM
>To: 	Douglas Stell-P27604
>Cc: 	Carlisle Adams; [email-masked]; [email-masked];
>[email-masked]
>Subject: 	Re: Combo DSS/ElGamal keys
>
>"I agree that it would be useful and appropriate to define a
>"DH-with-DSS" key exchange algorithm OID with all necessary values
>(2 public keys and optional public parameters) included in the
>parameter block.  As long as it is clear that the DSS key is not to be
>used for any purpose other than authenticating the DH exchange, this,
>as Charles points out, would not really count as a multiple-key
>certificate.

Maybe I haven't seen the full details of this proposal, but what you've
written here doesn't make sense to me.  If the DH public value is in a
*certificate*, why would another public value (in this case a DSS value)
_in_the_same_certificate_ be useful for authenticating the DH exchange?

In other words, if you trust the certificate to tie the DSS public value
to an entity, why can you not trust the certificate to tie the DH public
value to an entity?  What further authentication assurance does the DSS
key (in the same certificate as the DH value) have?

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Wed, 23 Jul 1997 15:41:37 +0100
From: Peter Williams <[email-masked]>
To: Douglas Stell-P27604 <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Combo DSS/ElGamal keys

I tried hard not to argue in my orignal mail, as Im familiar with all
these old arguments.
Part of the shift which MISSI has yet to address, which commercial
certificate
management has begun to solidy addressed, concerns the notion of
validity for
certs, and for security mechanisms such as digital signatures, when
offered
as adequate basis for a public signatures process on commercial
documents, transactions,
notices etc and other forms of potential recorded evidence during
dispute handling.

A solemn-signature is valid once made, given a valid
and operational certificate. (These legalistic notions do not even seem
to
exist in MISSI policy concepts, not being commercially driven). Should
a certificate be suspended or revoked, this does not affect
the validity of the signature made which would historically
quote the certificate. Period (under ABA style governing
terms for certificate policies). There is some vulnerability
due to compromise (of course) and this relying parties
must bear ,and CAs and other shall guarantee so as to manage
the residual risks, as with conventional signatures and frauds
due to impersonation. Again such notions do not
exist in MISSI world with multi-level control objectives , not legal
objectives.

 Douglas Stell-P27604 wrote:

> >To force every STS-like terminal to validate 2 chains of
> >cert controls, and revocation status, whereas one will do, and
> >no vulnerabilities in conforming systems are introduced by enabling
> >double-key key distribution via a single certificate
> >mechanism, seems an unreasonable engineering assumption.
>
> This is a little close to a red herring argument. One seldom has need
> to
> validate the signature and encryption certificates of the same
> subject.

Here we all need to get legally minded, and differentiate beween use and
reliance - two
aspects of validation procedures. A party cannot accept and act on a
signature
as a solemn binding act unless s/he "relies upon" it, and its supporting
instruments for
authentication.  A signature, and validation act which is less rigorous
is of
course possible, and is known as "use" of the various data;
unfortunately the
signing act does not make the signature binding when validated. Such
object is
usually the intent of bothering to validate solemn-signatures to
contract and other
law holds. This is what I picked up from the Baum and Ford book ,
anyway!

Of course, solemn signature are present not only on the contract
document, but
also on the certificates, and CRLs. One cannot rely upon a signature
without
validating the supporting certificate, which one cannot rely upon
without
verifying its digital signature, which one...

Of course, these solemn signature rules are a little paranoid, and do
not
naturally fit with the classical sort of regimes where
authetication-only signatures are
used to protect a key-agreement algorithm (versus sign a contract). Yet,

the signature even on these certificates (your DH keys for example) may
be
expected by users to be reliable in this paranoid sense if their
privacy is at stake, and the certs are expected to exist and be issued
in order
to induce reliance on the mechanism to ensure company-sensitive data is
not disclosed to unauthorized recipients, say ( a "secret" signed
contract)

One can be sure that if a DH cert is issued, and causes loss of
confidentiality
due to compromise visible when detemrining the status of a
certificate, the signature on the certificate and its issuing process
will be held to reliability criteria in the courts, when considering a
claim.

Again such issues are unlikely to have been discussed in a MISSI forum
planning for a private military network in which governing military  law

idemnifies everyone against failures ,assuming good faith and
best-effort
manufacturing. The law in the real world of suit-ready commerce is
however
a little different, and the policies for issuance need to understand
these facts
when transferring technology from military to commercial use.

I find (not suprisingly) my argument stands (for the commercial
enviornment). **MISSI
in its simpler versions knew of no purely technical or crypto
vulnerability caused by the
designs we are here discussing, and this represents a techncial data
point usable in court
as valid design**.  Policy options are of course a function
of understanding the environments in which the four parties are
operating (CA, creator, verifier, judge). I dont know, but Im sure
Warwick
was tailoring his comments to the environment at risk, and tailors
his comments to other enviornments with a legal axis more in CPS/ABA
terms
than military messaging design terms.

>

>
> >> do you really want all your signatures to become invalid simply
> because
> >> your key-transfer key was compromised (or, worse yet, was only
> >> *suspected* to have been compromised)?

Such FUD is really quite damaging; though your signing authority is
revoked
to create NEW solemn signatures, previously created solemn signature are
NOT affected
by a suspension or revocation act, under ABA policy regimes.  You are
obliged to
ensure you revoke your certificate ASAP, just as relying parties are
obligated
to check revocation status, before acting to induce or perform a
reliance.

Conclusion.

"One seldom has need to
validate the signature and encryption certificates of the same subject.
"

I suggest in the world of lawyers, which most of are subject to, you
have a need to
act reasonably to check the instruments you rely upon each and every
time you use
them particularly when they are known to have dynamic reliability
status. Whilst no
harm is necesarily done if you fail such a standard, you may find you
have little basis for
claming the other party did you damage which you had the means to limit
if
you had only taken care to re-validate the certs all the way up the
chain
EACH  time you were likely to suffer a potential and significant loss of
message
integrity and  authenticity, or loss of privacy of proprietary data
confidentiality.

Doug - I used to think as you are clasically thinking about private
networks
or regulated public networks bound by subscriber agreements or legal
indemnities.
Then I met comon law lawyers and their 400 years of  case law in public
signatures,
frauds, risk of loss and common duties/obligation!

 http://www.news.com/News/Item/0,4,12716,00.html?owv

                "By Howard Hill
                July 23, 1997, 7:30 a.m. PT

                About 180 lawyers meeting in San Francisco earlier
                this week to discuss evolving legal ramifications of
                the Internet concluded that cyberspace was virtually
                no different from "terra firma" when it comes to the
                applicability of the law."

I cannot wait to look back in 10 years time and see what actually
happened
to one of the principle institutions (signatures) of society when
embracing
crypto!

Date: Wed, 23 Jul 1997 16:01:51 +0100
From: Peter Williams <[email-masked]>
To: Douglas Stell-P27604 <"[email-masked]@[160.12.2.1]"@austx.tandem.com>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Combo DSS/ElGamal keys

Douglas Stell-P27604 wrote:

>
>
> Even if both certificates of a subject need to be validated they would
> be
> issued by the CA and the application would not have to validate 2
> chains of
> certificates or CRLs. Seperate certificates then requires validating
> only
> one additional certificate and looking for it in the CA's CRL.

When I used the term STS-KA, I was attempting to give a moniker for
the "store-and-forward key agreement mechanism" used in MSP,
and PGP based on DSS+DH. I was really not trying to imply
STS interactive protocol and its notions for access control to a
connection; I
was  trying to take David Kemps notion that there is an atomic ISO
security
mechanism and algoirhtm conceivable for key agreement which does
(DSS+DH) ,and
this could be given an oid and recognised as such in a store and forward
or
connectionless environment, such as PGP. Such a mechanism could be
similarly used by
S/MIME, while RSA signing or counter-signing say with certs from
a different CA to that managing confidentiality and key escrow, for
example.

"I agree that it would be useful and appropriate to define a
"DH-with-DSS" key exchange algorithm OID with all necessary values
(2 public keys and optional public parameters) included in the
parameter block.  As long as it is clear that the DSS key is not to be
used for any purpose other than authenticating the DH exchange, this,
as Charles points out, would not really count as a multiple-key
certificate.  The logical next step is for someone to write up some
proposed text for PKIX part 1."

Sender: [email-masked]
Date: Wed, 23 Jul 1997 18:39:32 -0300
From: Rodrigo Botafogo <[email-masked]>
Organization: CertiSign Certificadora Digital Ltda.
To: [email-masked]
Subject: subscribe

subscribe [email-masked] ietf-pkix

Date: Wed, 23 Jul 1997 15:26:50 -0500
From: Douglas Stell-P27604 <[email-masked]@[160.12.2.1]@austx.tandem.com>
Subject: Re: Combo DSS/ElGamal keys
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]

>To force every STS-like terminal to validate 2 chains of
>cert controls, and revocation status, whereas one will do, and
>no vulnerabilities in conforming systems are introduced by enabling
>double-key key distribution via a single certificate
>mechanism, seems an unreasonable engineering assumption.

This is a little close to a red herring argument. One seldom has need to 
validate the signature and encryption certificates of the same subject. The 
recipient usually validates the signer's signature certificate for 
authentication and possibly his own encryption certificate for inbound 
access control, if access control is an issue. The originator usually 
validates the recipient's and possibly his own encryption certificate for 
outbound access control.

Even if both certificates of a subject need to be validated they would be 
issued by the CA and the application would not have to validate 2 chains of 
certificates or CRLs. Seperate certificates then requires validating only 
one additional certificate and looking for it in the CA's CRL.

>This practice is already documented in MISSI-based Fortezza and MSP
>[3.0] certificate-concept design documents where the "signing DSA key"
>from a MISSI [V1] cert is used for solemn signing acts by real humans,
>whereas a multi-purpose single public value (potentially and likely
>to be escrowed by DoD CA software) is available for use for KEA
>key agreement for confidentiality service establishment and, in such
>as SSL enviornments  a Fortezza-based *signed*-challenge response
>handshake for various classes of anonymous and accountable shared
>secret and data origin authentication service establisment

MISSI is abandoning this the two-key certificate. So, I wouldn't hold this 
up as a model to follow. MISSI is going to separate certificates as it 
transitions to Version 3 certificates and MSP 4.0. The reasons are the same 
ones stated earlier in this thread and repeated below, most notably proper 
revocation. (MISSI V1 certs have a single key identifier for both encryption 
and signature keys. Well, actually, they didn't foresee the need to revoke 
signature keys.)

>> It is not generally a good idea to have two public keys in the same
>> certificate, even if it appears that it might be useful in some
>> circumstances.  This is especially true for signature keys and
>> encryption/key-transfer keys, since these are likely to have quite
>> different life cycle characteristics.  Typically, for example, you will
>> want the validity periods to be different (perhaps significantly so).
>> Furthermore, the whole area of revocation becomes much more painful
>> do you really want all your signatures to become invalid simply because
>> your key-transfer key was compromised (or, worse yet, was only
>> *suspected* to have been compromised)?

This is good advice and Warwick strongly advised the MISSI working group to 
abandon the two-key model and go with separate certificates with standard 
subjectPublicKeyInfo fields. Being heavily involved in that working group 
and its revocation, renewal, rekey and operatonial aspects, I can attest 
that this is good advice. Do what MISSI and everyone else is doing, not what 
MISSI did.

doug stell

Date: Wed, 23 Jul 1997 11:42:16 +0100
From: Peter Williams <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: "'ietf-pkix'" <[email-masked]>, "'Charles Breed'" <[email-masked]>, "'Dan Laska'" <[email-masked]>
Subject: Re: Combo DSS/ElGamal keys

I have to disagree, though Im sympathetic to your argument
on conventional reasoning grounds.

I find that it is hard to justify that all mechanisms should be
restricted to
a single key design, when  all information necessary
to invoke that mechanism is available from a single certificate
validation act.

If one invents the STS-KA mechanism (which happens
to use double-key-based countermeasures), and assuming
the local systems have the security context implementations
which recognise such mechanism's signal,  is  there
rationale basis for believing that the keys will be improperly
reused for other non-designated purposes, if a conforming PKIX systems
is in use, and the relevant constraints are set
in the control extensions?

To force every STS-like terminal to validate 2 chains of
cert controls, and revocation status, whereas one will do, and
no vulnerabilities in conforming systems are introduced by enabling
double-key key distribution via a single certificate
mechanism, seems an unreasonable engineering assumption.

This practice is already documented in MISSI-based Fortezza
and MSP certificate-concept design documents where the "signing DSA key"

from a MISSI cert is used for solemn signing acts by real humans,
whereas a
multi-purpose single public value (potentially and likely
to be escrowed by DoD CA software) is available for use for KEA
key agreement for confidentiality service establishment and, in such
as SSL enviornments  a Fortezza-based *signed*-challenge response
handshake for various classes of anonymous and accountable shared
secret and data origin authentication service establisment

NB the difference between regimes
(a) solemn-signing + (single-key Key Agreement)
(b) solemn-signing + (dual-key Key Agreement)
(c) no-solemn-signing-capability + (dual-key Key Agreement)

--------

To embrace the PGP community practically, why not simple assign an oid
for the existing PGP DSS/ElGamal certificate format, and allow
PKIX complying system components to wrap X.509 controls around that
format
whose value is placed in, and removed from, the subjectPublicKey "as
is".

This would allow PGP software to use its http link to point to
an PKCS7 certs-only file (thereby sharing infrastructure with
the major SSL browsers and S/MIME), and use such chain to introduce
the party's embedded  keying material already in PGP formats
to the local key ring. This could well be addon software,
versus a change to deployed PGP.

It may be more valid here to embrace communities to
create a joint PKI, than be too religious about X.509
mechanisms and models.

Carlisle Adams wrote:

> Hello,
>
> >----------
> >From:  Dan Laska[SMTP:[email-masked]]
> >Sent:  Tuesday, July 22, 1997 10:38 AM
> >To:    ietf-pkix; Charles Breed
> >Subject:       Re: Combo DSS/ElGamal keys
> >
> >I agree that it would be useful for PKIX to address how DH and DSS
> keys
> >can be included in a single certificate (and perhaps also in a single
>
> >certificate request) in a standard way.  It makes sense to allow the
> two
> >public values to be in the same certificate, because DH and DSS keys
> are
> >often required by the same application.
>
> It is not generally a good idea to have two public keys in the same
> certificate, even if it appears that it might be useful in some
> circumstances.  This is especially true for signature keys and
> encryption/key-transfer keys, since these are likely to have quite
> different life cycle characteristics.  Typically, for example, you
> will
> want the validity periods to be different (perhaps significantly so).
> Furthermore, the whole area of revocation becomes much more painful
> --
> do you really want all your signatures to become invalid simply
> because
> your key-transfer key was compromised (or, worse yet, was only
> *suspected* to have been compromised)?
>
> The chances are very good that people will have multiple certificates
> for multiple purposes anyway (e.g., for the multiple roles or
> "personalities" they adopt during a normal day), so trying to combine
> signature and encryption/key-transfer keys into a single certificate
> for
> the purpose of cutting down the number of certificates is not likely
> to
> buy you very much.
>
> >A typical customer using Frontier's e-Lock product with DH/DSS must
> now
> >generate two requests and maintain two certificates. The DH and DSS
> >requests are created at the same time, using the same subject name,
> and
> >sent to the same CA. It would be convenient to allow both keys to be
> in
> >the same request and certificate, if this could be done in a
> PKIX-standard
> >way.
>
> PKIX Part 3 already addresses this.  You can request any number of
> certificates with a single request message (this is why the request is
> a
> SEQUENCE OF FullCertTemplate).  Furthermore, the multiple certificates
>
> come back in a single response message.  What could possibly be
> easier?
> :-)
>
> >----------
> >> From: Charles Breed <[email-masked]>
> >> To: [email-masked]
> >> Subject: Re: Combo DSS/ElGamal keys
> >> Date: Monday, July 21, 1997 1:14 PM
> >>
> >>
> >> We *really* should have an answer to this within PKIX. The term
> >'multiple-keys" is a bit misleading, because you'll always encrypt a
> >session key with only one user's Public Key, (the signing key would
> map
> >elsewhere).
>
> Agreed, but on the other hand, "multiple keys" is not misleading at
> all,
> since the proposal is to map two keys with very different purposes
> into
> the same structure...
>
> >> Our commercial (X.509) customers like the DH (ElGamal)/DSS combo
> for a
> >verity of reasons (like flexibility for users to own a signing-key
> while
> >using Corp pub-key with message recovery), AND since the IETF fronds
> upon
> >use of "encumbered" algorithms, we should have an agreed upon scheme
> for
> >mapping DH/DSS into PKIX's use of X.509v3
>
> There is an agree-upon scheme for mapping DH/DSS into PKIX's use of
> X.509v3; it's just that the two keys are mapped into two certificates.
>
> :-)
>
> >> >MISSI has that "neat trick" too, for encoding DSS keys, KEA (key
> exchange)
> >> >keys, and privilege bits into a single X.509 version 1
> certificate.
> >> >
> >> >Even in version 1, which did not restrict what could go into the
> >> >subjectPublicKeyInfo field, MISSI "jumbo certificates" were a hack
> to
> >> >get around the fact that v1 did not have anywhere else to put that
>
> >> >information.  During the evolution of v3, the topic was debated,
> and
> >> >consensus was reached that certificates must contain only a single
>
> >> >public key.
> >> >
> >> >Private profiles (such as one defining PGP's use of X.509) could
> >> >be used to define OIDs for multiple key certificates, but they
> won't
> >> >be part of the PKIX profile because multiple keys have been judged
> to
> >> >cause more problems than they solve.
>
> I certainly agree with David here.  Multiple keys in a single
> certificate will be problematic for the user as time goes on.  Much
> better to have separate certificates for separate purposes.  That way,
>
> as each one expires, or gets revoked, or needs to be updated, or
> whatever, it does not affect the continued use and validity of the
> other
> one.
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------

From: Carlisle Adams <[email-masked]>
To: "'ietf-pkix'" <[email-masked]>, "'Charles Breed'" <[email-masked]>, "'Dan Laska'" <[email-masked]>
Subject: RE: Combo DSS/ElGamal keys
Date: Wed, 23 Jul 1997 12:10:31 -0400

Hello,

>----------
>From: 	Dan Laska[SMTP:[email-masked]]
>Sent: 	Tuesday, July 22, 1997 10:38 AM
>To: 	ietf-pkix; Charles Breed
>Subject: 	Re: Combo DSS/ElGamal keys
>
>I agree that it would be useful for PKIX to address how DH and DSS keys
>can be included in a single certificate (and perhaps also in a single
>certificate request) in a standard way.  It makes sense to allow the two
>public values to be in the same certificate, because DH and DSS keys are
>often required by the same application. 

It is not generally a good idea to have two public keys in the same
certificate, even if it appears that it might be useful in some
circumstances.  This is especially true for signature keys and
encryption/key-transfer keys, since these are likely to have quite
different life cycle characteristics.  Typically, for example, you will
want the validity periods to be different (perhaps significantly so).
Furthermore, the whole area of revocation becomes much more painful  --
do you really want all your signatures to become invalid simply because
your key-transfer key was compromised (or, worse yet, was only
*suspected* to have been compromised)?

The chances are very good that people will have multiple certificates
for multiple purposes anyway (e.g., for the multiple roles or
"personalities" they adopt during a normal day), so trying to combine
signature and encryption/key-transfer keys into a single certificate for
the purpose of cutting down the number of certificates is not likely to
buy you very much.

>A typical customer using Frontier's e-Lock product with DH/DSS must now
>generate two requests and maintain two certificates. The DH and DSS
>requests are created at the same time, using the same subject name, and
>sent to the same CA. It would be convenient to allow both keys to be in
>the same request and certificate, if this could be done in a PKIX-standard
>way.

PKIX Part 3 already addresses this.  You can request any number of
certificates with a single request message (this is why the request is a
SEQUENCE OF FullCertTemplate).  Furthermore, the multiple certificates
come back in a single response message.  What could possibly be easier?
:-)

>----------
>> From: Charles Breed <[email-masked]>
>> To: [email-masked]
>> Subject: Re: Combo DSS/ElGamal keys
>> Date: Monday, July 21, 1997 1:14 PM
>> 
>> 
>> We *really* should have an answer to this within PKIX. The term
>'multiple-keys" is a bit misleading, because you'll always encrypt a
>session key with only one user's Public Key, (the signing key would map
>elsewhere).

Agreed, but on the other hand, "multiple keys" is not misleading at all,
since the proposal is to map two keys with very different purposes into
the same structure...

>> Our commercial (X.509) customers like the DH (ElGamal)/DSS combo for a
>verity of reasons (like flexibility for users to own a signing-key while
>using Corp pub-key with message recovery), AND since the IETF fronds upon
>use of "encumbered" algorithms, we should have an agreed upon scheme for
>mapping DH/DSS into PKIX's use of X.509v3

There is an agree-upon scheme for mapping DH/DSS into PKIX's use of
X.509v3; it's just that the two keys are mapped into two certificates.
:-)

>> >MISSI has that "neat trick" too, for encoding DSS keys, KEA (key exchange)
>> >keys, and privilege bits into a single X.509 version 1 certificate.
>> >
>> >Even in version 1, which did not restrict what could go into the
>> >subjectPublicKeyInfo field, MISSI "jumbo certificates" were a hack to
>> >get around the fact that v1 did not have anywhere else to put that
>> >information.  During the evolution of v3, the topic was debated, and
>> >consensus was reached that certificates must contain only a single
>> >public key.
>> >
>> >Private profiles (such as one defining PGP's use of X.509) could
>> >be used to define OIDs for multiple key certificates, but they won't
>> >be part of the PKIX profile because multiple keys have been judged to
>> >cause more problems than they solve.

I certainly agree with David here.  Multiple keys in a single
certificate will be problematic for the user as time goes on.  Much
better to have separate certificates for separate purposes.  That way,
as each one expires, or gets revoked, or needs to be updated, or
whatever, it does not affect the continued use and validity of the other
one.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date: Wed, 23 Jul 1997 10:56:41 -0400
From: "Dulude, Bob" <[email-masked]>
Subject: Cross Certification
To: "[email-masked]'" <[email-masked]>

Can anyone point me to a good primer on cross certification?  I am
trying to answer questions such as why it is needed, how it will be
used, status of cross certification standards, and descriptions of
approaches being considered or currently implemented.
Thanks

Bob
---------------------
Bob Dulude             
GTE CyberTrust                                  (617)-455-2623     
77 "A" Street                                      (617)-455-3105  [FAX]
Needham, MA  02194-2892               [email-masked]
please visit: http://www.cybertrust.gte.com   

Date: Tue, 22 Jul 1997 16:21:05 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Combo DSS/ElGamal keys

> From: "Dan Laska" <[email-masked]>
> 
> I agree that it would be useful for PKIX to address how DH and DSS keys
> can be included in a single certificate (and perhaps also in a single
> certificate request) in a standard way.  It makes sense to allow the two
> public values to be in the same certificate, because DH and DSS keys are
> often required by the same application. 

I agree that it would be useful and appropriate to define a
"DH-with-DSS" key exchange algorithm OID with all necessary values
(2 public keys and optional public parameters) included in the
parameter block.  As long as it is clear that the DSS key is not to be
used for any purpose other than authenticating the DH exchange, this,
as Charles points out, would not really count as a multiple-key
certificate.  The logical next step is for someone to write up some
proposed text for PKIX part 1.

But for DSS keys used to sign user data (the message body), a separate
certificate (with a different DSS key) would still be needed.  This is
analogous to the RSA case, where one certificate contains an RSA
key-transport key and another contains an RSA signature key.

Date: Tue, 22 Jul 1997 19:07:56 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: Charles Breed <[email-masked]>
cc: [email-masked]
Subject: Re: Combo DSS/ElGamal keys

Hiya

I'm prepared to make a proposal unless someone else has an existing
document.  I think it's important to note that this would not be a generic
(key-exchange+signature) model, it would be a specific description of the
formatting of a DSS+DH SPKI.

Let's not get into a PGP vs X.509 um, debate ;-)

--
Mark Shuttleworth
Thawte Consulting

From: "Dan Laska" <[email-masked]>
To: <[email-masked]>, "Charles Breed" <[email-masked]>
Subject: Re: Combo DSS/ElGamal keys
Date: Tue, 22 Jul 1997 09:38:14 -0500

I agree that it would be useful for PKIX to address how DH and DSS keys
can be included in a single certificate (and perhaps also in a single
certificate request) in a standard way.  It makes sense to allow the two
public values to be in the same certificate, because DH and DSS keys are
often required by the same application. 

A typical customer using Frontier's e-Lock product with DH/DSS must now
generate two requests and maintain two certificates. The DH and DSS
requests are created at the same time, using the same subject name, and
sent to the same CA. It would be convenient to allow both keys to be in
the same request and certificate, if this could be done in a PKIX-standard
way.

- Dan

=====================
Dan Laska
Frontier Technologies Corp. - Engineering
Email: [email-masked]
Voice: (608) 231-0038
Fax:   (608) 231-0338
=====================

----------
> From: Charles Breed <[email-masked]>
> To: [email-masked]
> Subject: Re: Combo DSS/ElGamal keys
> Date: Monday, July 21, 1997 1:14 PM
> 
> 
> We *really* should have an answer to this within PKIX. The term
'multiple-keys" is a bit misleading, because you'll always encrypt a
session key with only one user's Public Key, (the signing key would map
elsewhere).
> 
> Our commercial (X.509) customers like the DH (ElGamal)/DSS combo for a
verity of reasons (like flexibility for users to own a signing-key while
using Corp pub-key with message recovery), AND since the IETF fronds upon
use of "encumbered" algorithms, we should have an agreed upon scheme for
mapping DH/DSS into PKIX's use of X.509v3
> 
> 
> At 09:29 AM 7/21/97 -0400, David P. Kemp wrote:
> >> From: Mark Shuttleworth <[email-masked]>
> >> 
> >> Hi folk
> >> 
> >> PGP 5.0 has a neat trick (*ugly* implementation) that combines a DSS
key
> >> for signatures with an ElGamal/DH thing for encryption/keyexchange. 
Is
> >> there a profile to map such a beast into an X.509 certificate?  OID's
and
> >> parameters, etc.
> >
> >
> >MISSI has that "neat trick" too, for encoding DSS keys, KEA (key
exchange)
> >keys, and privilege bits into a single X.509 version 1 certificate.
> >
> >Even in version 1, which did not restrict what could go into the
> >subjectPublicKeyInfo field, MISSI "jumbo certificates" were a hack to
> >get around the fact that v1 did not have anywhere else to put that
> >information.  During the evolution of v3, the topic was debated, and
> >consensus was reached that certificates must contain only a single
> >public key.
> >
> >Private profiles (such as one defining PGP's use of X.509) could
> >be used to define OIDs for multiple key certificates, but they won't
> >be part of the PKIX profile because multiple keys have been judged to
> >cause more problems than they solve.
> >
> >Personal opinion: I'm on the fence as to which approach is "best".
> >But the worst solution would be to require applications to support
> >both schemes, so one had to be picked.  If interoperability with the
> >rest of the X.509 world is the goal, don't use multiple-key certs.
> >
> >

Date: Mon, 21 Jul 1997 14:04:41 +0100
From: Peter Williams <[email-masked]>
To: Robert Jueneman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Cross Certification and Certificate Path Processing

I think we have just all agreed with one another toallow  implementation
of the
intelligent end of X.509 1988!. Put local verification controls into a
new
local-cert, and stick it on top of the inbound chain from one of the n
recognised
authentication domains, then pass  the locallly-extended chain to the
std algorithm
for enforcement.

Obviously one can implement the same local step in a proprietary manner
also. There is also a mixed std/locallisation scheme where
private controlling extensions are encoded in the local-cross-cert, for
local consumption only by a *local* value-added enforcement module.

E.g. remote inbound chain  "uk<Fr>. Fr<Nancy>. Nancy<Pierre>" might
be augmented by my local cert to become
Peter*<uk>  .   uk<Fr>. Fr<Nancy>. Nancy<Pierre>

where Peter* replaces all occurences of Pierre with Peter as
an expression of local language rules of an English culture worried
about French language invasion..

Ok the example of local control is silly (mostly, anyway), but I think
we now all agree.

Nothing in PKIX rule set should interfere with such behaviour. If the
local
security module wishes to add a chain of 6 certs on the front, it can
so do, and they can intersect the inbound chain at any point. This
is just standard X.509 chain preparation handling, exploiting
local knowlege, and.enforcing local policy.

PKIX might wish to encourage such a mechanism, rather than
encourage enforcement modules to access local databases for the same
rules in a proprietary manner.. The consumer of the std X.509
enforcement
module ,rather, should be encouraged to construct the local-cert, based
on the current dynamic database value, and thus preserve functional
separation and independence of std vs proprietary mechanisms and
modules.

This is the whole power of the cross-cert mechanism!

Robert Jueneman wrote:

> I agree with Denis. Although the current specifications wer intneded
> to
> support the use of contraints that could be imposed on the certificate
>
> structure, and evaluated by say a trusted smart cad without reference
> to any
> external or database constrains, the use of such external constraints
> should
> not be ruled out.
>
> Having said that, a prefrred solution to his point number 2 is for the
> user
> (or his MIS department) to creat a self-signed, unpublished
> certificate
> which are used to sign on or more lower-level certificates which
> cross-link
> to whatever public (root-level) CAs are desired. The policy mapping,
> name
> constraints, etc., can all be represented using the existing V3
> mechanims,
> nd relagated to a trusted smart card if necessary for enforcement.
> Then only
> a single public key has to be trusted -- the user's own, which can
> (and
> should) be protected against modification the same way the user's
> private
> key is protected.)
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Support Division
> 122 East 1700 South
> Provo, UT 84606
> 801/861-7387
> [email-masked]
>
> >>> Denis Pinkas <[email-masked]> 07/21 11:18 AM >>>
> Peter Williams wrote:
>
> > If you are following the X.509 procedure for cert path validation
> (which
> > all conforming implementations
> > will do)  it doest make any direct impact. All signals and
> constraints
> > to guide the validation procedure
> > are inband to the cert, CA cert or cross-cert equally - and enforced
> by
> > conformant semantic handling of the
> > extensions and the algorithm.
>
> I would like to make two observations:
>
> 1) naming constraint extensions are not necessarilly present within a
> certificate. When they are present they must indeed be processed. So
> there exists at least conceptually another way to validate a
> certificate
> path: using local naming constraints.
>
> 2) When naming contraints contained within the certificates are used,
> it
> is fairly important to apply these constraints on the first leg as
> well,
> i.e. naming contraints on the CA(s) that are trusted since they are
> not
> equally trusted. This means using local constraints. An easy way to do
>
> it is to define these constraints in a self-signed certificate of the
> CA, and only use them once they are found acceptable.
>
> I would appreciate that PKIX Part 1 reflects these points.
>
> Regards,
>
> Denis
> --
>
>       Denis Pinkas     Bull S.A.         E-mail :
> [email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Date: Mon, 21 Jul 1997 11:54:20 -0600
From: Robert Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Cross Certification and Certificate Path Processing

I agree with Denis. Although the current specifications wer intneded to
support the use of contraints that could be imposed on the certificate
structure, and evaluated by say a trusted smart cad without reference to any
external or database constrains, the use of such external constraints should
not be ruled out.

Having said that, a prefrred solution to his point number 2 is for the user
(or his MIS department) to creat a self-signed, unpublished certificate
which are used to sign on or more lower-level certificates which cross-link
to whatever public (root-level) CAs are desired. The policy mapping, name
constraints, etc., can all be represented using the existing V3 mechanims,
nd relagated to a trusted smart card if necessary for enforcement. Then only
a single public key has to be trusted -- the user's own, which can (and
should) be protected against modification the same way the user's private
key is protected.)

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Support Division
122 East 1700 South
Provo, UT 84606
801/861-7387
[email-masked]

>>> Denis Pinkas <[email-masked]> 07/21 11:18 AM >>>
Peter Williams wrote:
 
> If you are following the X.509 procedure for cert path validation (which
> all conforming implementations
> will do)  it doest make any direct impact. All signals and constraints
> to guide the validation procedure
> are inband to the cert, CA cert or cross-cert equally - and enforced by
> conformant semantic handling of the
> extensions and the algorithm.

I would like to make two observations:

1) naming constraint extensions are not necessarilly present within a
certificate. When they are present they must indeed be processed. So
there exists at least conceptually another way to validate a certificate
path: using local naming constraints.

2) When naming contraints contained within the certificates are used, it
is fairly important to apply these constraints on the first leg as well,
i.e. naming contraints on the CA(s) that are trusted since they are not
equally trusted. This means using local constraints. An easy way to do
it is to define these constraints in a self-signed certificate of the
CA, and only use them once they are found acceptable.

I would appreciate that PKIX Part 1 reflects these points.

Regards,

Denis
-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked] 
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Mon, 21 Jul 1997 11:14:01 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: Combo DSS/ElGamal keys

We *really* should have an answer to this within PKIX. The term 'multiple-keys" is a bit misleading, because you'll always encrypt a session key with only one user's Public Key, (the signing key would map elsewhere).

Our commercial (X.509) customers like the DH (ElGamal)/DSS combo for a verity of reasons (like flexibility for users to own a signing-key while using Corp pub-key with message recovery), AND since the IETF fronds upon use of "encumbered" algorithms, we should have an agreed upon scheme for mapping DH/DSS into PKIX's use of X.509v3

At 09:29 AM 7/21/97 -0400, David P. Kemp wrote:
>> From: Mark Shuttleworth <[email-masked]>
>> 
>> Hi folk
>> 
>> PGP 5.0 has a neat trick (*ugly* implementation) that combines a DSS key
>> for signatures with an ElGamal/DH thing for encryption/keyexchange.  Is
>> there a profile to map such a beast into an X.509 certificate?  OID's and
>> parameters, etc.
>
>
>MISSI has that "neat trick" too, for encoding DSS keys, KEA (key exchange)
>keys, and privilege bits into a single X.509 version 1 certificate.
>
>Even in version 1, which did not restrict what could go into the
>subjectPublicKeyInfo field, MISSI "jumbo certificates" were a hack to
>get around the fact that v1 did not have anywhere else to put that
>information.  During the evolution of v3, the topic was debated, and
>consensus was reached that certificates must contain only a single
>public key.
>
>Private profiles (such as one defining PGP's use of X.509) could
>be used to define OIDs for multiple key certificates, but they won't
>be part of the PKIX profile because multiple keys have been judged to
>cause more problems than they solve.
>
>Personal opinion: I'm on the fence as to which approach is "best".
>But the worst solution would be to require applications to support
>both schemes, so one had to be picked.  If interoperability with the
>rest of the X.509 world is the goal, don't use multiple-key certs.
>
>

Date: Mon, 21 Jul 1997 09:29:04 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Combo DSS/ElGamal keys

> From: Mark Shuttleworth <[email-masked]>
> 
> Hi folk
> 
> PGP 5.0 has a neat trick (*ugly* implementation) that combines a DSS key
> for signatures with an ElGamal/DH thing for encryption/keyexchange.  Is
> there a profile to map such a beast into an X.509 certificate?  OID's and
> parameters, etc.

MISSI has that "neat trick" too, for encoding DSS keys, KEA (key exchange)
keys, and privilege bits into a single X.509 version 1 certificate.

Even in version 1, which did not restrict what could go into the
subjectPublicKeyInfo field, MISSI "jumbo certificates" were a hack to
get around the fact that v1 did not have anywhere else to put that
information.  During the evolution of v3, the topic was debated, and
consensus was reached that certificates must contain only a single
public key.

Private profiles (such as one defining PGP's use of X.509) could
be used to define OIDs for multiple key certificates, but they won't
be part of the PKIX profile because multiple keys have been judged to
cause more problems than they solve.

Personal opinion: I'm on the fence as to which approach is "best".
But the worst solution would be to require applications to support
both schemes, so one had to be picked.  If interoperability with the
rest of the X.509 world is the goal, don't use multiple-key certs.

Date: Mon, 21 Jul 1997 10:18:18 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Peter Williams <[email-masked]>
Cc: Michael Leahy <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Cross Certification and Certificate Path Processing

Peter Williams wrote:
 
> If you are following the X.509 procedure for cert path validation (which
> all conforming implementations
> will do)  it doest make any direct impact. All signals and constraints
> to guide the validation procedure
> are inband to the cert, CA cert or cross-cert equally - and enforced by
> conformant semantic handling of the
> extensions and the algorithm.

I would like to make two observations:

1) naming constraint extensions are not necessarilly present within a
certificate. When they are present they must indeed be processed. So
there exists at least conceptually another way to validate a certificate
path: using local naming constraints.

2) When naming contraints contained within the certificates are used, it
is fairly important to apply these constraints on the first leg as well,
i.e. naming contraints on the CA(s) that are trusted since they are not
equally trusted. This means using local constraints. An easy way to do
it is to define these constraints in a self-signed certificate of the
CA, and only use them once they are found acceptable.

I would appreciate that PKIX Part 1 reflects these points.

Regards,

Denis
-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: =?iso-8859-1?Q?Dominique_Lepère?= <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Mon, 21 Jul 1997 08:29:47 +-200

subscribe [email-masked] ietf-pkix

Date: Fri, 18 Jul 1997 13:45:14 +0100
From: Peter Williams <[email-masked]>
To: "KESTERSON.H" <[email-masked]>
CC: [email-masked]
Subject: Re: Year 2000 roll-over

>  to peter's comment about the "*newly*" added text. i added that text
> (generated
> by russ) after the agreement of russ, david, and warwick. with their
> agreement i
> had assumed it would be aligned with pkix intent.
>
>    hoyt

IESG parochial sensibilities notwithstanding, PKIX-1 is indeed a profile
of an ISO
standard. I'm personally delighted at the way ISO and IETF worked
jointly on this area over
the last 3 years. The proof of the success is perhaps measured by
Microsoft recent incorporation
of core OSI layer 6/7 technology into Win32Base for all to use in a
*general* fashion not limited
to certificates.

http://premium.microsoft.com/msdn/library/sdkdoc/oid_262f.htm

not only does the world most voluminous consumer operating system now
contain a complete
implementation of X.509 and signed/encrypted PKCS7 macros, it also
embraces the entire X.500
Information Model, and the notions of abstract syntax as embodied in
ASN.1 ad the rules for
extensibility for specifiers and folk wishing to enable contolled
migration of older systems to new
features. The Microsoft cert server is ideally architected to control
profile and policy issues
through its plug-in architecture; SO PKIX can live quite happily in
the windows world as a non-competitive executable industry agreement. Im
sure java
will catch up eventually as will other platforms. We are well on the
way, I feel, now
to get, anti-ISO politics aside,  IESG to ratify PKIX as RFC status
through recognition of not
only the documents, but uptake, etc.

PKIX1 and PKIX-4 do need to work hand in hand, to define the specialised
semantics
which distinguish PKIX's Internet-profile from others, including SET.
PKIX-4 does embrace the
legal side I referred to, as does PKIX-2 by virtue of OCSP; I am merely
remarking that PKIX needs
to be internally consistent, and instructional, so that new users of
PKIX can make sense of a somewhat
difficult art and not flounder over terms or fundamentals due to
ambigous or competing terms. Perhaps
my  suggstion is not the right solution, but I hope I have made it clear
that both validity notions
need to exist, and they refer to quite different things.

Peter.

Date: Fri, 18 Jul 1997 11:57:26 -0700
From: [email-masked] (KESTERSON.H)
Subject: Re[2]: Year 2000 roll-over
To: Robert Jueneman <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Content-Description: cc:Mail note part

the 2050 date is not in the standard. the standard states in clause 8

"Before a value of Time is used in any comparison operation, e.g. as part of a
matching rule in a search, and if the syntax of Time has been chosen as the
UTCTime type, the value of the two digit year field shall be rationalized into a
four digit year value as follows:
-   If the 2 digit value is 00 through 49 inclusive, the value shall have 2000
added to it.
-   If the 2 digit value is 50 through 99 inclusive, the value shall have 1900
added to it.
Note - The use of GeneralizedTime may prevent interworking with implementations
unaware of the possibility of choosing either UTCTime or GeneralizedTime. It is
the responsibility of those specifying the domains in which certificates defined
in this Directory Specification will be used, e.g. profiling groups, as to when
the GeneralizedTime may be used. In no case shall UTCTime be used for
representing dates beyond 2049."

i believe that in this sense pkix is a profile group in that it states what
parts of a 509 certificate are to be use and how. others may choose an earlier
date. and if the ietf decides to change its mind, there will be no need to
change the standard.

to peter's comment about the "*newly*" added text. i added that text (generated
by russ) after the agreement of russ, david, and warwick. with their agreement i
had assumed it would be aligned with pkix intent.

   hoyt

_______________________________________________________________________________
Subject: Re: Year 2000 roll-over
From:    Robert Jueneman <[email-masked]> at az05-smtp
Date:    7/18/97  6:38

Thanks for the quotes, Russ.  I gather that the 2050 date is well-agreed to,
including outside PKIX.

I also agree with the thrust of Peter's remarks.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Internet Infrastructure Division
122 East 1700 South
Provo, UT 84606
801/861-7387
[email-masked]

>>> Peter Williams <[email-masked]> 07/17 4:39 AM >>>
I have a minor quibble on this text. Its potentially  important, and
caused by language issues,
not agreements over time formats. The aim is to reduce future arguments.

It concerns the use of the term "validity." As the legal community are
using
this term very precisly, as as state in the process of certificate
registration, and given the
standard X.509 semantics indicate that

"A certification authority produces the certificate of a user by signing
(see clause 9) a collection of information, including the user's
distinguished name and public key, as well as an optional unique
identifier containing additional information about the user. The exact
form of the unique identifier contents is unspecified here and left to
the certification authority and might be, for example, an object
identifier, a certificate, a date, or some other form of certification
on the validity of the distinguished name. Specifically, the certificate
of a user with distinguished name A and unique identifier UA, produced
by the certification authority with name CA and unique identifier UCA,
has the following form:
CA<<A>> = CA{V,SN,AI,CA,UCA,A,UA,Ap,TA}
where V is the version of the certificate, SN is the serial number of
the certificate, AI is the identifier of the algorithm used to sign the
certificate, UCA is the optional unique identifier of the CA, UA is the
optional unique identifier of the user A, TA indicates the period of
validity of the certificate, and consists of two dates, the first and
last on which the certificate is valid. The certificate validity period
is the time interval during which the CA warrants that it will maintain
information about the status of the certificate, i.e. publish revocation
data. Since TA is assumed to be changed in periods not less than 24
hours, it is expected that systems would use Coordinated Universal Time
as a reference time base. The signature in the certificate can be
checked for validity by any user with knowledge of CAp. The following
ASN.1 data type can be used to represent certificates:"

and given that the line "The certificate validity period..." is *newly*
added to the X.509 standard and defines
validity in terms of warranted availability of status information,

I recommend the I-Ds text be amended to reduce any confusion of terms
between the
certificate registration people, the X.509 semantics people, and PKIX.
The change should
harmonise X.509 and PKIX, and one should use the term
"certificate-validity" ("attribute-certiifcate-validity"
or "CRL-validity"), perhaps defining these terms to refer to the X.509
defn quoted above.

A note might distinguish X.509 certificate-validity from ABA validity
(as used by CPS and policy types)
and indicate that the two notions are complementary in their function.

Peter.

 Housley, Russ wrote:

> Bob:
>
> Here are the relevant sections.
>
> Russ
>
> = = = = = = = = >
> 4.1.2.5  Validity
>
>    This field indicates the dates on which the certificate becomes
> valid
>    (notBefore) and on which the certificate ceases to be valid
>    (notAfter).  Both notBefore and notAfter may be encoded as UTCTime
> or
>    GeneralizedTime.
>
>    CAs conforming to this profile shall always encode validity dates
>    through the year 2049 as UTCTime; validity dates in 2050 or later
>    shall be encoded as GeneralizedTime.
>
> 4.1.2.5.1  UTCTime
>
>    The universal time type, UTCTime, is a standard ASN.1 type intended
>
>    for international applications where local time alone is not
>    adequate.  UTCTime specifies the year through the two low order
>    digits and time is specified to the precision of one minute or one
>    second.  UTCTime includes either Z (for Zulu, or Greenwich Mean
> Time)
>    or a time differential.
>
>    For the purposes of this profile, UTCTime values shall be expressed
>
>    Greenwich Mean Time (Zulu) and shall include seconds (i.e., times
> are
>    YYMMDDHHMMSSZ), even where the number of seconds is zero.
> Conforming
>    systems shall interpret the year field (YY) as follows:
>
>       Where YY is greater than or equal to 50, the year shall be
>       interpreted as 19YY; and
>
>       Where YY is less than 50, the year shall be interpreted as 20YY.
>
> 4.1.2.5.2  GeneralizedTime
>
>    The generalized time type, GeneralizedTime, is a standard ASN.1
> type
>    for variable precision representation of time.  Optionally, the
>    GeneralizedTime field can include a representation of the time
>    differential between local and Greenwich Mean Time.
>
>    For the purposes of this profile, GeneralizedTime values shall be
>    expressed Greenwich Mean Time (Zulu) and shall include seconds
> (i.e.,
>    times are YYYYMMDDHHMMSSZ), even where the number of seconds is
> zero.
>    GeneralizedTime values shall not include fractional seconds.
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Year 2000 roll-over
> Author:  Bob Jueneman <[email-masked]> at internet
> Date:    7/11/97 12:13 PM
>
> I don't recall what we finally decided would be the roll-over year for
> UTCTime
> after 1 Jan 2000.  Was it 1 Jan 2050?
>
> Did we specify this in PKIX, or as an amendment to X.509, or
> elsewhere?  In
> other words, is the roll-over date universally agreed to?
>
> It won't be my problem, presumably, but I don't want to have to fix it
> again any
> time soon.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked] 

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Fri, 18 Jul 1997 06:38:53 -0600
From: Robert Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: Year 2000 roll-over

Thanks for the quotes, Russ.  I gather that the 2050 date is well-agreed to,
including outside PKIX.

I also agree with the thrust of Peter's remarks.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Internet Infrastructure Division
122 East 1700 South
Provo, UT 84606
801/861-7387
[email-masked]

>>> Peter Williams <[email-masked]> 07/17 4:39 AM >>>
I have a minor quibble on this text. Its potentially  important, and
caused by language issues,
not agreements over time formats. The aim is to reduce future arguments.

It concerns the use of the term "validity." As the legal community are
using
this term very precisly, as as state in the process of certificate
registration, and given the
standard X.509 semantics indicate that

"A certification authority produces the certificate of a user by signing
(see clause 9) a collection of information, including the user's
distinguished name and public key, as well as an optional unique
identifier containing additional information about the user. The exact
form of the unique identifier contents is unspecified here and left to
the certification authority and might be, for example, an object
identifier, a certificate, a date, or some other form of certification
on the validity of the distinguished name. Specifically, the certificate
of a user with distinguished name A and unique identifier UA, produced
by the certification authority with name CA and unique identifier UCA,
has the following form:
CA<<A>> = CA{V,SN,AI,CA,UCA,A,UA,Ap,TA}
where V is the version of the certificate, SN is the serial number of
the certificate, AI is the identifier of the algorithm used to sign the
certificate, UCA is the optional unique identifier of the CA, UA is the
optional unique identifier of the user A, TA indicates the period of
validity of the certificate, and consists of two dates, the first and
last on which the certificate is valid. The certificate validity period
is the time interval during which the CA warrants that it will maintain
information about the status of the certificate, i.e. publish revocation
data. Since TA is assumed to be changed in periods not less than 24
hours, it is expected that systems would use Coordinated Universal Time
as a reference time base. The signature in the certificate can be
checked for validity by any user with knowledge of CAp. The following
ASN.1 data type can be used to represent certificates:"

and given that the line "The certificate validity period..." is *newly*
added to the X.509 standard and defines
validity in terms of warranted availability of status information,

I recommend the I-Ds text be amended to reduce any confusion of terms
between the
certificate registration people, the X.509 semantics people, and PKIX.
The change should
harmonise X.509 and PKIX, and one should use the term
"certificate-validity" ("attribute-certiifcate-validity"
or "CRL-validity"), perhaps defining these terms to refer to the X.509
defn quoted above.

A note might distinguish X.509 certificate-validity from ABA validity
(as used by CPS and policy types)
and indicate that the two notions are complementary in their function.

Peter.

 Housley, Russ wrote:

> Bob:
>
> Here are the relevant sections.
>
> Russ
>
> = = = = = = = = >
> 4.1.2.5  Validity
>
>    This field indicates the dates on which the certificate becomes
> valid
>    (notBefore) and on which the certificate ceases to be valid
>    (notAfter).  Both notBefore and notAfter may be encoded as UTCTime
> or
>    GeneralizedTime.
>
>    CAs conforming to this profile shall always encode validity dates
>    through the year 2049 as UTCTime; validity dates in 2050 or later
>    shall be encoded as GeneralizedTime.
>
> 4.1.2.5.1  UTCTime
>
>    The universal time type, UTCTime, is a standard ASN.1 type intended
>
>    for international applications where local time alone is not
>    adequate.  UTCTime specifies the year through the two low order
>    digits and time is specified to the precision of one minute or one
>    second.  UTCTime includes either Z (for Zulu, or Greenwich Mean
> Time)
>    or a time differential.
>
>    For the purposes of this profile, UTCTime values shall be expressed
>
>    Greenwich Mean Time (Zulu) and shall include seconds (i.e., times
> are
>    YYMMDDHHMMSSZ), even where the number of seconds is zero.
> Conforming
>    systems shall interpret the year field (YY) as follows:
>
>       Where YY is greater than or equal to 50, the year shall be
>       interpreted as 19YY; and
>
>       Where YY is less than 50, the year shall be interpreted as 20YY.
>
> 4.1.2.5.2  GeneralizedTime
>
>    The generalized time type, GeneralizedTime, is a standard ASN.1
> type
>    for variable precision representation of time.  Optionally, the
>    GeneralizedTime field can include a representation of the time
>    differential between local and Greenwich Mean Time.
>
>    For the purposes of this profile, GeneralizedTime values shall be
>    expressed Greenwich Mean Time (Zulu) and shall include seconds
> (i.e.,
>    times are YYYYMMDDHHMMSSZ), even where the number of seconds is
> zero.
>    GeneralizedTime values shall not include fractional seconds.
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Year 2000 roll-over
> Author:  Bob Jueneman <[email-masked]> at internet
> Date:    7/11/97 12:13 PM
>
> I don't recall what we finally decided would be the roll-over year for
> UTCTime
> after 1 Jan 2000.  Was it 1 Jan 2050?
>
> Did we specify this in PKIX, or as an amendment to X.509, or
> elsewhere?  In
> other words, is the roll-over date universally agreed to?
>
> It won't be my problem, presumably, but I don't want to have to fix it
> again any
> time soon.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked] 

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 17 Jul 1997 11:48:46 +0100
From: Peter Williams <[email-masked]>
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: CRL Push over S/Mime

The issue of who is responsible for cancellation authority is a
difficult one; fortunately
its not limited to certificate registration and does not seem any more
security critical
for certificate management than for name/address management.In fact,
given the model
of X.509, it would seem less critical as certificate-users can always
accept
someauthentication and compromise risk if they have other information
sources other
than the CA, and they  are not forced into a mandatory online status
check by some standard,
profile or statue/regulation/ordinance.

Do you (or anyone else) interpret PKIX[-1] profile to make
recommendations or
enfore rules on these issues?

http://www.news.com/News/Item/0,4,12510,00.html?ticker.ms.ie40

Bob Jueneman wrote:

> Peter,
>
> >Bob Jueneman wrote:
>
>
> Section 46-3-307 (4) states that "A licensed certification authority
> may
> revoke one or more certificaters which it issued if the certificates
> are or
> become unreliable, regardless of whether the subscriber consents to
> the
> revocation."

Date: Thu, 17 Jul 1997 11:39:17 +0100
From: Peter Williams <[email-masked]>
To: "Housley, Russ" <[email-masked]>
CC: Bob Jueneman <[email-masked]>, [email-masked]
Subject: Re: Year 2000 roll-over

I have a minor quibble on this text. Its potentially  important, and
caused by language issues,
not agreements over time formats. The aim is to reduce future arguments.

It concerns the use of the term "validity." As the legal community are
using
this term very precisly, as as state in the process of certificate
registration, and given the
standard X.509 semantics indicate that

"A certification authority produces the certificate of a user by signing
(see clause 9) a collection of information, including the user's
distinguished name and public key, as well as an optional unique
identifier containing additional information about the user. The exact
form of the unique identifier contents is unspecified here and left to
the certification authority and might be, for example, an object
identifier, a certificate, a date, or some other form of certification
on the validity of the distinguished name. Specifically, the certificate
of a user with distinguished name A and unique identifier UA, produced
by the certification authority with name CA and unique identifier UCA,
has the following form:
CA<<A>> = CA{V,SN,AI,CA,UCA,A,UA,Ap,TA}
where V is the version of the certificate, SN is the serial number of
the certificate, AI is the identifier of the algorithm used to sign the
certificate, UCA is the optional unique identifier of the CA, UA is the
optional unique identifier of the user A, TA indicates the period of
validity of the certificate, and consists of two dates, the first and
last on which the certificate is valid. The certificate validity period
is the time interval during which the CA warrants that it will maintain
information about the status of the certificate, i.e. publish revocation
data. Since TA is assumed to be changed in periods not less than 24
hours, it is expected that systems would use Coordinated Universal Time
as a reference time base. The signature in the certificate can be
checked for validity by any user with knowledge of CAp. The following
ASN.1 data type can be used to represent certificates:"

and given that the line "The certificate validity period..." is *newly*
added to the X.509 standard and defines
validity in terms of warranted availability of status information,

I recommend the I-Ds text be amended to reduce any confusion of terms
between the
certificate registration people, the X.509 semantics people, and PKIX.
The change should
harmonise X.509 and PKIX, and one should use the term
"certificate-validity" ("attribute-certiifcate-validity"
or "CRL-validity"), perhaps defining these terms to refer to the X.509
defn quoted above.

A note might distinguish X.509 certificate-validity from ABA validity
(as used by CPS and policy types)
and indicate that the two notions are complementary in their function.

Peter.

 Housley, Russ wrote:

> Bob:
>
> Here are the relevant sections.
>
> Russ
>
> = = = = = = = = >
> 4.1.2.5  Validity
>
>    This field indicates the dates on which the certificate becomes
> valid
>    (notBefore) and on which the certificate ceases to be valid
>    (notAfter).  Both notBefore and notAfter may be encoded as UTCTime
> or
>    GeneralizedTime.
>
>    CAs conforming to this profile shall always encode validity dates
>    through the year 2049 as UTCTime; validity dates in 2050 or later
>    shall be encoded as GeneralizedTime.
>
> 4.1.2.5.1  UTCTime
>
>    The universal time type, UTCTime, is a standard ASN.1 type intended
>
>    for international applications where local time alone is not
>    adequate.  UTCTime specifies the year through the two low order
>    digits and time is specified to the precision of one minute or one
>    second.  UTCTime includes either Z (for Zulu, or Greenwich Mean
> Time)
>    or a time differential.
>
>    For the purposes of this profile, UTCTime values shall be expressed
>
>    Greenwich Mean Time (Zulu) and shall include seconds (i.e., times
> are
>    YYMMDDHHMMSSZ), even where the number of seconds is zero.
> Conforming
>    systems shall interpret the year field (YY) as follows:
>
>       Where YY is greater than or equal to 50, the year shall be
>       interpreted as 19YY; and
>
>       Where YY is less than 50, the year shall be interpreted as 20YY.
>
> 4.1.2.5.2  GeneralizedTime
>
>    The generalized time type, GeneralizedTime, is a standard ASN.1
> type
>    for variable precision representation of time.  Optionally, the
>    GeneralizedTime field can include a representation of the time
>    differential between local and Greenwich Mean Time.
>
>    For the purposes of this profile, GeneralizedTime values shall be
>    expressed Greenwich Mean Time (Zulu) and shall include seconds
> (i.e.,
>    times are YYYYMMDDHHMMSSZ), even where the number of seconds is
> zero.
>    GeneralizedTime values shall not include fractional seconds.
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Year 2000 roll-over
> Author:  Bob Jueneman <[email-masked]> at internet
> Date:    7/11/97 12:13 PM
>
> I don't recall what we finally decided would be the roll-over year for
> UTCTime
> after 1 Jan 2000.  Was it 1 Jan 2050?
>
> Did we specify this in PKIX, or as an amendment to X.509, or
> elsewhere?  In
> other words, is the roll-over date universally agreed to?
>
> It won't be my problem, presumably, but I don't want to have to fix it
> again any
> time soon.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]

Date: Thu, 17 Jul 1997 11:03:02 +0200 (SAT)
From: Mark Shuttleworth <[email-masked]>
To: [email-masked]
Subject: Combo DSS/ElGamal keys

Hi folk

PGP 5.0 has a neat trick (*ugly* implementation) that combines a DSS key
for signatures with an ElGamal/DH thing for encryption/keyexchange.  Is
there a profile to map such a beast into an X.509 certificate?  OID's and
parameters, etc.

--
Mark Shuttleworth
Thawte Consulting

Date: Wed, 16 Jul 97 13:43:09 
From: "Housley, Russ" <[email-masked]>
Encoding: 2676 Text
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: Year 2000 roll-over

Bob:

Here are the relevant sections.

Russ

= = = = = = = = 

4.1.2.5  Validity

   This field indicates the dates on which the certificate becomes valid
   (notBefore) and on which the certificate ceases to be valid
   (notAfter).  Both notBefore and notAfter may be encoded as UTCTime or
   GeneralizedTime.

   CAs conforming to this profile shall always encode validity dates
   through the year 2049 as UTCTime; validity dates in 2050 or later
   shall be encoded as GeneralizedTime.

4.1.2.5.1  UTCTime

   The universal time type, UTCTime, is a standard ASN.1 type intended
   for international applications where local time alone is not
   adequate.  UTCTime specifies the year through the two low order
   digits and time is specified to the precision of one minute or one
   second.  UTCTime includes either Z (for Zulu, or Greenwich Mean Time)
   or a time differential.

   For the purposes of this profile, UTCTime values shall be expressed
   Greenwich Mean Time (Zulu) and shall include seconds (i.e., times are
   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
   systems shall interpret the year field (YY) as follows:

      Where YY is greater than or equal to 50, the year shall be
      interpreted as 19YY; and

      Where YY is less than 50, the year shall be interpreted as 20YY.

4.1.2.5.2  GeneralizedTime

   The generalized time type, GeneralizedTime, is a standard ASN.1 type
   for variable precision representation of time.  Optionally, the
   GeneralizedTime field can include a representation of the time
   differential between local and Greenwich Mean Time.

   For the purposes of this profile, GeneralizedTime values shall be
   expressed Greenwich Mean Time (Zulu) and shall include seconds (i.e.,
   times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
   GeneralizedTime values shall not include fractional seconds.

______________________________ Reply Separator _________________________________
Subject: Year 2000 roll-over
Author:  Bob Jueneman <[email-masked]> at internet
Date:    7/11/97 12:13 PM

I don't recall what we finally decided would be the roll-over year for UTCTime 
after 1 Jan 2000.  Was it 1 Jan 2050?

Did we specify this in PKIX, or as an amendment to X.509, or elsewhere?  In 
other words, is the roll-over date universally agreed to?

It won't be my problem, presumably, but I don't want to have to fix it again any
time soon.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

Date: Tue, 15 Jul 1997 14:53:00 -0400
From: "Shah, Jay" <[email-masked]>
Subject: pki mailing list join
To: "'inet'" <[email-masked]>

subscribe [email-masked] ietf-pkix

Date: Tue, 15 Jul 1997 21:20:12 +0200
From: David <[email-masked]>
Organization: FIB
To: [email-masked]
Subject: Subscribe

Subscribe please.

Date: Mon, 14 Jul 1997 15:23:07 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: CRL Push over S/Mime

Peter,

>Bob Jueneman wrote:
>
>[...] t this
>
>> doesn't make long-term economic sense, because neither the subscriber,
>> nor
>> certainly the CA, are in a very good position to know how often that
>> certificate will have to be validated, or by whom, nor what degree of
>> latency will be acceptable.
>
>Surely Bob, such statutes as UTAH require those who determine thata cert
>is unreliable to contact the originator! (A concept I personally
>find a little on the "fascist" side of policy-making, and not
>one overly suited to internet culture!) 

Your statement is a little difficult to parse, because of possible ambiguity
with respect to "those" and "originator".

Under Utah 46-3-301 (4) (a) "A _licensed_ CA 
(i) shall revoke a certificate immediately upon confirming that it was not
issued as required by this section; or
(ii) may suspend, for a reasonable period of time not to exceed 48 hours, a
certificate which it has issued in order to conduct an investigation to
confirm grounds for revocation under Subsection (i)."

Section 46-3-307 (4) states that "A licensed certification authority may
revoke one or more certificaters which it issued if the certificates are or
become unreliable, regardless of whether the subscriber concents to the
revocation."

So as I read it, (remember, IANAA -- I am not an attorney), a licensed CA
has a positive duty to respond to allegations or evidence that may be
received that the certificate has become unreliable, whether due to the
death of the subscriber, a change of address or other substantive detail, or
a compromise of the private key, BUT the CA has no ongoing positive duty to
monitor the subscriber's activities or otherwise providing an on-going
confidence in the certificate.

Interestingly, although the subscriber, by accepting the certificate, makes
representations about the truthfulness of the information contained in the
certificate at the time of issuance, it isn't clear to me whether the
subscriber has a positive duty to notify the CA of any material change in
his or her circumstances after the certificate was issued.

Section 46-3-304 (4) (a) states, "By accepting a certificate, a subscriber
undertakes to indemnify the issuing certification authority for any loss or
damage caused by issuance or publication of a certificate in reliance on a
false and material representation of fact by the subscriber, or the failure
by the subscriber to disclose a material fact if the representation or
failure to disclose was made either with intent to deceive the certification
authority or a person relying on the certificate or was made with
negligence."

I think that particular part of the statute could probably be argued either
way. However, I also strongly suspect that if the subscriber's circumstances
change, and he/she fails to notify the CA, _and_ some relying party is
harmed thereby, the CA and/or the relying party will have every right to sue
the subscriber for any damages, and will probably prevail.

Other than those two paragraphs in the statute, I cannot find any other
reference to "those" (presumably meaning some third party, perhaps including
a relying party), having any duty to notify anyone at all if they find out
that a certificate contains erroneous informaton. On the other hand, if
someone does point out such infromation to a CA, the CA almost surely has a
responsibility to investigate the allegations. How much effort has to be put
into this investigation certainly isn't clear -- "commercially reasonable"
would probably be the guideline.

It is interesting to note that the ABA Guidelines, section 4.3, states a
positive duty on the subscriber to notify the CA in the event the private
key is compromised, but is silent regarding the validity of other
information in the certificate which might change after issuance.

>Is the design of UTAH
>and a few other simialr schemes not that the digital signature is
>essentially presumptive
>evidence of signing intent, per se, unless there is otherwise reason to
>doubt? Surely
>this is not a function of economics, but of law design per jurisdiction?

Yes, that is the intent, at least with respect to digital signature backed
up by certificates issued by licensed CAs. Certificates issued by unlicenced
CAs are treated as the equivalent of a mark, or as an "electronic signature"
that may not be all that different than a simple e-mail signature -- that is
up to common law and a court to decide on a case by case basis. The Utah law
simply doesn't apply, except to licensed CAs.

But the "reason to doubt" is the key, even for a licensed CA. 46-3-307,
Revocation of a certificate, paragraph (5) states: ":Immediately upon
revocation of a certificate by a licensed certification authority, the
licensed rertification authority shall publish signed notice of the
revocation in any repository specified in the certificate for publication of
notice of revocation. If any repository specified in the certificate no
longer exists or refuses to accept publication, or is no longer recognized
pursuant to Section 46-3-501, the licensed certification authority shall
publish the notice in any recognized repository."

In the definitions, 46-3-103 (24) states, ""Publish" means to record or file
in a repository."

Unless waived, the repository has one business day to publish the notice of
revocation after receiving notification from a CA, and a licensed CA in turn
has one business day after receving a request to revoke a certificate to do
so.

Nowhere in any of this do I see a positive duty of the CA or the respository
to notify the entire world, willy-nilly. In particular, I see nothing that
would require a CA or repository to maintain a list of all possibly
interested parties, and send them reliable notice any time something
changed. Rightly or wrongly, the Utah Act envisioned a pull model (in part,
I confess,  because that's what folks like me who were participating in the
discussions had in mind.). But of course, a repository can make whatever
contractual or other agreements it likes, both with its own subscribers or
with the various CAs, and such agrements might include push notification to
some kind of a distribution list.
>
>A signature is a sometime public declaration and not-so public act. If
>there is a "non-public act"
>involved when applying certs and signatures type technology, then
>*private* CA domains
>and distribution channels can easily impose selective governing terms in
>bilateral
>and multi-lateral domains of interpretation to restrict semantics to
>suit,
>and imposed oblgations such as - you WILL use the
>state repository, pay a non-negotiable per-transaction fee to the
>contractor,
>or else face the wrath of the sherriff of UTAH.

The repository is not a state-owned or operated repository, just one that is
licensed by the state.  CAs, even licensed CAs, don't have to use it -- they
can provide such publication services themselves -- but they may choose to,
presumably by including the address of the repository in the
CRL-distribution point in the certificate.  Even licensed CAs may not want
to have the responsibility of operating a highly reliable, 7x24 type of
operation, and may choose to contract out such services. The Zions
repository is not operated by or on behalf of the state, it was just
required by the contract to prime the pump and make some of these services
available to the public. They are free to charge whatever they like, and no
CA is required to use their services. In other words, they are free to fail
if they don't offer a valuable service.
>
>I can undersatnd motivations for such a scheme (though Im
>not sure many industriees will accept a per-transaction fee-based
>industry for PKI), but is it to be universal and ubiquitous, and
>exlusionary
>of the public-spirited model serving also personal privacy, general
>accountability of individual action,  say, versus those areas of
>commerce and trade akin to UTAH's prescriptive models, all of which
>PKIX addresses?

Say whaa?

Is it to be universal?  Almost surely not, although it is envisioned that
repositories may be linked together. Will it be ubiquitous?  To the extent
that LDAP will be available, and probably other access methods as well, yes.
Exclusionary of the public-spirited model serving also personal privacy
[and] general accountability of individual action?  No, not exclusionary,
unless such public spirited, pro bono institutiions such as VeriSign decide
to publish their [free?] certificates there exclusively, which seems
unlikely, nor the intent. 

Areas of commerce and trade akin to Utah's prescriptive models?  Certainly I
would expect that electronic commerce users would be the primary consumers
of a repository's functions, as opposed to the pro bono (free) users.  But
prescriptive?  Contrary to what the popular opinion seems to be, there isn't
anything prescriptive in the Utah statute at all. If you want to use
unlicensed CAs, which may be either of the pond-scum or the sterling silver
nature, you are completely free to do so. If you want to avail yourself of
the services of a CA that has voluntarily agreed to submit to certain
standards regarding the operation, auditing, financial responsibility, etc.,
you may take advantage of such services, and in that case the law will
accord your signature a somewhat higher level of credibility in court.  So
what is prescriptive about that?
>
>Surely, PKIX (and the Internet)  is about inter-networking autonomous
>domains -
>not imposing a single, monolithic international key management
>infrastructure??

Yes, but again, so what?  Did someone propose a single monolithic key
management infastructure while I wasn't looking?  (Other than McCain/Kerrey,
of course, which doesn't count!)

>>
>
>[...]
>
>> The only way that I can see a push model working is on a subscription
>> basis
>> for emergency certificate suspensions or revocations, but probably not
>> for
>> routine change of address cancellations where the subscriber is still
>> personally liable for the transaction.
>
>I think this distinction is fine. Just as NSA's MISSI program helped DMS
>design CRL-pull for semi-robust revocation of name bindings, and
>authentication
>status, (relying upon organization dymanics, and expiry also) so then
>the DMS designers
>imposed email-PUSH for compromised-key information (for individual email
>channels) where (obviously) impacts are more severe and immediate action
>is required. And
>remember, for "CA compomise", the planned reaction is designed to be yet
>considerably
>more severe  than "mere" compromised-key handling.

But DMS was a different environment, where a flood type environment was
specifically designed to be reliable.  I'm not sure that USENET would be so
reliable, much less individual e-mail messages.
>
>For commercial trnasactions, planning for the notion of reliance (when
>and when it is not
>reasonable) is perhaps the parrallel of the MISSI distribution of KRL
>information detemrining
>when and when it is not reasonable to authorise access to confidential
>information from a
>previously distributed email.
>
>Just as MISSI pushed KRLs to the world, should we not be at least
>allowing pushing
>of "reliance-data" (i.e. revocation status) to the world, under contract
>where necessary, and
>through conventional internet dynamics where impacts are less severe?.

If you attempt to push an emergency CRL to me, prior to the expiration of
the next valid CRL, and I don't get it, then I have been misled, perhaps
seriously.  If I attempt to pull a CRL from a repository and I don't get an
answer, then I at least know that something is wrong, and I can undertake
any local response that seems appropriate.
>
>Scoping PKIX-II to address this kind of security need would help surely
>rationalise
>the profiles and choices of protocols specified in the document, over
>and above
>the mere interoperability guidelines for developers, currently present,
>would
>you not agree?
>
>Peter.
>
I would prefer to concentrate on a simple  LDAP pull model, without even
including any billing information, and leave the more sophisticated
mechanisms until we have either some validated business models or a clear,
more compelling need.  In that regard I view the Zions/DSTC effort as
essentially an alpha test of these concepts. If the mechanism works, and is
accepted by some significant portion of the business community, then I'm
sure they will submit their protocols as an informational RFC at least, and
others can build to them or even standardize on them as may be required. But
lets see a few systems deployed first, before we architect all possible
variations.

Sometimes I think we get carried away trying to design all possible
methodologies before we ever worry about practicality, or seeing what works.
 The hallmark of the IETF, as opposed to ISO, was supposed to be "concensus,
and working code", not "design by committee!"

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                     

Date: Mon, 14 Jul 1997 12:28:09 +0100
From: Peter Williams <[email-masked]>
To: Bob Jueneman <[email-masked]>
CC: [email-masked]
Subject: Re: CRL Push over S/Mime

Bob Jueneman wrote:

[...] t this

> doesn't make long-term economic sense, because neither the subscriber,
> nor
> certainly the CA, are in a very good position to know how often that
> certificate will have to be validated, or by whom, nor what degree of
> latency will be acceptable.

Surely Bob, such statutes as UTAH require those who determine thata cert
is unreliable to contact the originator! (A concept I personally
find a little on the "fascist" side of policy-making, and not
one overly suited to internet culture!) Is the design of UTAH
and a few other simialr schemes not that the digital signature is
essentially presumptive
evidence of signing intent, per se, unless there is otherwise reason to
doubt? Surely
this is not a function of economics, but of law design per jurisdiction?

A signature is a sometime public declaration and not-so public act. If
there is a "non-public act"
involved when applying certs and signatures type technology, then
*private* CA domains
and distribution channels can easily impose selective governing terms in
bilateral
and multi-lateral domains of interpretation to restrict semantics to
suit,
and imposed oblgations such as - you WILL use the
state repository, pay a non-negotiable per-transaction fee to the
contractor,
or else face the wrath of the sherriff of UTAH.

I can undersatnd motivations for such a scheme (though Im
not sure many industriees will accept a per-transaction fee-based
industry for PKI), but is it to be universal and ubiquitous, and
exlusionary
of the public-spirited model serving also personal privacy, general
accountability of individual action,  say, versus those areas of
commerce and trade akin to UTAH's prescriptive models, all of which
PKIX addresses?

Surely, PKIX (and the Internet)  is about inter-networking autonomous
domains -
not imposing a single, monolithic international key management
infrastructure??

>

[...]

> The only way that I can see a push model working is on a subscription
> basis
> for emergency certificate suspensions or revocations, but probably not
> for
> routine change of address cancellations where the subscriber is still
> personally liable for the transaction.

I think this distinction is fine. Just as NSA's MISSI program helped DMS

design CRL-pull for semi-robust revocation of name bindings, and
authentication
status, (relying upon organization dymanics, and expiry also) so then
the DMS designers
imposed email-PUSH for compromised-key information (for individual email

channels) where (obviously) impacts are more severe and immediate action
is required. And
remember, for "CA compomise", the planned reaction is designed to be yet
considerably
more severe  than "mere" compromised-key handling.

For commercial trnasactions, planning for the notion of reliance (when
and when it is not
reasonable) is perhaps the parrallel of the MISSI distribution of KRL
information detemrining
when and when it is not reasonable to authorise access to confidential
information from a
previously distributed email.

Just as MISSI pushed KRLs to the world, should we not be at least
allowing pushing
of "reliance-data" (i.e. revocation status) to the world, under contract
where necessary, and
through conventional internet dynamics where impacts are less severe?.

Scoping PKIX-II to address this kind of security need would help surely
rationalise
the profiles and choices of protocols specified in the document, over
and above
the mere interoperability guidelines for developers, currently present,
would
you not agree?

Peter.

Date: Mon, 14 Jul 1997 11:37:38 +0100
From: Peter Williams <[email-masked]>
To: Dwight Arthur <[email-masked]>
CC: "G. Mack Hicks, VP Bank of America" <[email-masked]>, [email-masked]
Subject: Re: CRL Push over S/Mime

Dwight Arthur wrote:

> G. Mack Hicks, VP Bank of America wrote:
> > <...> I am at a loss to understand how every MS CA and Netscape CA
> > (thousands -- maybe millions? scary) is going to start PUSHing out
> > their CRLs to unsuspecting repositories and directories. Will this
> > really scale? <...>

"Mack, you make an excellent point about informed cost decisions. I
agree
with you that a global 'push this CRL to all directories and
repositories' will not scale. On the other hand, I can describe several
cases where pull models including OCSP are problematic:"

-------

Dwight,

I'm, partially responsible for OCSP - in that I set the security
requirements and
concept of operations for the system (named here OCSP.bis) on which the
specification
is based. (OCSP.bis is fully deployed to several million people, by the
way, though
in more of the online status mode, than in the mode which follows and
for which considerable security analysis was done:- )

OCSP.bis was a mixed pull/push design. The purpose of using
signed responses was to enable strong authentication of source, AND
caching
of the (signed) message by http/firewall proxies and http-push-based
message routers
such as Microsoft's Proxy Server, and Content Replication System. Part
of the rationale was security against network failure and delay, and
another part was scaling to a billion or more occasional parties.

See just todays http://www.microsoft.com/corpinfo/7-14proxyserver.htm
for example which mixed signed-object, virus scanning content
replication, firewalling,
application proxying and packet relaying together with trust domain
management!

In this way, we sought to re-use much of the original X.500 concepts for

the distribution not only of routing and conenction point knowledge for
the distirbuted access points, but also high-availability revocation
information.
I allowed the bilateral agreements model to control the guarantees of
timely
and regulat delivery of such information to local replicates to support
those
who need such quality. We kept the replication notions at the
"directory-level"
rather than the database-level quite deilberately so as
to best exploit open systems inter-*networking*, over brute-force
raw-power.

(Folks interested in history may want to compare OCSP signed-response
with a X.500 signed DAP-read operation response on a read request on the

certificate attribute of a singled-valued X.500 entry; this revocation
scheme
I first designed and indeed implemented after the Boston IETF nearly 5
years
ago; things find their own time to march, as Steve Crocker tought me; no

point pushing things faster than the market wants to actually accept
them)

I would argue that "push-caching" (where the bilateral contract to
carefully and reliably push are arranged by pull) will most certainly
scale (and
does scale in practice), and the large X.500 Paradise pilots proved it
for both the online
DAP operations, and the creation of bilateral agreement fault-tolerant
replication and distribution
networks between  internet-type providers of both telco and
organizational varieties. As the web
Internet application-layer catches up to X.500 (and this happening at
very fast speed
now in the http replication, caching/ and firewalling arena) we should
shortly have
what most of had in the OSI days, but with rather more significant
buyin from the vendors, with much the same scaling properties and
(in reality) the same design. This infrastructure may well carry over
to benefit ldapv3 (the ghost of X.500), or it may not, we will see.

As with all internet versions of large-scaled intelligent application
protocols, the
working models which actually get used based on the deploying
infrastructure
technology at routers, firewall and trust-domain-enforcing  proxy
servers will
take a little time to settle down into user-driven conventions.

The great thing about this industry is we have a technology
shelf stuffed full of advanced goodies, all waiting to be
pulled down and applied. There is plenty more modern intelligent
message switching and security & crypto  technology to go yet!
Iw woudl not wish PKIX to standardize material which
prevents more intelligent designs, and hold
the market back from where its going, by overly constraining
PKIX-II or making its profiles of common internet baseline protocols
more important in conformance terms than they really need be
to ensure actual large-scale  interworking at the billion+ levels
of service.

> >
> > The point is that the receiver of a document which is signed must
> make
> > a decision whether the cost and effort of validating a certificate
> is
> > worth it. If the "cost and effort" seem to be "free" (which seems to
>
> > be the case for the PUSHed CRL to all repositories and directories),
>
> > then the cost is hidden from the receiver - and the receiver will
> not
> > make an informed decision. The receiver will also have to believe
> CRLs
> > PUSHed to her from parties (unfamiliar CA's and repositories) where
> > there is no contractual relationship or even legal recourse.
>
> Mack, you make an excellent point about informed cost decisions. I
> agree
> with you that a global 'push this CRL to all directories and
> repositories' will not scale. On the other hand, I can describe
> several
> cases where pull models including OCSP are problematic: including
> cases
> where a low probability of revocation combines with a high cost of
> delay
> (such as repurchase agreements) and cases where high transaction
> volumes
> combine with long settlement cycles (such as ACH-funded Mutual Fund
> purchases).
>
> I still strongly advocate that PKIX support a sessionless,
> authenticated
> push of CRL's among contracted parties.

OCSP-bis *was* designed for sessionless, authenticated
push of [CRL's/revocation-infomation] among contracted parties,
amongt other environments of likely use.

It seems to ne that a number of distribution issues are colliding here
in
the discussion of PKIX-II - email, bodyparts, syntaxes, http, push,
X.500,
mime types, etc. This may take a verbal forum at IETF to
decide how to re-apportation community specification effort on a
re-vitalised/re-scoped  PKIX-II. I think we are feeling and saying
the same thing re the future, and expressing the need for more
refined and scoped concept for this part..

> --------------------------------------------------
> p:(212) 412-8687                     Dwight Arthur
> f:(212) 908-2345        Managing Director: Systems
> b:(917) 646-6682      National Securities Clearing
> [email-masked]                   55 Water Street
> http://www.nscc.com        New York, NY 10041-0082

Date: Mon, 14 Jul 1997 12:14:54 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: CRL Push over S/Mime

Regardless of the technical merits and scalability arguments of push vs.
pull models, there is a fundamental issue of the business model which has to
be addressed. Someone is eventually going to have to pay for all of these
repositories and the bandwidth that is used in communicating CRLs back and
forth  -- providing all of the necessary high reliability infrastructure
won't be cheap, and certainly won't come for free. 

At present, the CRL infrastructure cost seems to be buried in the cost of
the initial certificates, which would imply that the subscriber (the subject
listed in the certificate) pays for the CRLs, at least indirectly. But this
doesn't make long-term economic sense, because neither the subscriber, nor
certainly the CA, are in a very good position to know how often that
certificate will have to be validated, or by whom, nor what degree of
latency will be acceptable.

The only economically reasonable model, to my way of thinking, is a pull
model, where the subscriber requests CRLs (or a positive, nonrepudiable,
confirmation of validity, which would be significantly better and more
timely) from either a CA, or from a repository who has contracted with
multiple CAs to provide that kind of CRL distribution point service.

In many case, notably in a corporate model, the user's company may download 
CRL status from a repository on a mass basis, perhaps once a week, or they
might cache CRLs if and as requested.  If the user has a requirement to
obtain the status of a certificate, their software will interrogate the
corporate sub-repository.  If the corporate database doesn't contain a CRL
for that certificate, or if the status was not sufficiently up to date, the
corporate repository would either go to the public repository, or directly
to the CA. The advantage of having the corporate repository get the update,
as opposed to each user, should be obvious, although it may add a minor
amount of additional latency.

In either case it is highly likely that some kind of billing information
will have to be passed along with the request, presumably authenticated with
a digital signature, before the CA or repository will respond.  If
reasonable fees are not required, someone could effectively bankrupt the CA
or repository  by asking for all CRLs over and over again.

The only way that I can see a push model working is on a subscription basis
for emergency certificate suspensions or revocations, but probably not for
routine change of address cancellations where the subscriber is still
personally liable for the transaction.  Even then, in all probability there
will be a very great number of certificate cancellations that the relying
party will care nothing whatsoever about, because they don't happen to do
business with that individual or firm. And for those certificates that a
person does care about, the push model may not be sufficiently robust or
timely to satisfy the user's needs. (What guarantee is there that the push
model succeeds?  And if it doesn't, where does that leave the relying party?
Perhaps most importantly, who has the liability for that certificate??)

The bottom line, as far as I am concerned, is that the entire CRL model is
fundamentally broken for anything other than routine identification of web
servers via SSL for low to zero value transactions, and for casual e-mail. 
For electronic commerce, it will be frequently be essential to obtain
nonrepudiable confirmation of the validity of a certificate by submitting
the actual digital signature to be validated to the CA or repository/oracle,
and asking it to confirm the validity of that signature as of that specific
moment.  In all probablility, the CA or repository will be asked to provide
a form of insurance against errors and omissions having occurred, up to some
lcaimed tansaction value. Since that implies some risk, as well as some
processing, there will be a fee associated with that transaction.

Zions Bank/Digital Signature Trust Co. is presently implementing
approximately the type of repository functionality that I have described
(minus the insurance, at least so far), under contract to the State of Utah
as part of the implementation of the Utah Digital Signature Act.  It will be
very interesting, to say the least, to see how their business model works
out.

Bob

>
>
>>>> Dwight Arthur <[email-masked]> 07/14/97 05:06AM >>>
>G. Mack Hicks, VP Bank of America wrote:
>> <...> I am at a loss to understand how every MS CA and Netscape CA
>> (thousands -- maybe millions? scary) is going to start PUSHing out 
>> their CRLs to unsuspecting repositories and directories. Will this 
>> really scale? <...>
>> 
>> The point is that the receiver of a document which is signed must make
>> a decision whether the cost and effort of validating a certificate is
>> worth it. If the "cost and effort" seem to be "free" (which seems to
>> be the case for the PUSHed CRL to all repositories and directories), 
>> then the cost is hidden from the receiver - and the receiver will not 
>> make an informed decision. The receiver will also have to believe CRLs 
>> PUSHed to her from parties (unfamiliar CA's and repositories) where 
>> there is no contractual relationship or even legal recourse.
>
>Mack, you make an excellent point about informed cost decisions. I agree
>with you that a global 'push this CRL to all directories and
>repositories' will not scale. On the other hand, I can describe several
>cases where pull models including OCSP are problematic: including cases
>where a low probability of revocation combines with a high cost of delay
>(such as repurchase agreements) and cases where high transaction volumes
>combine with long settlement cycles (such as ACH-funded Mutual Fund
>purchases).
>
>I still strongly advocate that PKIX support a sessionless, authenticated
>push of CRL's among contracted parties.
>
>--------------------------------------------------
>p:(212) 412-8687                     Dwight Arthur
>f:(212) 908-2345        Managing Director: Systems
>b:(917) 646-6682      National Securities Clearing
>[email-masked]                   55 Water Street
>http://www.nscc.com        New York, NY 10041-0082
>

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                 

Date: Mon, 14 Jul 1997 11:06:07 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: ISC July 29-30 Meeting Notice

For the information of subscribers...

>=============================
>                       MEETING NOTICE
>=============================
>
>Please correspond with:
>  Michael S. Baum, Esq.
>  One Alewife Center, Suite 350
>  Cambridge, MA 02140 USA
>  V: +1 617.661.1234
>  F: +1 617.661.0716
>  E: [email-masked]
>
>
>Subject: INFORMATION SECURITY COMMITTEE MEETING NOTICE - JULY 29-31, 1997
>
>
>Dear Committee Member and Prospective Members:
>
>You are cordially invited to participate in a meeting of the Information
>Security Committee, Section of Science & Technology, American Bar
>Association, on Tuesday-Thursday, July 29-31, 1997, at KPMG, Three
>Embarcadero Center, San Francisco, California. This meeting will take place
>just before the ABA Annual Meeting in San Francisco on July 31 - August 6.
>The Committee will continue its advancement of public key infrastructure
>legal and control issues, and will include further work on CA
>accreditation, commercial key escrow guidelines, PKI evidentiary issues,
>digital signature legislative initiatives, and CA / user liability, among
>other matters.
>
>Consistent with Section policy, ISC meeting participants must be members of
>both the ABA and the ABA Section of Science and Technology.  Please contact
>Ann Kowalsky, Manager Section of Science & Technology, at ABA headquarters
>in Chicago by phone: +1 (312)988.5599, fax: +1 (312)988.5628, or email:
>[email-masked] for membership information. You can become a paid
>member of the ABA and the ISC at the July 28-30 meeting -- and affiliate
>ABA membership is available for non-lawyers. 
>
>Meeting details appear below. I look forward to seeing you in San Francisco.
>
>Sincerely, 
>
>
>Michael S. Baum 
>Chair, Information Security Committee 
>Section of Science & Technology, ABA 
>--------------- 
>
>INFORMATION SECURITY COMMITTEE 
>Section of Science & Technology, ABA 
>July 29-31, 1997 
>
>Tentative Agenda 
>(see "Meeting Details," next page) 
>(In extended sessions, breaks will be taken as needed.) 
>
>July 29, 1997  Tuesday
>13:00-14:00   Greetings, administrative matters 
>14:00-14:30   Introductions, meeting logistics, general announcements 
>14:30-16:00   Updates by Work Groups; General discussion of 
>              Senate Bill 909 and a Draft Proposed ABA Resolution
>16:00-17:00   WG breakouts, including a working dinner
>17:00-???     Watering hole discussions; possible continuation of WG meetings
>
>July 30, Wednesday
> 8:30-09:00   Breakfast, et cetera
> 9:00-12:00   Breakout sessions; legislative WG conference call
>12:00-13:00   Lunch speaker Alfred Charles and David Grey, of the
>              California Secretary of State's office.
>              Topic: California Digital Signature Regulation
>13:00-17:00   Breakout sessions
>
>July 31, Thursday
> 8:30-09:00   Breakfast, et cetera. 
> 9:00-12:00   WG wrap-ups;
>12:00-13:00   Lunch speaker/Discussion: Bill Dziadyk of the 
>              Canadian Security Establishment
>13:00-14:30   WG Presentations and path forward of an SB909 resolution
>14:30-15:00   Path forward; wrap-up
> 
>
>
>Information Security Committee 
>San Francisco, CA MEETING DETAILS 
>July 29-31, 1997 
>
>Members are urged to participate in one of the work groups that will be
>presenting/meeting during the ISC's meeting. Please contact Ruven Schwartz,
>Esq. ([email-masked]) for further information. 
>
>
>**Accreditation Work Group 
>Contacts:   Chas Merrill, Esq. ([email-masked])
>            Rick Hornbeck ([email-masked])
>            Lynn McNulty ([email-masked]) 
>                    
>The Accreditation Work Group will continue its work on the Accreditation
>for Public Key Certificate Authorities outline and draft, in expectation of
>delivering a draft for public comment before the year is ended. 
>
>
>**Addendum Work Group 
>Contact:     Joseph Alhadeff, Esq. ([email-masked])
>             Tom Smedinghoff, Esq. ([email-masked]) 
>             Joe Wackerman, Esq. ([email-masked]) 
>
>The Addendum Work Group will continue drafting a digital signature trading
>partner agreement -- integrating the principles of the Digital Signature
>Guidelines, and developing additional practical commentary for this model
>form of electronic commerce agreement. 
>
>
>**Evidentiary Work Group 
>Contact:     Gary Fresen, Esq. ([email-masked])
>             Stan Kurzban, Esq. ([email-masked]) or 
>             Serge Parisien, Esq. ([email-masked]) 
>
>The Evidentiary Work Group will continue its drafting of the judicial
>tutorial and report on its coordination activities with record management
>standards authorities.  The working group members will also assist the
>other working groups on their evidentiary issues.
>
>
>**Key Escrow Work Group (KEWG) 
>Contacts:   Emily Frye, Esq. ([email-masked]) 
>            Dwight Olson, Esq. ([email-masked]) 
>
>The KEWG concentrates its efforts in two ways.  First, it monitors proposed
>legislation and regulations, both here and abroad, that address key
>recovery.  The KEWG offers comments where it thinks they would be
>appropriate.  The KEWG's larger work is a document addressing the framework
>and operation of a key recovery center.  Work is in the advanced outline
>stage and will focus on fleshing out draft text.
>
>
>**Liability Work Group 
>Contact:     Maureen Adamache, Esq. ([email-masked]) 
>             Elise Reed 
>
>The Liability Work Group will continue its work with the Accreditation
>Group on the liability side.  It will also continue its work preparing
>liability policy statements, its analyses of the liability of application
>software providers, and it discussion of liability for other applications
>of public key cryptography.  It will also take on a new issue, technical
>methods of binding relying parties.
>
>
>**Digital Signatures Laws & Regulations 
>Contacts:   Kenneth Allen, Esq. ([email-masked])
>            Dan Greenwood, Esq. ([email-masked])
>            Dale Juffernbruch, Esq. ([email-masked])
>
>The Legislative and Regulatory Working Group will hold its periodic
>conference call, sponsored this round by the State of California, to
>discuss updates to legislation and regulation regarding electronic
>authentication.  The Leg/Reg Working Group would also like to continue to
>explore the relationship between legislation in this area and accreditation
>of Certification Authorities; further pursue the evidentiary effects of
>electronic authentication, and possibly begin to draft a user's manual; and
>discuss litigation, to the extent any exists.
>
>
>The dress for the meeting is business attire.
>
>First-time participants planning to attend the July 29-31 meeting must
>contact Ruven Schwartz, ISC ViceChair, at 612-687-8095 or
>[email-masked], to coordinate work-product contributions for the
>upcoming meeting. 
>
>Meeting Location: 
>KPMG
>Three Embarcadero Center
>San Francisco, CA 94111
>415-951-0100
>
>
>Meals: Lunch on July 30 and 31 will be available at cost. 
>
>Lodging:  Because we are holding the meeting just before the ABA Annual
>meeting, we encourage you to use the hotels that they have reserved and
>extend your stay to the two nights prior to cover the ISC meeting.  You
>must go through ITS to make reservations by sending in the ABA meeting
>registration form (at http://www.abanet.org/annual/97/regform.html or
>http://www.itsmtgs.com/aba/ or attached to the end of this message).  For
>those who will not be attending the ABA Annual Meeting, you can try the
>hotels directly (http://www.abanet.org/annual/97/housing.html), or the
>following hotels which are all close by: Hyatt Regency (415-788-1234), Park
>Hyatt (415392-1234), Harbor Court (415-882-1300), and the Griffen
>(415-495-2100).
>
>
>RSVP: Please confirm your intention to participate to Ann Kowalsky, Section
>Manager, Section of Science and Technology ([email-masked]) as soon
>as possible. 
>
>See you in San Francisco.
>
>===============================

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date: Mon, 14 Jul 1997 07:06:37 -0400
From: Dwight Arthur <[email-masked]>
To: "G. Mack Hicks, VP Bank of America" <[email-masked]>
CC: [email-masked]
Subject: Re: CRL Push over S/Mime

G. Mack Hicks, VP Bank of America wrote:
> <...> I am at a loss to understand how every MS CA and Netscape CA
> (thousands -- maybe millions? scary) is going to start PUSHing out 
> their CRLs to unsuspecting repositories and directories. Will this 
> really scale? <...>
> 
> The point is that the receiver of a document which is signed must make
> a decision whether the cost and effort of validating a certificate is
> worth it. If the "cost and effort" seem to be "free" (which seems to
> be the case for the PUSHed CRL to all repositories and directories), 
> then the cost is hidden from the receiver - and the receiver will not 
> make an informed decision. The receiver will also have to believe CRLs 
> PUSHed to her from parties (unfamiliar CA's and repositories) where 
> there is no contractual relationship or even legal recourse.

Mack, you make an excellent point about informed cost decisions. I agree
with you that a global 'push this CRL to all directories and
repositories' will not scale. On the other hand, I can describe several
cases where pull models including OCSP are problematic: including cases
where a low probability of revocation combines with a high cost of delay
(such as repurchase agreements) and cases where high transaction volumes
combine with long settlement cycles (such as ACH-funded Mutual Fund
purchases).

I still strongly advocate that PKIX support a sessionless, authenticated
push of CRL's among contracted parties.

--------------------------------------------------
p:(212) 412-8687                     Dwight Arthur
f:(212) 908-2345        Managing Director: Systems
b:(917) 646-6682      National Securities Clearing
[email-masked]                   55 Water Street
http://www.nscc.com        New York, NY 10041-0082

Date: Fri, 11 Jul 1997 22:21:41 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: "Housley, Russ" <[email-masked]>
CC: "Mike St. Johns" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: FW: CRL Push over S/Mime

I think the idea of separating this material out to a separate RFC is
probably
good.

I am less confident about the tagged object definition below
for the following two reasons:

1) Alot of implementors don't want to deal with BER/DER decoding
   at the time they make the initial dispatch decision to the
   code that handles a specific mime type.  I think this is often the
case
   for typical mail and browser programs in many cases. See also:
related
   discussions on the smime-dev mailing list.  I think the case is a bit
stronger
   for browsers.

2) PKCS-7 already provides essentially a generic tagged object format.

--a.

Housley, Russ wrote:
> 
> All:
> 
> Mike's "2 page RFC" comment hits home with me.  Are we making PKIX part 2
> too complex by putting all of this information in a since document?  Would
> it be easier to read and handle if each of the mechanisms for obtaining
> certificates and CRLs were in a separate document?
> 
> Russ
> 
> ______________________________ Reply Separator _________________________________
> Subject: Re: Re[2]: FW: CRL Push over S/Mime
> Author:  [email-masked] (Mike St. Johns) at internet
> Date:    7/10/97 7:05 PM
> 
> I keep thinking that the right way to do this is to define:
> 
> TaggedObject ::= SEQUENCE {
>    tag            OBJECT IDENTIFIER,
>    object         ANY DEFINED BY tag }
> 
> And then define the mime type as application/security-object or some such.
> Then give each high-level construct (certificate, CRL, etc) an OID to identify
> it if it doesn't already have one.  Since the objects are generally handled in
> a like manner (by a security module) it makes sense to group them under a
> common mime opaque type.  This is about a 2 page RFC - more if you want it to
> include the OIDs.
> 
> Mike

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

Date: 11 Jul 97 20:23:00 +1700
From: [email-masked]
To: [email-masked]
Subject: How to UNSUBCRIBE from the IETF mailing list

Hi all,

Instructions :
-------------

Please use the [email-masked] address !
               -------------------

If you ever want to remove yourself from this mailing list,
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Example:
--------

 Suppose you are fred at iwantoff.com and you wish to unsubscribe
 from this list.

 1) In the content of your email you would write the following line :

    unsubscribe [email-masked] ietf-pkix

 2) You then address your email request to

    [email-masked]

  Within a few seconds of receiving the mail message, the listserver
  will remove you from this list and will send a confirmation email
  to tell you the results of your request.

Regards
Jean

Date: Fri, 11 Jul 97 09:02:54 
From: "Housley, Russ" <[email-masked]>
Encoding: 1124 Text
To: [email-masked] (Mike St. Johns)
CC: [email-masked], [email-masked], [email-masked]
Subject: Re[4]: FW: CRL Push over S/Mime

All:

Mike's "2 page RFC" comment hits home with me.  Are we making PKIX part 2 
too complex by putting all of this information in a since document?  Would 
it be easier to read and handle if each of the mechanisms for obtaining 
certificates and CRLs were in a separate document?

Russ

______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: FW: CRL Push over S/Mime 
Author:  [email-masked] (Mike St. Johns) at internet
Date:    7/10/97 7:05 PM

I keep thinking that the right way to do this is to define:

TaggedObject ::= SEQUENCE {
   tag            OBJECT IDENTIFIER,
   object         ANY DEFINED BY tag }

And then define the mime type as application/security-object or some such.  
Then give each high-level construct (certificate, CRL, etc) an OID to identify 
it if it doesn't already have one.  Since the objects are generally handled in 
a like manner (by a security module) it makes sense to group them under a 
common mime opaque type.  This is about a 2 page RFC - more if you want it to 
include the OIDs.  

Mike

X400-Received: by /c=US/admd=attmail/; Relayed; 11 Jul 97 11:45:49 -0800
X400-Received: by mta BofA-MTA in /c=US/admd=attmail/; Relayed;  11 Jul 97 11:45:49 -0800
X400-Mts-Identifier: [/c=US/admd=attmail/; 04FE033C67F5D093-attmail]
Content-Identifier: 04FE033C67F5D093
Content-Return: Allowed
X400-Content-Type:  P2-1984 ( 2 )
Conversion: Allowed
Conversion-With-Loss: Allowed
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date: 11 Jul 97 11:45:49 -0800
From: "G. Mack Hicks, VP Bank of America" <[email-masked]>
To: [email-masked]
Subject: RE: CRL Push over S/Mime

For: IETF-PKIX Mailing list

Trevor Freeman said:

It would seem logical to define a series of MIME types for the
certificates in the email replay such as

application/x509-user-cert
application/x509-ca-cert
application/x509-crl-cert
application/x509-cross-cert

<snip>
===============
Would the "x" in the beginning of "ion/x509-" cause confusion with the
"x-" as experimental MIME types. I think all the S/MIME types are "x-".

==================

Trevor said:
Also is there a case for use of a signed S\MIME request message to allow
the email service to authenticate the request.
===========================
IMO the most frequently commercially supported requests of these types
will be between systems that are contracted. That is - they are not
public services - so a signed request is a necessity.

I am at a loss to understand how every MS CA and Netscape CA (thousands
-- maybe millions? scary) is going to start PUSHing out their CRLs to
unsuspecting repositories and directories. Will this really scale? It
seems more likely that these "small" regional or intracompany CAs will
contract with repositories to provide certificate validation services on
their behalf.

Is the world really served well by PUSHed, replicated, cached, and
spread around CRLs? I think not.

The point is that the receiver of a document which is signed must make a
decision whether the cost and effort of validating a certificate is
worth it. If the "cost and effort" seem to be "free" (which seems to be
the case for the PUSHed CRL to all repositories and directories), then
the cost is hidden from the receiver - and the receiver will not make an
informed decision. The receiver will also have to believe CRLs PUSHed to
her from parties (unfamiliar CA's and repositories) where there is no
contractual relationship or even legal recourse.

Date: Fri, 11 Jul 1997 14:13:50 -0400
From: "Hoffman, Mort" <[email-masked]>
Subject: RE: SET Root CA Extension
To: "'Hoffman, Mort'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

You're right, we should have published a full analysis.  It didn't
happen.  This was developed for SET where the root is used only to sign
a small, select group of brands which aren't going to be easily given to
accept a bogus root, and have significant control of the processing
infrastructure.  In SET the brands issue notice of the collection of
CRLs needed to process SET messages, so that the compromised root should
be quickly cut off.  The Brands are in a position to mediate competing
claims, and the hash provides a mechanism to authenticate that it is the
root the brands are accepting.  Obviously not a complete description,
but I hope it gives you the outline.

The trust relies not only on the obvious root-based hierarchy, but also
on the Brand's ability to manage the trust to be given the root.

Mot

>----------
>From: 	Stephen Kent[SMTP:[email-masked]]
>Sent: 	Friday, July 11, 1997 1:58 PM
>To: 	Hoffman, Mort
>Cc: 	[email-masked]'
>Subject: 	RE: SET Root CA Extension
>
>Mort,
>
>	If the next CA key is compromised, the attacker could start issuing
>new certs under a self-signed cert containg that key, amd they would appear
>to be legitimate relative to the old CA key (which contains the hash of the
>new key).  If one issues some sort of "recall" on what was supposed to be
>the next CA key, using the old CA key, how is that distinguished from a
>compromise of the old CA key, where the attackers try to convince users not
>to believe the transition to the new key?  There may be design a tradeoff
>between responses to compromises of the current CA key vs. the next CA key.
>As Bob pointed out, one needs to evaluate the options relative to a threat
>model, and one also needs the algortihmic description of what the
>certificate processing software response should be as a result of receiving
>various certs, CRLs, etc.  Only in that context can one evaluate the
>efficacy of different proposals.
>
>Steve
>
>
>

Date: Fri, 11 Jul 1997 13:58:21 -0400
To: "Hoffman, Mort" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SET Root CA Extension
Cc: "[email-masked]'" <[email-masked]>

Mort,

	If the next CA key is compromised, the attacker could start issuing
new certs under a self-signed cert containg that key, amd they would appear
to be legitimate relative to the old CA key (which contains the hash of the
new key).  If one issues some sort of "recall" on what was supposed to be
the next CA key, using the old CA key, how is that distinguished from a
compromise of the old CA key, where the attackers try to convince users not
to believe the transition to the new key?  There may be design a tradeoff
between responses to compromises of the current CA key vs. the next CA key.
As Bob pointed out, one needs to evaluate the options relative to a threat
model, and one also needs the algortihmic description of what the
certificate processing software response should be as a result of receiving
various certs, CRLs, etc.  Only in that context can one evaluate the
efficacy of different proposals.

Steve

Date: Fri, 11 Jul 1997 13:26:01 -0400
From: "Hoffman, Mort" <[email-masked]>
Subject: RE: SET Root CA Extension
To: "'Santosh Chokhani'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Steve,

If the next key is compromised, you don't have to fix the problem as
fast.  Moreover, you can reissue a new certificate for the current
generation (since it's private key is intact) which contains a new hash
for a different next generation public key (since the hash is of the
public key rather than the certificate).

Mort

>----------
>From: 	Stephen Kent[SMTP:[email-masked]]
>Sent: 	Friday, July 11, 1997 12:30 PM
>To: 	Santosh Chokhani
>Cc: 	[email-masked]
>Subject: 	Re: SET Root CA Extension
>
>Santosh,
>
>	You make a good point too.  In the face of a compromise, the
>already distributed certs have a fixed value suitable for identifying the
>next CA key, whereas merely pre-signing the new cert leaves open the
>possibility that a compromised CA key (as opposed to a loss of use of a CA
>key) could be used to create new, bogus CA certs.  However, if the proposed
>next CA key is compromised, it would seem that we have the reverse problem,
>i.e., it becomes hard to issue a different, next CA key because all of the
>existing certs believe that they have the definitive hash value for the
>next CA key.  As Bob points out, one needs a threat model to evaluate the
>relatibve merits of these alternative approaches.  For example,in some
>instances the backup CA private key, because it is not being used, may be
>more suspecptible to (undetected) compromise, whereas the operational key
>is afforded better protection precisely because of its continued use.
>
>Steve
>
>
>

Date: Fri, 11 Jul 1997 10:56:46 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Year 2000 roll-over

I don't recall what we finally decided would be the roll-over year for
UTCTime after 1 Jan 2000.  Was it 1 Jan 2050?

Did we specify this in PKIX, or as an amendment to X.509, or elsewhere?  In
other words, is the roll-over date universally agreed to?

It won't be my problem, presumably, but I don't want to have to fix it again
any time soon.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

Date: Fri, 11 Jul 1997 10:02:57 -0700
From: David Marquardt <[email-masked]>
Reply-To: [email-masked]
Organization: Prospect Systems
To: [email-masked]
Subject: subscribe ietf-pkix

subscribe ietf-pkix

Date: Fri, 11 Jul 1997 12:30:10 -0400
To: Santosh Chokhani <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SET Root CA Extension
Cc: [email-masked]

Santosh,

	You make a good point too.  In the face of a compromise, the
already distributed certs have a fixed value suitable for identifying the
next CA key, whereas merely pre-signing the new cert leaves open the
possibility that a compromised CA key (as opposed to a loss of use of a CA
key) could be used to create new, bogus CA certs.  However, if the proposed
next CA key is compromised, it would seem that we have the reverse problem,
i.e., it becomes hard to issue a different, next CA key because all of the
existing certs believe that they have the definitive hash value for the
next CA key.  As Bob points out, one needs a threat model to evaluate the
relatibve merits of these alternative approaches.  For example,in some
instances the backup CA private key, because it is not being used, may be
more suspecptible to (undetected) compromise, whereas the operational key
is afforded better protection precisely because of its continued use.

Steve

Date: Fri, 11 Jul 1997 12:24:39 -0400
To: Ebbe Hansen <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SET Root CA Extension
Cc: "[email-masked]" <[email-masked]>

Ebbe,

	I conceur with Bon, that the advantage you describe is a good one,
i.e., being able to specify the next CA key, without constaining the CA
cert validity interval.  One might be able to achieve a similar effect by
periodically signing new (next) CA certs, but this is cleaner.

Steve

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Format for certificates distribued via email
Date: Fri, 11 Jul 1997 09:25:33 -0700

I have herd conflicting views on how the certificate should be formatted
for distribution via email. These fall into two camps. 
The certificate should be either  as a DER encoded binary file
attachments or 
as the degenerate pkcs#7 format. 
The main factor for the former would be its simplicity and that is does
not require a ASN.1 aware server so can easily be implemented by
conventional tools. The main factor in favour of the later would be that
some s/mime implementation already support this mechanism.
Where does the balance of opinion lie for inclusion into a pkix
standard?

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel:  UK(+44) 1734 270412 
Fax: UK(+44) 1734 270435

Date: Fri, 11 Jul 1997 12:00:29 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Re[2]: FW: CRL Push over S/Mime

> From [email-masked] Thu Jul 10 22:10:03 1997
> From: [email-masked] (Mike St. Johns)
> 
> 
> I keep thinking that the right way to do this is to define:
> 
> 
> 
> TaggedObject ::= SEQUENCE {
>    tag            OBJECT IDENTIFIER,
>    object         ANY DEFINED BY tag }
> 
> 
> 
> And then define the mime type as application/security-object or some such.  
> Then give each high-level construct (certificate, CRL, etc) an OID to identify
> it if it doesn't already have one.  Since the objects are generally handled in
> a like manner (by a security module) it makes sense to group them under a 
> common mime opaque type.  This is about a 2 page RFC - more if you want it to 
> include the OIDs.  

I really like this idea.  As an application developer, I want one
container that can have a single cert, a (full or partial) cert
path, or a cert path plus applicable CRL(s).  There is no standard
way of doing this - X.509 defines a two different syntaxes for cert
paths, PKCS 7 has a different syntax which includes CRLs, SSL
concatenates BER certificates in an SSL-notation vector, and I was
just going to punt and use SEQUENCE OF Certificate for lack of
anything better.

Please write the RFC, and include the OID (a single one would suffice
for the cert/path/CRL structure) and structure definitions!  :-)

Lots of people could use it.

X400-Received: by /c=US/admd=attmail/; Relayed; 11 Jul 97 08:20:28 -0800
X400-Received: by mta BofA-MTA in /c=US/admd=attmail/; Relayed;  11 Jul 97 08:20:28 -0800
X400-Mts-Identifier: [/c=US/admd=attmail/; 05B7F33C64F3C033-attmail]
Content-Identifier: 05B7F33C64F3C033
Content-Return: Allowed
X400-Content-Type:  P2-1984 ( 2 )
Conversion: Allowed
Conversion-With-Loss: Allowed
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date: 11 Jul 97 08:20:28 -0800
From: "G. Mack Hicks, VP Bank of America" <[email-masked]>
To: [email-masked]
Subject: Re: Cross Certification and Certificate Path Processing

For: [email-masked]

At 06:26 PM 7/10/97 UT, Michael Leahy wrote:
>Hi
>
>When you Cross Certify with another certification authority what
implications (if any) does this have on the Certificate Path Processing
procedure (i.e. How should you process the cross certificate within the
certification path processing procedure) ?
>
>Regards
>Michael Leahy
>ISOCOR
>

In Warwick Ford and Michael Baums recent book- "Secure Electronic
Commerce", there are eight references to certificate path processing in
the index. For those without access to the X509 documents, this book
makes an excellent reference for PKI matters near and far.

See "Secure Electronic Commerce" Prentice-Hall
  ISBN 0-13-476342-4

From: Trevor Freeman <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: CRL Push over S/Mime
Date: Fri, 11 Jul 1997 07:07:11 -0700

It would seem logical to define a series of MIME types for the
certificates in the email replay such as

application/x509-user-cert
application/x509-ca-cert
application/x509-crl-cert
application/x509-cross-cert

For completeness it would seem also logical to define a series of  bp15
oid's for X.400
 based mail systems. Should we allocate oid's from the pkix oid, or is
there a more appropriate source.

Also is there a case for use of a signed S\MIME request message to allow
the email service to authenticate the request.

Trevor

Date: Fri, 11 Jul 1997 00:58:50 -0700
From: Nick Zhang <[email-masked]>
Reply-To: [email-masked]
Organization: EIT
To: "Mike St. Johns" <[email-masked]>
CC: "Housley, Russ" <[email-masked]>, [email-masked], Peter Williams <[email-masked]>, [email-masked]
Subject: Re: FW: CRL Push over S/Mime

Mike St. Johns wrote:

> I keep thinking that the right way to do this is to define:
>
> TaggedObject ::= SEQUENCE {
>    tag            OBJECT IDENTIFIER,
>    object         ANY DEFINED BY tag }
>

Why bother when you already have ContentInfo which can do the same
thing?Besides, all S/MIME data types are ContentInfo inside a MIME
wrapper.
As a matter of fact, there is only one content type, i.e.,
"application/pkcs7-mime", --this
is a sort of a principle of S/MIME, stupid or not, if anybody care to
argue
(I keep thinking S/MIME has nothing to do with MIME at all. Why people
choose
S/MIME instead of elegant MOSS?).

> Then give each high-level construct (certificate, CRL, etc) an OID to
> identify
> it if it doesn't already have one.  Since the objects are generally
> handled in
> a like manner (by a security module) it makes sense to group them
> under a
> common mime opaque type.  This is about a 2 page RFC - more if you
> want it to
> include the OIDs.

Actually the only thing needed here would just be an oid if S/MIME was
really
something you want--not even worth "a 2 page RFC".

But again, back to the original question, why S/MIME? The thing we are
really
looking for is a pushed schme for Certificate/CertChain/CRL
distribution, right?
IMHO, there are 3 interwoven solutions:
1) MIME content-type "application/x509" and "application/crl", etc. In
addition,
a Content-Disposition header is defined for "application/x509" to tell
where to find CRL.
2) URL, something like "http://www.foo.bar/mycert.cer". I think someone
has already
proposed this as an alternative operation protocol and I believe this is
the way for
search engines to get to them.
3) an URL embeded in a "message/external" typed object points to a CA's
CRL.
I think this is suitable for CRL because it might be a very very long
list and no
good to push them around all the time.

--nick

From: "Alain Zahm" <[email-masked]>
To: "Michael Leahy" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: ASN1 encoding and decoding rules for 'GeneralName' 
Date: Fri, 11 Jul 1997 08:28:44 +0200

The IMPLICIT rule does not apply to CHOICE and ANY. So you are right in your assomption: i.e. you have to encode CHOICE item tags.

----------
De : Michael Leahy <[email-masked]>
A : [email-masked]'
Objet : ASN1 encoding and decoding rules for 'GeneralName' 
Date : jeudi 10 juillet 1997 18:40

Hi

I question on ASN1 encoding and decoding rules for 'GeneralName' - specifically the following CHOICE

directoryName    [4]   Name   

CertificateExtensions (see ISO/IEC 9594-8:1995(E))  imports 'Name' from informationFramework.  I assume I have to encode and decode any elements of type Name EXPLICITELY regardless of the definition for IMPLICIT tags statement in CertificateExtensions. The reason I assume this is that 'Name' is encoded as a CHOICE. A CHOICE normally needs distinct tags to avoid ambiguity.

So am I correct in my assumption for directoryName ?

Regards and thanks in advance
Michael Leahy
ISOCOR
----------

From: Simon Kennedy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 11 Jul 1997 14:28:49 +1000

subscribe ietf-pkix

To: "Housley, Russ" <[email-masked]>
cc: [email-masked], Peter Williams <[email-masked]>, [email-masked]
Subject: Re: Re[2]: FW: CRL Push over S/Mime 
Date: Thu, 10 Jul 1997 18:53:52 -0700
From: [email-masked] (Mike St. Johns)

> 
> Peter:
> 
> I think that the approch that you provide is a good start, but I think that we 
> need to define a MIME type to wrap the certificate and CRL in.  The MIME type is
> necessary so that the browser can handle them correctly.
> 
> Should we "standardize" anything else in the WWW environment that make it 
> easy for search engines to locate certificates and CRLs?
> 
> Russ

I keep thinking that the right way to do this is to define:

TaggedObject ::= SEQUENCE {
   tag            OBJECT IDENTIFIER,
   object         ANY DEFINED BY tag }

And then define the mime type as application/security-object or some such.  
Then give each high-level construct (certificate, CRL, etc) an OID to identify 
it if it doesn't already have one.  Since the objects are generally handled in 
a like manner (by a security module) it makes sense to group them under a 
common mime opaque type.  This is about a 2 page RFC - more if you want it to 
include the OIDs.  

Mike

Date: Thu, 10 Jul 1997 21:13:35 -0700
To: Michael Leahy <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: Cross Certification and Certificate Path Processing 

You follow the procedure defined in the standard.  Many of the X.509
features, like name and path length constraints and policy mapping, were
designed with precisely this type of certificate in mind.

Warwick

At 06:26 PM 7/10/97 UT, Michael Leahy wrote:
>Hi
>
>When you Cross Certify with another certification authority what
implications (if any) does this have on the Certificate Path Processing
procedure (i.e. How should you process the cross certificate within the
certification path processing procedure) ? 
>
>Regards
>Michael Leahy
>ISOCOR
>
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

X400-Received: by /c=US/admd=attmail/; Relayed; 10 Jul 97 16:18:11 -0800
X400-Received: by mta BofA-MTA in /c=US/admd=attmail/; Relayed;  10 Jul 97 16:18:11 -0800
X400-Mts-Identifier: [/c=US/admd=attmail/; 0214233C56DB3001-attmail]
Content-Identifier: 0214233C56DB3001
Content-Return: Allowed
X400-Content-Type:  P2-1984 ( 2 )
Conversion: Allowed
Conversion-With-Loss: Allowed
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date: 10 Jul 97 16:18:11 -0800
From: "G. Mack Hicks, VP Bank of America" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: PKIX p2 - Intent to submit - SSLv3 LDAPv3 signed response

For:  IETF PKIX mail list

From: Mack Hicks, VP Interactive Banking -Bank of America
                  [email-masked]
      Alan Asaya, VP CertCo, NYC   [email-masked]
      Paul Turner, VP CertCo, NYC  [email-masked]

Regarding the PKIX part 2 - On-line Requests for Validation

We are working with a group in the Internet Council of the National
Automated Clearinghouse Association. ( http://www.nacha.org/ )

We intend to have a pilot this year that will involve various members of
NACHA implementing CAs, subscribers, and repositories.

The current model is that a subscriber receiving a certificate will
contact the subscriber's CA's repository to validate a certificate. This
query must be authenticated. The subscriber's repository will
communicate with the certificate's CA's repository to determine
validity. The subscriber will receive a signed response from their
repository.

The pilot we are proposing wishes to have one CA repository communicate
with another CA repository requesting the validity of a particular
certificate. The communications is authenticated. The CA repositories
will be contracted to support each other in this manner.

There is another part of the pilot that will look at CRL exchange
between repositories on a regular basis. This part of the pilot will be
used to examine distribution of risk between the contracted CAs.

----------------------------------------------------------------------

As part of this test we are developing a submission to the IETF as an
addition to PKIX part 2. The specification will target SSLv3 client
authentication with an LDAP v3 non-critical extension providing a signed
response from the CA's repository on the validity of the certificate.

The outstanding problem is that PKIX part 2 is based on LDAP v2 as has
been noted earlier on this mailing list.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
Mack Hicks (415) 278-7230  -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <[email-masked]>

Date: Thu, 10 Jul 97 14:24:48 
From: "Housley, Russ" <[email-masked]>
Encoding: 3847 Text
To: [email-masked], Peter Williams <[email-masked]>
CC: [email-masked]
Subject: Re[2]: FW: CRL Push over S/Mime

Peter:

I think that the approch that you provide is a good start, but I think that we 
need to define a MIME type to wrap the certificate and CRL in.  The MIME type is
necessary so that the browser can handle them correctly.

Should we "standardize" anything else in the WWW environment that make it 
easy for search engines to locate certificates and CRLs?

Russ

______________________________ Reply Separator _________________________________
Subject: Re: FW: CRL Push over S/Mime
Author:  Peter Williams <[email-masked]> at internet 
Date:    7/8/97 12:24 PM

Sharon Boeyen wrote:

Re an http mechanism - I believe that the draft minutes indicated

> someone was going to submit this to me for inclusion, but there were 
> changes proposed to the minutes and with my temporary loss of
> connectivity I may have missed something. I have received no input on 
> this mechanism to date.

As I remember, there was an http I-D posted, which was going to be 
possibly integrated, appropriately, or at least the author was to be 
invited
to harmonise the material with the PKIX-2 framework. I think
you were the person Sharon who introduced this fact. I certainly 
remember
trying to back up the obvious legitimacy of the approach. As far as I 
can
learn, the only force arguing for the archaic ftp approach was US and 
DoD-based (for
who knows what reason) and logically an http approach would 
functionally replace that mechanism entirely just as http (with 
keep-alive)
has replaced simple ftp-getfile operations everywhere else.

Perhaps accept the following edit to ID-2, part 3 as an indication of 
what minimal changes are required for what I suggested:-

3. Hypertext Transfer Protocol (HTTP)

Some CAs mandate the use of on-line validation services, while 
others distribute CRLs to allow certificate users to perform 
certificate validation themselves.  In general, CAs make CRLs 
available to certificate users by posting them in the Directory. 
The Directory is also the normal distribution mechanism for 
certificates.  However, Directory Services are not available in
many parts of the Internet today, and the Hypertext Transfer Protocol 
(HTTP), defined in RFC 2068,  offers an alternate method for 
certificate and CRL distribution.

Within certificate extensions and CRL extensions, URI form of 
GeneralName is used to specify the location where issuer 
certificates and CRL may be obtained.  For instance, a URI 
identifying the subject of a certificate can be carried in 
subjectAltName certificate extension. An IA5String describes the 
use of anonymous, or authenticated HTTP to fetch certificate or CRL 
information.
For example:

   http://www.netcom.com/sp/spyrus/housley.cer 
   shttp://www.your.org/pki/id48.cer
   https://www.your.org/pki/id48.crl?numberB

Internet users may publish the URI reference to a file that 
contains their certificate on their business card.  This practice 
is useful when there is no Directory entry for that user. HTTP is 
widely deployed, and anonymous HTTP is accommodated by many 
firewalls.  Thus, HTTP is an attractive alternative to Directory 
access protocols for certificate and CRL distribution.

For convenience, the names of files that contain certificates 
should have a suffix of ".cer".  Likewise, the names of files that 
contain CRLs should have a suffix of ".crl". Files that contain 
both certificates and CRLs should have a suffix of ".p7c".

Note that this service satisfies the the requirement to retrieve 
information related to a certificate which is already identified by 
a URI. It is not intended to satisfy the more general problem of 
finding a certificate for a user about whom some other information, 
such as their email address or corporate affiliation, is known.

Date: Thu, 10 Jul 1997 12:24:27 +0100
From: Peter Williams <[email-masked]>
To: Michael Leahy <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Cross Certification and Certificate Path Processing

If you are following the X.509 procedure for cert path validation (which
all conforming implementations
will do)  it doest make any direct impact. All signals and constraints
to guide the validation procedure
are inband to the cert, CA cert or cross-cert equally - and enforced by
conformant semantic handling of the
extensions and the algorithm.

Many sites will soon have a local CA. (why ever not?! an RSA cert server
and CA is slated to come free with
the NT Server IIS4 web server, and Netscape's  multi-platform cert
server only costs $1000 :-) ) and thus may use
it to issue "cross-certs" to important connection-points in the various
external domains recognised by that
local policy. Will a consumer in the remote domain append said
cross-cert to the chain? One assumes not,
but one can assume local server may "reorganize" the chain by appending
the relevant cross-cert, and
then passing it to the std algoirhtm for enforcement where the local
policy rules in the cross-cert control.

The more advanced ISO extension provide lots of jurisidictional control
mechanism, which PKIX allows
conforming systems to use as non-critical elements to instrument local
policy.

Hope this helps broaden the issue. The relevant PKIX point is perhaps
the need for conforming
implementations at UAs to implement the ISO validatation algorithm
correctly. I cannot remember whether SET
took my advice to mandate said algoirhtm, but it should too.

Peter.

Michael Leahy wrote:

> Hi
>
> When you Cross Certify with another certification authority what
> implications (if any) does this have on the Certificate Path
> Processing procedure (i.e. How should you process the cross
> certificate within the certification path processing procedure) ?
>
> Regards
> Michael Leahy
> ISOCOR

Date: Thu, 10 Jul 1997 18:26:59 UT
From: Michael Leahy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Cross Certification and Certificate Path Processing 

Hi

When you Cross Certify with another certification authority what implications (if any) does this have on the Certificate Path Processing procedure (i.e. How should you process the cross certificate within the certification path processing procedure) ? 

Regards
Michael Leahy
ISOCOR

From: John Marchioni <[email-masked]>
To: "'John Kennedy'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: RSA mandatory for PKIX CMP?!
Date: Thu, 10 Jul 1997 10:42:29 +0100

I agree, well said and with the right amount of words.

- John

-----Original Message-----
From:	John Kennedy [SMTP:[email-masked]]
Sent:	Thursday, July 10, 1997 5:35 PM
To:	[email-masked]; [email-masked]
Subject:	Re: RSA mandatory for PKIX CMP?!

Words of wisdom.

-John

------------------------------------------------------------------------------------------------------------
John C. Kennedy
Cryptographic Systems Architect, Internet Infrastructure Division
+1 (801) 861-5282 ;  [email-masked]
Novell, Inc., 122 East 1700 South, M/S PRV-F221, Provo, UT 84606
--------------------------------------------------------------------------------------------------------------

>>> <[email-masked]> 07/09/97 07:12PM >>>
All--

If this debate can take yet one more voice, Dave Kemp makes a convincing
argument.  There is no compelling reason to mandate any cryptosuite.   In
fact, given the penetration of RSA and the cost attractiveness of DSA, PKIX
implementors would be well advised to prepare for operating with both, thus
making the point largely moot.  All we need PKIX to do is provide us a
standard specification with which to do so.

--Mike

Michael Myers
[email-masked] 
(415) 429-3402

>Date: Tue, 8 Jul 1997 09:10:25 -0400
>From: [email-masked] (David P. Kemp)
>Message-Id: <[email-masked]>
>To: [email-masked] 
>Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)
>X-Sun-Charset: US-ASCII
>
>> From: [email-masked] (Amit Kapoor)
>> 
>> I had a minor email exchange with Carlisle Adams on the same point.
>> I disagree with the use of RSA for the same reasons mentioned
>> by John Marchioni & Li Gong.
>> 
>> I think it would make more sense to use DSA and D-H as the
>> mandatory algorithms. Reasons:
>
>
>As an employee of a government which until recently tried to make
>DSA mandatory, I believe that is the wrong approach.
>
>The purpose of IETF mandatory algorithms is to attempt to guarantee
>interoperability between all conforming implementations.  But TLS (SSL)
>has no mandatory supported algorithms and yet market forces have resulted
>in a substantial degree of interoperability between SSL implementations.
>To date, that interoperability has been RSA-based, but there is support
>for DSA/DH in both commercial and free (SSLeay) implementations.  If
>the costs (monetary, administrative, and performance) of fielding
>RSA-based solutions become too onerous, as they clearly have recently
>for some segments of the marketplace, DSA (or perhaps EDSA) will gain
>market share to the point where interoperability is no longer a
>concern for DSA-only implementations.
>
>Speaking from experience, I doubt that the regulatory approach of
>mandating *any* algorithm set will accelerate that process.  I
>recommend that PKIX profile the use of RSA, DSA, and EDSA, but not
>make any of them a MUST-implement.
>
>

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: Eric Jacksch <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: PLEASE REMOVE ME FROM THIS LIST
Date: Thu, 10 Jul 1997 13:26:40 -0400

Sorry to spam you all, but unsubscribe doesn't appear to work.

Please remove me ([email-masked], [email-masked],
[email-masked], [email-masked]) from the list.  I appear to be in
there at least twice.

Thanks, and again, sorry to spam the rest of you.

Eric.

Date: Thu, 10 Jul 1997 16:40:22 UT
From: Michael Leahy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: ASN1 encoding and decoding rules for 'GeneralName' 

Hi

I question on ASN1 encoding and decoding rules for 'GeneralName' - specifically the following CHOICE

directoryName    [4]   Name   

CertificateExtensions (see ISO/IEC 9594-8:1995(E))  imports 'Name' from informationFramework.  I assume I have to encode and decode any elements of type Name EXPLICITELY regardless of the definition for IMPLICIT tags statement in CertificateExtensions. The reason I assume this is that 'Name' is encoded as a CHOICE. A CHOICE normally needs distinct tags to avoid ambiguity.

So am I correct in my assumption for directoryName ?

Regards and thanks in advance
Michael Leahy
ISOCOR

Date: Thu, 10 Jul 1997 10:34:41 -0600
From: John Kennedy <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RSA mandatory for PKIX CMP?!

Words of wisdom.

-John

------------------------------------------------------------------------------------------------------------
John C. Kennedy
Cryptographic Systems Architect, Internet Infrastructure Division
+1 (801) 861-5282 ;  [email-masked]
Novell, Inc., 122 East 1700 South, M/S PRV-F221, Provo, UT 84606
--------------------------------------------------------------------------------------------------------------

>>> <[email-masked]> 07/09/97 07:12PM >>>
All--

If this debate can take yet one more voice, Dave Kemp makes a convincing
argument.  There is no compelling reason to mandate any cryptosuite.   In
fact, given the penetration of RSA and the cost attractiveness of DSA, PKIX
implementors would be well advised to prepare for operating with both, thus
making the point largely moot.  All we need PKIX to do is provide us a
standard specification with which to do so.

--Mike

Michael Myers
[email-masked] 
(415) 429-3402

>Date: Tue, 8 Jul 1997 09:10:25 -0400
>From: [email-masked] (David P. Kemp)
>Message-Id: <[email-masked]>
>To: [email-masked] 
>Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)
>X-Sun-Charset: US-ASCII
>
>> From: [email-masked] (Amit Kapoor)
>> 
>> I had a minor email exchange with Carlisle Adams on the same point.
>> I disagree with the use of RSA for the same reasons mentioned
>> by John Marchioni & Li Gong.
>> 
>> I think it would make more sense to use DSA and D-H as the
>> mandatory algorithms. Reasons:
>
>
>As an employee of a government which until recently tried to make
>DSA mandatory, I believe that is the wrong approach.
>
>The purpose of IETF mandatory algorithms is to attempt to guarantee
>interoperability between all conforming implementations.  But TLS (SSL)
>has no mandatory supported algorithms and yet market forces have resulted
>in a substantial degree of interoperability between SSL implementations.
>To date, that interoperability has been RSA-based, but there is support
>for DSA/DH in both commercial and free (SSLeay) implementations.  If
>the costs (monetary, administrative, and performance) of fielding
>RSA-based solutions become too onerous, as they clearly have recently
>for some segments of the marketplace, DSA (or perhaps EDSA) will gain
>market share to the point where interoperability is no longer a
>concern for DSA-only implementations.
>
>Speaking from experience, I doubt that the regulatory approach of
>mandating *any* algorithm set will accelerate that process.  I
>recommend that PKIX profile the use of RSA, DSA, and EDSA, but not
>make any of them a MUST-implement.
>
>

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Thu, 10 Jul 1997 08:50:30 -0700
From: "Todd Glassey, Chief Technical Officer" <[email-masked]>
Organization: Coastek Infosys, Inc.
To: Li Gong <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Lawsuit Time: RSA mandatory for PKIX CMP?!, can working groups really do this?

I have watched this process happen in several working groups to date,
especially the IPv6 efforts that mandate ISAKMP/Oakley... and I have a
policy and process question:

"Is this an issue with IETF and it'as policies, because if it is, then
by the same token the IP/v6 WG cannot favor any specific IPSEC WG
standards (SKIP or ISAKMP/Oakley)."

Personally I feel that if the IETF is to retain it's A-political stance
as a technologies forum, it's body and WG's cannot endorse or make
mandatory any foreign WG component standard(s) by todays charters... I
would think that unless it is going to create a new class of working
groups that have deliverable built as composites of ther standards
committees effort, that the clear violation of the charters is in
reality malfeasance.

The net effect of questioning this existing process is that by denying
the right of the WG to mandate specific complicity in the development
and roll-out of a standard, a very big piece of IPSEC's IPv6 thunder has
vanished in a cloud of policy. Personally I favor this concept.

keeping our eyes on the ball, the bottom line is "does the endoresement
of any specific deliverable technologies" violate the charter of the
IETF and it's sattellite working groups?. I think that in most instances
it does and is grounds for a cause of action against the IETF and it's
officers.

The above is my personal opinion and in no way reflects my company's
opinions.

Todd Glassey
Chief Technical Officer
Coastek Infosys, Inc.

Li Gong wrote:

> Hi,
>
> I do not normally follow this mailing list, so apologies for posting.
> It has recently been brought to my attention that certain IETF
> standards (PKIX draft in particular) are proposing to make RSA a
> "mandatory" feature.
>
> This is clearly unacceptable for the Java platform.
>
> The main problem is that RSA public key technology is not available
> royalty free on the Java platform (when I say royalty free, I mean
> that you can include an RSA implemention in your Java-based product
> and expose the RSA APIs without the fear of ending up in some court).
>
> Until RSA public key technology becomes freely available on the Java
> platform, picking RSA as a mandatory feature will not help but to
> derail a potential IETF standard, because developers on the Java
> platform will likely be forced to adopt an alternative feature.
>
> By the way, the *only sure sign* that RSA is freely available in Java
> is when JavaSoft ships an exposed RSA implementation in the baseline
> Java platform, such as the Java Cryptography Extension (JCE).
>
> Best regards,
>
> Li
> --
> Li Gong, PhD
> Java Security Architect and Senior Engineering Manager
> JavaSoft, Cupertino, California, USA
> Email: [email-masked]
> Web: http://java.sun.com/people/gong
> Tel: 408-343-1825 and Fax: 408-343-1993

Date: Thu, 10 Jul 97 06:28:58 
From: "Housley, Russ" <[email-masked]>
Encoding: 1595 Text
To: [email-masked]
CC: [email-masked]
Subject: Re: PKIX Part1

Hellen:

Yes, PKIX Part 1 specifies the use of PKCS#1.  After hashing the 
DER-encoded certificate-to-be-signed, the hash value and hash algorithm OID 
are placed in DigestInfo.  DigestInfo is encoded, padded, and encrypted 
with the RSA private key.

PKCS#1 is used in many, many implementations.  You are the first person to 
suggest ISO 9796 as ans alternative.  I do not think that there are any 
problems with PKCS#1, and unless a majority of implementors want to use ISO 
9796, then I see no reason to change.

Russ

______________________________ Reply Separator _________________________________
Subject: PKIX Part1
Author:  [email-masked] at internet
Date:    7/9/97 8:05 AM

Russell,

In looking at PKIX part 1, I would like to confirm the exact details of how= 
 
the signature is actually generated.  In particular, I would just like to  
check that after hashing the certificate details, PKIX part 1 expects that  
the hash will be formatted as the  "DigestInfo" field in PKCS#1.

I am also aware of the ISO 9796 formating which, as I understand it adds  
additional redundancy (which can be checked).  Certainly there seems to be = 
a 
push in that direction.  Do you think that the ISO 9796 format should be  
used (possibly as an alternative to PKCS #1 DigestInfo)? If you don't think= 
 
so, do you have any views about ISO 9796 and the justification I mentioned?

Hellen Mullenger
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK 
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901

Date: Wed, 09 Jul 1997 20:34:38 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: Peter Williams <[email-masked]>
CC: [email-masked], Sharon Boeyen <[email-masked]>
Subject: Re: FW: CRL Push over S/Mime

Peter Williams wrote:
> 
> Anil R. Gangolli wrote:
> 
> > I hope this doesn't get lost in all the traffic on the list.
> >
> > Due to the mixed quoting,  I couldn't tell whether the wording was
> > from the I-D, from Peter's suggestion, or Sharon's.
> >
> > Regarding transfer of CRLs using HTTP or HTTPS urls, I object to the
> > I-D dictating anything about the format of the URL.  These are
> > typically
> > dynamically interpreted by servers.
> >
> > The important thing to specify is that the GET method returns
> > a specific a specific content type label (mime type) with content
> > in a specific syntax, or one of a set of content types and syntaxes.
> >
> > Any mention of .cer, .p7c and associated extensions
> > should be at very least separated from the spec proper into an
> > advisory note.  If there at all, it should be very precise about what
> > the expected content is.  Otherwise it has little or perhaps
> > negative value.
> 
> Anil,
> 
> Agreed. I took Russ's existing text, and substituted ftp for http -
> almost
> verbatim. I argued to Sharon, then, the important fact (for both the
> http retreival and
> messaging push issue) that the only additional fact in need of
> standardization
> was the mime content type.
> 
> So, I suspect we are mostly in agreement. We can add a line
> to PKIX-2 part 3 which says - "The example URIs are not required forms
> of URLs suggesting merely
> some possiblities." I just modified Russ original examples to use web
> motifs.
> 
> If Sharon is amenable to the notion, and she is editor
> in charge of Part II & who can give the nod prior to any writing, a mime
> 
> content type can also be specified, as we seem to be agreeing. I have
> already
> suggested reuse of application/x-x509-user-cert
> from Netscape, used in that companies products and some
> of Microsoft's. Perhaps we could specify application/x509-user-cert ??
> 
> Or would it be more correct & useful  to also allow
> application/[x-]x509-ca-cert
> also as an allowed content type return, along with
> application/octet-string?
> 
> Peter.

[My personal feelings on Part II are that it is premature to be
standardizing the CMP area, but given that one is addressing
some of these topics, I think one should try to specify enough
to be of practical utility.  Ok, enough of my subjective b.s.;
some objective statements, hopefully constructive, do follow.]

Re: Certificate and CRL pull over HTTP/HTTPS
----------------------------------------

It sounds like we are in general agreement on these two
points:

- The URL string should not be dictated.

- The method (e.g. GET), the mime type label and the syntax
of the contents must be dictated if the act of specifying
this is to be useful at all to implementors.

Regarding current behavior in MS and NS browsers (3.x up).
The labels in use are:

	application/x-x509-user-cert  (for importing user certs)
	
	application/x-x509-ca-cert    (for importing ca certs)

but the two browsers don't quite agree on what the content
of these can be.  Netscape's is a bit more permissive
allowing the cert to arrive in any of a number of bundling
formats, e.g. straight DER or PKCS7 Certs Only Signed Data
or PKCS7 NS Cert Sequence or base64 encodings of these,
while MSIE accepts only a couple of these.  Here,
to be of practical utility it would be both necessary and
sufficient for the spec to dictate at least one format that
must be accepted by any compliant implementation.

Dealing with detailed semantics of import (e.g. treatment of
individual certs in a bundle) is trickier, and is probably beyond
the scope of the Part II spec.  

If it is any indication of industry direction, Netscape 4.x also has
some
implementation for X.509 CRL import over HTTP.  It was last seen
using the (mis)label

	application/x-pkcs7-crl

associated with the content type DER encoded X.509 CRL.
I expect they would comply if the label application/x-x509-crl
were suggested for this content.

A similar level of specification is needed for the CRL Distribution
Point extension (if still proposed) for the case of an HTTP URL.
[Q: Would this belong in Part I or II?]

Re: Dynamic Revocation Checking over HTTPS
--------------------------------------

There was also a separate thread at one time concerning dynamic
revocation checking.  One version of the Part II I-D had a section
on online revocation checking that did not require a secure channel,
but did require signing on a per-response basis.  HTTPS can provide
similar protections and may scale better in certain environments.

For example, Netscape's browser supports an implementation of
this in which the certificate serial number in hex is
appended to a URL extension present in the end-entity or
CA certificate.  The GET method on this triggers a response with
specific mime type and a single ASCII 0 or 1 as content.  It is not
very expressive, and I do not favor standardizing Netscape's
scheme.  I just wanted to give an example.

To specify this what would be useful is:
 - a cert extension with specific OID and syntax bearing the URL
 - HTTP request method (e.g. GET)
 - Mime type, exact content format, and semantics of the response.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

From: <[email-masked]>
Date: Wed, 09 Jul 1997 19:12:22 -0600
To: [email-masked]
Subject: Re: RSA mandatory for PKIX CMP?!

All--

If this debate can take yet one more voice, Dave Kemp makes a convincing
argument.  There is no compelling reason to mandate any cryptosuite.   In
fact, given the penetration of RSA and the cost attractiveness of DSA, PKIX
implementors would be well advised to prepare for operating with both, thus
making the point largely moot.  All we need PKIX to do is provide us a
standard specification with which to do so.

--Mike

Michael Myers
[email-masked]
(415) 429-3402

>Date: Tue, 8 Jul 1997 09:10:25 -0400
>From: [email-masked] (David P. Kemp)
>Message-Id: <[email-masked]>
>To: [email-masked]
>Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)
>X-Sun-Charset: US-ASCII
>
>> From: [email-masked] (Amit Kapoor)
>> 
>> I had a minor email exchange with Carlisle Adams on the same point.
>> I disagree with the use of RSA for the same reasons mentioned
>> by John Marchioni & Li Gong.
>> 
>> I think it would make more sense to use DSA and D-H as the
>> mandatory algorithms. Reasons:
>
>
>As an employee of a government which until recently tried to make
>DSA mandatory, I believe that is the wrong approach.
>
>The purpose of IETF mandatory algorithms is to attempt to guarantee
>interoperability between all conforming implementations.  But TLS (SSL)
>has no mandatory supported algorithms and yet market forces have resulted
>in a substantial degree of interoperability between SSL implementations.
>To date, that interoperability has been RSA-based, but there is support
>for DSA/DH in both commercial and free (SSLeay) implementations.  If
>the costs (monetary, administrative, and performance) of fielding
>RSA-based solutions become too onerous, as they clearly have recently
>for some segments of the marketplace, DSA (or perhaps EDSA) will gain
>market share to the point where interoperability is no longer a
>concern for DSA-only implementations.
>
>Speaking from experience, I doubt that the regulatory approach of
>mandating *any* algorithm set will accelerate that process.  I
>recommend that PKIX profile the use of RSA, DSA, and EDSA, but not
>make any of them a MUST-implement.
>
>

From: John Marchioni <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: Re: RSA mandatory for PKIX CMP?!
Date: Wed, 9 Jul 1997 16:37:02 +0100

Bob Jueneman wrote:
"But clearly RSA is available on a non-discriminatory
basis to all, so the only issue is cost. I confess that have a certain lack
of sympathy for developers who are too cheap to pay people for their
inventions and all of the work that has gone into building and popularizing
the infrastructure."

Bob -

I think we made the PKIX WG suffer enough on this subject but, with all due respect you need a better appreciation for the commercial issues associated with RSA licensing.  Have you ever negotiated a deal with RSA?  If you have then you can run with the big dogs on this subject, otherwise you should stay on the porch.  I can say with some confidence that the costs involved are a lot more than those associated with an ASN.1 compiler.  As far as your assertion about "clearly non-discriminatory" licensing I suggest you interview some of RSA's licensees and see how happy they really are with the structure of their deals, and further, try to find two deals that are the same (you see non-discriminatory means that no distinction in terms are made between licenses granted).  AND see the included text from the standard BSAFE license which eliminates the possibility of any competing certification service to VeriSign.  I guess you could say that it is non-discriminatory for all as long as "all" is VerisSign and RSA but what about those who wish to enter this market and be IETF PKIX CMP compliant?  Don't you agree that they are being discriminated against?

Again the only pertinent issue, and a responsibility of the RFC editors and WG, is to ensure that the standard does not support an unfair competitive advantage for one or two vendors.  I think there is enough evidence to conclude that if RSA is mandated in the CMP that the editors and WG would be failing to live up to their responsibilities.  So I ask again to focus on this issue and I recommend that RSA not be designated mandatory.  I think this is a reasonable approach we can all live with.

- John

RSA BSAFE OEM License text:

Section "2.3.5 No Certificate Services.  Bundled Products may be created so as to allow End User Customers to issue Certificates solely for the purpose of directly Certifying other End User Customers with whom they exchange data.  Except as expressly set forth in section 2.3.5, nothing in this Agreement shall be construed to grant OEM or any third person a right to use RSA Software to issue certificates to third parties, act as a Certification Authority, or provide Certificate-Issuing services or any fee-generating service associated with the issuance of Certificates."

Section "2.3.6 RSA Root Keys.  Any Bundled product that includes any hierarchy root key must incorporate the RSA/Verisign, Inc. root keys included within the RSA Software (the "RSA Root Keys"), and the RSA Root Keys must be functional within the Bundled Product and as accessible as any other hierarchy root key within the Bundled Product."

Date: Wed, 09 Jul 1997 17:01:50 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SET Root CA Extension

Interesting analysis, Luis.  I particularly liked the remark about such
systems as diskless workstations (the current name seems to be a net PC)
which may not have have any permanent state storage mechanism at all, not
even EEPROM, I suppose.

So the SET approach may not be completely without merit, to say the least. 
The advantages and disadvantages would be difficult to analyze without a
more thorough understanding of the exact threat model.

So where does this leave us with respect to a PKIX methodology?  Should we
leave it as an interesting and potentially useful anomaly and private
extension, or elevate it to a more worthy status?

I've been flamed enough regarding the RSA issue that I don't care to wade
into the standards issue one more time, at least so soon. :-)

Bob

>>> Luis Valente <[email-masked]> 07/09/97 03:50PM >>>
At 10:24 AM 7/9/97 -0600, Bob Jueneman wrote:
>The threat analysis in a system as important as SET is obviously important,
>and a non-trivial exercise. Without knowing more about precisely how their
>keys are generated, by whom, how stored, etc., etc., it may not be possible
>to completely analyze the threat.
>
>But my general approach would be to avoid generating a new root key until a
>time that is near the expiration date of the current key, in order to avoid
>any possible human or institutional threat for as long as possible.
>
>Yes, I agree that this raises the possibility that the original key is
>compromised, and then logically it is impossible to distribute a new one
>without relying on an out-of-band mechanism.  But even if the original root
>key were compromised, assuming it is still in the possession of the
>authorities it can still be used to authenticate a new one -- the only
>problem is that someone else might attempt to spoof that process. But in
>that case, it would be almost impossible to carry out the spoof without
>detection, and so the bogus root key could be ignored.

I think this is the main advantage of the SET root CA extension mechanism
versus a cross-certification mechanism. In the former you do an "early
binding" of the current (active) root key to the next (dormant) root key.
It the current root key is compromised, one can effectively revoke it by
issuing a self-signed certificate for the dormant key which then becomes
the active key. An attacker who successfully compromises the current key
is, thus, thwarted by this revocation mechanism.

Of course, this only makes sense if the root key is used regularly and,
thus, more vulnerable to cryptanalysis and other attacks (e.g., stealing).

It was stated in an earlier message that the dormant key is as vulnerable
as the current key (except wrt cryptanalysis). This is not necessarily the
case. Since the dormant key is not used until it is activated (i.e.,
becomes the current key) it can be stored separately from the current key.
Indeed, the dormant key is also, effectively, a backup key since it can be
used to replace the current key should the latter become unusable.

Another advantage of the early binding created by the SET cert chaining
mechanism is in systems that store a root certificate as part of their
executable image (e.g., in ROM) and must rely on in-band root cert renewal
schemes.

Disclaimer: I was not involved in the definition of SET; the opinions
expressed above are my own.

/Luis

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

           

Date: Wed, 09 Jul 1997 14:50:50 -0700
To: [email-masked]
From: Luis Valente <[email-masked]>
Subject: Re: SET Root CA Extension

At 10:24 AM 7/9/97 -0600, Bob Jueneman wrote:
>The threat analysis in a system as important as SET is obviously important,
>and a non-trivial exercise. Without knowing more about precisely how their
>keys are generated, by whom, how stored, etc., etc., it may not be possible
>to completely analyze the threat.
>
>But my general approach would be to avoid generating a new root key until a
>time that is near the expiration date of the current key, in order to avoid
>any possible human or institutional threat for as long as possible.
>
>Yes, I agree that this raises the possibility that the original key is
>compromised, and then logically it is impossible to distribute a new one
>without relying on an out-of-band mechanism.  But even if the original root
>key were compromised, assuming it is still in the possession of the
>authorities it can still be used to authenticate a new one -- the only
>problem is that someone else might attempt to spoof that process. But in
>that case, it would be almost impossible to carry out the spoof without
>detection, and so the bogus root key could be ignored.

I think this is the main advantage of the SET root CA extension mechanism
versus a cross-certification mechanism. In the former you do an "early
binding" of the current (active) root key to the next (dormant) root key.
It the current root key is compromised, one can effectively revoke it by
issuing a self-signed certificate for the dormant key which then becomes
the active key. An attacker who successfully compromises the current key
is, thus, thwarted by this revocation mechanism.

Of course, this only makes sense if the root key is used regularly and,
thus, more vulnerable to cryptanalysis and other attacks (e.g., stealing).

It was stated in an earlier message that the dormant key is as vulnerable
as the current key (except wrt cryptanalysis). This is not necessarily the
case. Since the dormant key is not used until it is activated (i.e.,
becomes the current key) it can be stored separately from the current key.
Indeed, the dormant key is also, effectively, a backup key since it can be
used to replace the current key should the latter become unusable.

Another advantage of the early binding created by the SET cert chaining
mechanism is in systems that store a root certificate as part of their
executable image (e.g., in ROM) and must rely on in-band root cert renewal
schemes.

Disclaimer: I was not involved in the definition of SET; the opinions
expressed above are my own.

/Luis

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: PKIX part 2 - additional mechanisms
Date: Wed, 9 Jul 1997 15:06:43 -0400

I think I'm clear on the email mechanism status - there appears to be
significant support on the list for adding an email mechanism for
retrieval certs and crls, but I don't think we've addressed the overall
security requirements for that mechanism or the others fully. Trevor
Freeman, based on some earlier discussion on the list back in April has
agreed to draft that mechanism and plans to provide it to me by Monday
for inclusion in the revised I-D. (Trevor - Tuesday is fine too, because
I'm having a root canal done Monday morning and don't expect to be
editing that day!).

As for the http mechanism, I do apologize for still being a bit confused
as to where we stand. I went back through some old messages trying to
piece together where we left both of these issues and attached is the
action item I mentioned from the Memphis meeting. Does anyone remember
whether the scope of what was envisaged here is close to what is now
being discussed. I don't think we need discussion on whether or not the
mechanism should be added, since it was accepted as an action item in
Memphis (I assume the minutes were modified as indicated below). If
Hiroaki is on this list, I'm interested in his views on the discussion
so far and curious whether any contribution from him is forthcoming for
PKIX part 2.

------------------
NOTE: WE'VE MOVED 

Sharon Boeyen                  
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario Canada K1V 1A7

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

>----------
>From: 	Housley, Russ[SMTP:[email-masked]]
>Sent: 	April 23, 1997 2:37 PM
>To: 	[email-masked]; Warwick Ford
>Subject: 	Re: Draft Memphis PKIX Minutes
>
>
>Warwick:
>
>The draft minutses say:
>
>   Hiroaki accepted the invitation to contact Russ Housley regarding
>any 
>   contributions he desires to produce for Part 2.
>
>They should say:
>
>   Hiroaki accepted the invitation to write a contribution for Part 2 
>   dealing with the use of HTTP for obtain certificates and CRLs from a
>
>   repository.
>
>Russ
>

From: Amit Kapoor <[email-masked]>
Subject: Re: [Fwd: Re: FW: RSA mandatory for PKIX CMP?! (fwd)]
To: [email-masked] (Bob Jueneman)
Date: Wed, 9 Jul 1997 12:27:52 -0700 (PDT)
Cc: [email-masked] (pkix)

<snip>
You wrote:
> 
> I don't work for RSA, nor for one of their competitors, and I don't have
> stock in any of those companies. As a result I don't really give a fig which
> way the argument goes.

My apologies Bob.  I assumed from your first message that you were in
favour of using RSA.  Since you really do not care, lets drop this and
allow people who care about using RSA to present their arguments.

cheers-

Amit

<snip>

Date: Wed, 9 Jul 1997 15:02:11 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [Fwd: Re: FW: RSA mandatory for PKIX CMP?! (fwd)]

> >(PS:  Someone I know just mentioned that RSA is not extensible to
> >      Elliptic curve cryptosystems?  Is this true?)
> 
> I can't even fathom what you mean. The two are different algorithms.

It means that the Integer Factorization hard mathematical problem
on which RSA is based has no equivalent over Elliptic Curve groups.

Whereas the Discrete Logarithm problem, on which Diffie-Hellman and
DSA is based, does.

The equations for computing DSA signatures in modular finite field
arithmetic translate straightforwardly into equivalent equations for
computing EDSA signatures using Elliptic Curve group operations.  If
you call the EC operator * instead of the traditional +, the equations
even look the same :-).

How is this PKIX-relevant?  I don't know :-).  But I agree that PKIX
should profile the use of EDSA in addition to DSA and RSA.

Date: Wed, 09 Jul 1997 12:07:02 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Fwd: Re: FW: RSA mandatory for PKIX CMP?! (fwd)]

>Forwarded message:
>> 
>> "The wonderful thing about standards is that there are so many to chose
>> from."
>
>Let us make the right choice then :)

Maybe my late night attempt at humor was misinterpreted.  I was merely
observing that RSA has already captured what I would guess is probably 90%
of the software market for signature and key exchange algorithms, and
therefore, if you want to be able to interoperate with what is already out
there, that's probably what you should support. That's what I meant by the
de facto choice, irrespective of either technical merits of cost
considerations.

So my personal belief is that if the IETF wishes to recommend an algorithm
in order to facilitate interoperability, RSA is the obvious, market-driven
choice. But why does it matter -- if someone chooses to support DH/DSA, or
SKIPJACK/CAPSTONE, or whatever the Brits use, is the IETF going to jerk
their Good Housekeeping Seal of Approval?
>
>> 
>> RSA is the obvious, de facto choice if the IETF wishes to support
>> interoperability.
>
>I have lots (and lots)+ of problems with the above statement.
>
>1.  Obvious?  It is not obvious to quite a few of us.  Will it be obvious
>    to software developer's when they have to purchase a RSA patent license
>    just to get a certificate issued from a CA?  Can Joe Developer
>    get RSA toolkit/license to write a CA/CMP at a affordable cost?
>    Or is the paradigm that CA/CMP is for a selected elite only and
>    the IETF standard should mandate that?

This raises some very real questions about what the role of the IETF is, and
the role of voluntary standards in general. Clearly that role is advisory,
and not compulsory, so if Joe Developer chooses to develop a system that
does not implement RSA (or any other "mandated" algorithm) he is free to do
so. He is also free to starve to death, when his system doesn't sell!

I'd be curious to learn how many developers are really going to go out and
role their own crypto implementations, and not use such toolkits such as
BSAFE.

Granted the rather academic, "everything on the Internet should be a God
given right to use without paying a cent" tradition, I can understand a
desire to avoid enshrining a proprietary standard. I can also understand the
US Government trying to do that with DSA, and why the insurance companies
would like to restrict you to using only generic drugs, and not pay for the
R&D that goes into new developments. But I don't believe that any of those
approaches have been or will be successful in the marketplace.  Even with
the force of a FIPS standard, and government procurements behind them, the
US government hasn't been able to make DSS stick to the wall, and they have
now effectively given up.  The FIPS standard is going to be rewritten to
include RSA and perhaps other commercial algorithms.

>
>2.  "de facto choice".  When did this happen :)

"De facto" means "as a matter of fact."  And that has happened over the last
20 years -- the market has essentially spoken.  Not that that means that new
algorithms can never be introduced.
>
>3.  "support interoperability".  I am very sure that IETF can support
>    interoperability with DSA/D-H also :).  RSA is not the only algorithm
>    which allows interoperability.  Please correct me if I am wrong.

Sure.  But I am assuming that only one algorithm was going to be nominated
as the minimum recommendation for interoperability.  Are you suggesting an
entire suite be so nominated? Now how about your poor Joe Developer, who has
to implement a bunch of algorithms that probably won't get used?
>
>4.  The stated reason is again *not* technical.  Againist all non-techinal
>    reasons a lot of us will keep raising the fact that RSA is available
>    only to a *selected few*, not what the purpose of a IETF standard
>    should be.  Please also refer to Li Gong's message about what it
>    means for RSA to be available to everyone (substitute Java with
>    whatever platform :))

I don't work for RSA, nor for one of their competitors, and I don't have
stock in any of those companies. As a result I don't really give a fig which
way the argument goes.  But clearly RSA is available on a non-discriminatory
basis to all ,so the only issue is cost. I confess that have a certain lack
of sympathy for developers who are too cheap to pay people for their
inventions and all of the work that has gone into building and popularizing
the infrastructure. This was the same kind of argument that was raised
regarding ASN.1 and other standards.  "We can't afford to buy a compiler."
Then choose another line of work! If you want to keep up with the big dogs,
you have to run in the tall grass.  RSA is table-stakes for any commercial
developer, but that doesn't mean that I am going to hold a gun to someone's
head if they choose to go a different direction. Call me elitist if you
will. Mea culpa.

>
>> Perhaps "mandatory" is too strong, but if a PKIX
>> implementation chooses to only implement DSA, or some government's
>> proprietary (or even secret) signature and/or key exchange algorithm,
will
>> the Internet police descend upon them and drag them off to some Dragon
>> infested Dungeon?
>
>I am missing your point in the above statement.  Are you saying DSA is
>proprietary or that its algorithm is secret as compared to RSA? And what
>Internet police :) ???

The UK government has their own proprietary signature and/or key exchange
algorithm, which they are apparently insisting on for their procurements,
just as the US government (used to) insist on DSA.  And my sardonic
reference to the Internet police was intended to highlight the fact that an
IETF "Request For Comments" is a long, long way from being a legally
compulsory requirement.  Compliance with the RFC may turn out to be a
_market_ requirement, but so may the provision of a well-known algorithm
such as RSA, regardless of what the IETF decides. So roll the dice, and
implement whatever you think will sell. It's a free country.
>
>I have no problems with "mandatory", just what the spec is making
>mandatory :).  As in response to Kemp's message, I had stated that
>it makes sense to make one algorithm manadatory to provide for
>interoperability, the whole point for all of us to be spending time
>on this.
>
>cheers-
>
>Amit
>(PS:  Someone I know just mentioned that RSA is not extensible to
>      Elliptic curve cryptosystems?  Is this true?)

I can't even fathom what you mean. The two are different algorithms.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                       

Date: Wed, 09 Jul 1997 11:05:02 +0100
From: Peter Williams <[email-masked]>
To: [email-masked]
CC: [email-masked], Sharon Boeyen <[email-masked]>
Subject: Re: FW: CRL Push over S/Mime

Anil R. Gangolli wrote:

> I hope this doesn't get lost in all the traffic on the list.
>
> Due to the mixed quoting,  I couldn't tell whether the wording was
> from the I-D, from Peter's suggestion, or Sharon's.
>
> Regarding transfer of CRLs using HTTP or HTTPS urls, I object to the
> I-D dictating anything about the format of the URL.  These are
> typically
> dynamically interpreted by servers.
>
> The important thing to specify is that the GET method returns
> a specific a specific content type label (mime type) with content
> in a specific syntax, or one of a set of content types and syntaxes.
>
> Any mention of .cer, .p7c and associated extensions
> should be at very least separated from the spec proper into an
> advisory note.  If there at all, it should be very precise about what
> the expected content is.  Otherwise it has little or perhaps
> negative value.

Anil,

Agreed. I took Russ's existing text, and substituted ftp for http -
almost
verbatim. I argued to Sharon, then, the important fact (for both the
http retreival and
messaging push issue) that the only additional fact in need of
standardization
was the mime content type.

So, I suspect we are mostly in agreement. We can add a line
to PKIX-2 part 3 which says - "The example URIs are not required forms
of URLs suggesting merely
some possiblities." I just modified Russ original examples to use web
motifs.

If Sharon is amenable to the notion, and she is editor
in charge of Part II & who can give the nod prior to any writing, a mime

content type can also be specified, as we seem to be agreeing. I have
already
suggested reuse of application/x-x509-user-cert
from Netscape, used in that companies products and some
of Microsoft's. Perhaps we could specify application/x509-user-cert ??

Or would it be more correct & useful  to also allow
application/[x-]x509-ca-cert
also as an allowed content type return, along with
application/octet-string?

Peter.

Date: Wed, 09 Jul 1997 11:11:22 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: SET Root CA Extension

>If we knew that the current Root-CA certificate would be valid throughout
the validation 
>period, I do not see any problems in issuing the "next" Root-CA certificate
when the 
>"current" Root-CA certificate is issued.
>
>However, if we would also like to use an already generated (and
hash-published) key to be 
>used when the "next" Root-CA certificate must be generated "prematurely"
due to 
>compromise of the "current" Root-CA certificate, it would not be helpful if
we had already 
>used the key in the "next" Root-CA certificate and issued it with a now
"unusable" begin 
>date.
>
>Regards Ebbe Hansen @ Cylink Corp.

The mechanism which I had previously thought was going to be used was for
the next generation root certificate and public/private key pair to be
generated contemporanously, at a time near the end of the current root key's
validity period, and hence the unusable begin date problem would not occur.
The old root key would then be used to certifiy the new root as though it
were a subordinate CA, and likewise the new root would be used to certify
the old root as though it were a subordinate CA. This way, certificates
which have been issued under the old root can be validated by those clients
that have installed the new root as their top-level CA, and those clients
which have not yet switched over can validate certificate issued under the
new root, in each case adding only one additional level to the chain.  (As I
recall it was Denis Pinkas who first described this mechanism.)

The above mechanism certainly works in the absence of a compromise, and by
deferring the generation of a new private key it also helps reduce the
possiblity of a compromise. The same mechanism also works nicely for the
backup CA problem -- the primary and the backup CA's effectively
cross-certify each other, so that the validation chain can continue even
during a period where the backup CA may be required to issue new
certificates. (This mechanism is therefore likely to be required in any
case.) And this mechanism does not require the potentially dangerous
practice of extracting and securely transporting a copy of the private key
to the backup location(s).

The only real question is how awkward a problem would be created in the case
where a real or suspected compromise of the original root key occurs.  In
the case of the hash technique, the assumption has to be that the new
replacement key will not have been compromised.  Yet that assumption seems
quite shaky to me -- if one key was compromised there is an excellent chance
that the same compromise mechanism has compromised the replacement key as
well.  I am assuming that the root key is used extremely rarely, and is kept
under strong physical security inside a tamper-proof container and only
brought out under armed guard with high ceremony, to create new
country-level CA certificates, perhaps once a year or so.  Under those
assupmptions, it seems just as likely that the replacement key would have
been compromised as well, and so the hash of the new key becomes useless.

It might also be worth noting that the hash technique doesn't solve the
problem created by a potential  but so far unexploited weakness being found
in the signature algorithm itself (or the hashing technique, for that
matter). In that case the hash technique would be useless, but a
cross-certification technique could be used to certify a new public key and
algorithm.  As soon as possible, the entire user population should switch
over to the new root certificate and algorithm to avoid the potential
weakness, but the cross-certification approach would permit a smooth
continued operation during the transition period.

For these reasons I would prefer the cross-certification technique, but in
either case it is important to design for the possibility of reintroducing a
new root key via a trusted path, rather than assuming that the system will
run perfectly forever, once it gets started.

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Wed, 09 Jul 1997 13:31:36 -0400
To: Stephen Kent <[email-masked]>
From: Santosh Chokhani <[email-masked]>
Subject: Re: SET Root CA Extension
Cc: Bob Jueneman <[email-masked]>, [email-masked]

At 11:55 AM 7/9/97 -0400, Stephen Kent wrote:
>Bob,
>
>	I too would like to see the explanation for why inclusion of the
>hash of the next (root) CA public key is preferable to merely presigning
>the next cert for a (root) CA.  I have designed systems that adopted the
>presigning of the next cert approach, primarily as a response to loss of
>use of (vs. compromise of) the CA key.  I'm open to arguments why the
>approach adopted for SET is preferable, but I agree with Bob that we ought
>not adopt a new extension unless it is supported by a good argument as to
>why other methods, that don't require a new extension, are not
>equivalent/sufficient.
>
>Steve
>
>
>

Steve: I assume by presigning you mean use the current key to sign the next
key.  Assuming this, the hash has one advantage.  It allows for "in-band"
rekying of the root in the face of a compromise.  Those entities who have
received the current certificate and hence the hash of the next public key
before the current key was compromised, can use the hash to validate the
next certificate received over untrusted channels.

-------------------------------------------------
Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West
7927 Jones Branch Drive
McLean, Virginia 22102-3305
(703) 848 - 0883
[email-masked]

Date: Wed, 09 Jul 1997 10:24:39 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: SET Root CA Extension

>Bob,
>
> I too would like to see the explanation for why inclusion of the
>hash of the next (root) CA public key is preferable to merely presigning
>the next cert for a (root) CA.  I have designed systems that adopted the
>presigning of the next cert approach, primarily as a response to loss of
>use of (vs. compromise of) the CA key.  I'm open to arguments why the
>approach adopted for SET is preferable, but I agree with Bob that we ought
>not adopt a new extension unless it is supported by a good argument as to
>why other methods, that don't require a new extension, are not
>equivalent/sufficient.
>
>Steve
>
>
The threat analysis in a system as important as SET is obviously important,
and a non-trivial exercise. Without knowing more about precisely how their
keys are generated, by whom, how stored, etc., etc., it may not be possible
to completely analyze the threat.

But my general approach would be to avoid generating a new root key until a
time that is near the expiration date of the current key, in order to avoid
any possible human or institutional threat for as long as possible.

Yes, I agree that this raises the possibility that the original key is
compromised, and then logically it is impossible to distribute a new one
without relying on an out-of-band mechanism.  But even if the original root
key were compromised, assuming it is still in the possession of the
authorities it can still be used to authenticate a new one -- the only
problem is that someone else might attempt to spoof that process. But in
that case, it would be almost impossible to carry out the spoof without
detection, and so the bogus root key could be ignored.

The denial of service case, where the CA loses control of the key (it is
destroyed somehow) is another case that has to be addressed. But this also
raises the issue of a backup CA that is physically distributed, and how the
keys for that CA are going to be generated, distributed, and controlled.  Do
you make a copy of the private key, and install it at the backup site? That
introduces even more complexity and potential risk.

I don't want to be misunderstood -- I'm not necessarily criticizing the
decision that the SET folks made. I just don't understand it, and would not
like to adopt such a mechanism within PKIX without having discussed it in a
more general context than might apply to SET.

I do think that it is very important to work through these cases carefully
in advance -- trying to do it in the middle of a crisis would not be fun!

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                               

From: Ebbe Hansen <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: SET Root CA Extension
Date: Wed, 9 Jul 1997 09:17:27 -0700

If we knew that the current Root-CA certificate would be valid throughout the validation period, I do not see any problems in issuing the "next" Root-CA certificate when the "current" Root-CA certificate is issued.

However, if we would also like to use an already generated (and hash-published) key to be used when the "next" Root-CA certificate must be generated "prematurely" due to compromise of the "current" Root-CA certificate, it would not be helpful if we had already used the key in the "next" Root-CA certificate and issued it with a now "unusable" begin date.

Regards Ebbe Hansen @ Cylink Corp.

----------
From: 	Bob Jueneman[SMTP:[email-masked]]
Sent: 	Tuesday, July 08, 1997 7:15 PM
To: 	[email-masked]; [email-masked]
Subject: 	Re: SET Root CA Extension

>
>All:
>
>In the SET environment, the Root CA has a private extension that carries 
>the hash of the next public key to be used by the CA.  This extension 
>allows a single key (the current one) to be distributed by a trusted means,

>then, as long as there are no compromises at the Root CA, subsequent CA 
>certificates can be trusted without trusted distribution of the public key.

That was apparently added after I was no longer involved, and I don't
understand the reasoning.  Obviously if the hash of the next key is known,
it must have already been generated, so it is potentially vulnerable to
compromise before it has ever been put inbto use.  (It just can't be
cryptoanalytically attacked, as it hasn't been disclosed yet.)

Other than the possible fear for a cryptanalytic attack, why not just
digitally sign (cross-certify) the next one, and distribute it along with
the first certificate? This would also allow subsequent CA certificates to
be distributed safely, making the same assumiptions regarding the lack of
compromise.

I must be missing something -- what does this accomplish that couldn't be
done just as easily using existing standards, without an attribute
extension?

>
>The syntax used by SET is:
>1587 -- Set protocol private extensions -- 
>1588
>1589 hashedRootKey EXTENSION ::= { -- Only in root certificates 
>1590 SYNTAX HashedRootKeySyntax
>1591 CRITICAL TRUE
>1592 IDENTIFIED BY id-set-hashedRootKey 1593 }
>1594
>1595 HashedRootKeySyntax ::= RootKeyThumb 1596
>1597 RootKeyThumb ::= SEQUENCE {
>1599 rootKeyThumbprint DD { SubjectPublicKeyInfo{{SupportedAlgorithms}} } 
>1600 }
>
>Are any other communities planning to use this mechanism?
>
>If many communities want to use this mechanism, then we should add it to 
>PKIX Part 1 to make sure that certificate users are prepared for this 
>CRITICAL extension.  If only the SET community is interested in this 
>extension, then we should not add it to PKIX Part 1.
>
>Russ

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Wed, 9 Jul 1997 11:55:48 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SET Root CA Extension
Cc: [email-masked]

Bob,

	I too would like to see the explanation for why inclusion of the
hash of the next (root) CA public key is preferable to merely presigning
the next cert for a (root) CA.  I have designed systems that adopted the
presigning of the next cert approach, primarily as a response to loss of
use of (vs. compromise of) the CA key.  I'm open to arguments why the
approach adopted for SET is preferable, but I agree with Bob that we ought
not adopt a new extension unless it is supported by a good argument as to
why other methods, that don't require a new extension, are not
equivalent/sufficient.

Steve

Date: Wed, 09 Jul 97 07:19:53 
From: "Housley, Russ" <[email-masked]>
Encoding: 686 Text
To: [email-masked], Peter Williams <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: CRL Push over S/Mime

Peter:

> I have been asked to write up a mail based distribution for pkix part 
> two.
>
> Nice for someone to inform the WG and  list about the activity; comments
> might then be introduced to gain as much techncial input and concensus as 
> possible before writing.

Back off.

Trevor asked about an e-mail distribution mechanism.  I am pretty sure that 
this question was asked on this list.  I responded to him saying that the 
mechanisms included in Part 2 were there because someone offered to write a 
section about them.  At that time, no one offered to write about e-mail.  
Trevor cares enough about e-mail that he offered to write the section.

Russ

From: Trevor Freeman <[email-masked]>
To: Dwight Arthur <[email-masked]>, Sharon Boeyen <[email-masked]>
Cc: PKIX List <[email-masked]>
Subject: RE: FW: CRL Push over S/Mime
Date: Wed, 9 Jul 1997 05:08:10 -0700

We need to be careful here. There are two places where of certificate
and crl distribution are documented. By application specific workgroups
and by pkix. 
Applications which use certificates such as ipsec, TLS etc. are at
liberty to define a method of certificate distribution specific to their
application. These would then be documented by the workgroup responsible
for the application. Some of the examples given for S\MIME  on this
thread fall into this category. If RSA define as part of their standard
for S\MIME, a mechanism for certificate chain or CRL distribution with
the message, that has no impact on the pkix work.
The pkix workgroup is defining "application independent" protocols for
certificate distribution. Pkix is using the output from other
application workgroups as transports e.g. ftp, http etc. but they are
not part of the application protocol in themselves. Sharon, I believe
email would be an important addition to the pkix part 2 standard as it
provides an alternative to session based certificate distribution
currently described. A store and forward approach for certificate
distribution would significant advantages for some groups of users
partially those using dials up connections. Also some organisation may
not want a session based protocol to cross their firewall. Many
organisations already have their firewalls configured for mail, the
email can also be scanned for viruses.
Trevor

> -----Original Message-----
> From:	Dwight Arthur [SMTP:[email-masked]]
> Sent:	Tuesday, July 08, 1997 9:24 PM
> To:	Sharon Boeyen
> Cc:	PKIX List
> Subject:	Re: FW: CRL Push over S/Mime
> 
> Sharon Boeyen wrote:
> > <...> but email is bordering pretty close to
> > application specific. Also, I don't see the value of using a store
> and
> > forward protocol for either retrieval or management of repository
> > information and think that from a user's perspective the delays
> would
> > not be acceptable. I am yet to be convinced that we need (or want)
> and
> > email protocol in pkix 2. 
> 
> Hi, I am addressing this from the viewpoint of an actual user
> organization.
> NSCC is an industry owned utility that does clearing and settlement
> for
> the Securities Industry. We potentially have much to gain from the use
> of 
> PKI for validation of the source of a trade submitted for settlement,
> but
> I need to be very conscious of the issues of performance, reliability,
> availability, recovery, etc. across a wide range of transaction types
> ranging from $50Million for settlement in five minutes, to $500 for 
> settlement  in three days.
> 
> I have trouble imagining any sort of high volume transaction
> processing 
> that involves CRL pull or online check on a per-transaction basis: the
> volumes of messages and the network latency would have a severe impact
> on our data centers and network managers.  This is especially the case
> 
> where the transactions themselves are being processed on an overnight 
> basis. I believe that our only viable options for many of our
> transaction 
> types are (1) Polling for CRL's on established intervals, or (2) CRL
> push by participating CA's whenever there is a new revocation. I
> believe
> that the latter offers the smallest window of exposure.
> 
> Possibly, LDAP will be the mechanism by which this type of information
> 
> gets pushed, but I believe that there will be a long wait before the
> Securities Industry has a sufficiently broad deployment of
> geographically
> distributed, replicated, reliable, high capacity LDAP-capable
> directory 
> servers accessible over public networks. For example, if I were to
> start
> today I would estimate that it would take a year before I could enable
> incoming LDAP protocols through my firewall. That's just one small
> obstacle out of many.
> 
> FTP could be an excellent choice: but I have some issues ... I do not
> understand a need for encryption but I do understand a clear and
> strong
> need to authenticate the source of a CRL: it should be signed. I also
> need it to come with an expiration. I also need to negotiate with my
> CA 
> to be aware of and address unsuccessful delivery requests. Each of
> these
> seems very possible with SMTP-based protocols, and as an added bonus I
> already have, today, a firewall that accepts incoming SMTP and scans
> for
> viruses, where incoming FTP is blocked as a security measure.
> 
> Does this mean that MIME should be the preferred mode for CRL 
> distribution? no. But there must be a low-end choice where business
> issues call for it and I believe that SMTP (S/MIME?) offers certain
> advantages over FTP which is the only low-end alternative I see.
> 
> Also, if I am not mistaken, Netscape Communicator's current 
> implementation presumes CRL distribution as a dated, signed, S-Mime 
> attachment
> 
> -Dwight

Date: Tue, 08 Jul 1997 22:23:16 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: [email-masked]
CC: Sharon Boeyen <[email-masked]>, Peter Williams <[email-masked]>
Subject: Re: FW: CRL Push over S/Mime

I hope this doesn't get lost in all the traffic on the list.

Due to the mixed quoting,  I couldn't tell whether the wording was
from the I-D, from Peter's suggestion, or Sharon's.

Regarding transfer of CRLs using HTTP or HTTPS urls, I object to the
I-D dictating anything about the format of the URL.  These are typically
dynamically interpreted by servers.

The important thing to specify is that the GET method returns
a specific a specific content type label (mime type) with content
in a specific syntax, or one of a set of content types and syntaxes.

Any mention of .cer, .p7c and associated extensions
should be at very least separated from the spec proper into an
advisory note.  If there at all, it should be very precise about what
the expected content is.  Otherwise it has little or perhaps
negative value.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

From: [email-masked] (Amit Kapoor)
Subject: Re: [Fwd: Re: FW: RSA mandatory for PKIX CMP?! (fwd)]
To: [email-masked] (Bob Jueneman)
Date: Tue, 8 Jul 1997 21:00:10 -0700 (PDT)
Cc: [email-masked] (pkix)
Content-Length: 2397

Forwarded message:
> From [email-masked] Tue Jul  8 19:50:06 1997
> Message-Id: <[email-masked]>
> From: Bob Jueneman <[email-masked]>
> To: [email-masked]
> 
> "The wonderful thing about standards is that there are so many to chose
> from."

Let us make the right choice then :)

> 
> RSA is the obvious, de facto choice if the IETF wishes to support
> interoperability.

I have lots (and lots)+ of problems with the above statement.

1.  Obvious?  It is not obvious to quite a few of us.  Will it be obvious
    to software developer's when they have to purchase a RSA patent license
    just to get a certificate issued from a CA?  Can Joe Developer
    get RSA toolkit/license to write a CA/CMP at a affordable cost?
    Or is the paradigm that CA/CMP is for a selected elite only and
    the IETF standard should mandate that?

2.  "de facto choice".  When did this happen :)

3.  "support interoperability".  I am very sure that IETF can support
    interoperability with DSA/D-H also :).  RSA is not the only algorithm
    which allows interoperability.  Please correct me if I am wrong.

4.  The stated reason is again *not* technical.  Againist all non-techinal
    reasons a lot of us will keep raising the fact that RSA is available
    only to a *selected few*, not what the purpose of a IETF standard
    should be.  Please also refer to Li Gong's message about what it
    means for RSA to be available to everyone (substitute Java with
    whatever platform :))

> Perhaps "mandatory" is too strong, but if a PKIX
> implementation chooses to only implement DSA, or some government's
> proprietary (or even secret) signature and/or key exchange algorithm, will
> the Internet police descend upon them and drag them off to some Dragon
> infested Dungeon?

I am missing your point in the above statement.  Are you saying DSA is
proprietary or that its algorithm is secret as compared to RSA? And what
Internet police :) ???

I have no problems with "mandatory", just what the spec is making
mandatory :).  As in response to Kemp's message, I had stated that
it makes sense to make one algorithm manadatory to provide for
interoperability, the whole point for all of us to be spending time
on this.

cheers-

Amit
(PS:  Someone I know just mentioned that RSA is not extensible to
      Elliptic curve cryptosystems?  Is this true?)

> 
> Bob
> 
<snip>

Date: Tue, 08 Jul 1997 20:31:04 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Subject: [Fwd: Re: FW: RSA mandatory for PKIX CMP?! (fwd)]

"The wonderful thing about standards is that there are so many to chose
from."

RSA is the obvious, de facto choice if the IETF wishes to support
interoperability. Perhaps "mandatory" is too strong, but if a PKIX
implementation chooses to only implement DSA, or some government's
proprietary (or even secret) signature and/or key exchange algorithm, will
the Internet police descend upon them and drag them off to some Dragon
infested Dungeon?

Bob

David P. Kemp wrote:
> 
> As an employee of a government which until recently tried to make
> DSA mandatory, I believe that is the wrong approach.
> 
> Speaking from experience, I doubt that the regulatory approach of
> mandating *any* algorithm set will accelerate that process.  I
> recommend that PKIX profile the use of RSA, DSA, and EDSA, but not
> make any of them a MUST-implement.

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Tue, 08 Jul 1997 20:15:36 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: SET Root CA Extension

>
>All:
>
>In the SET environment, the Root CA has a private extension that carries 
>the hash of the next public key to be used by the CA.  This extension 
>allows a single key (the current one) to be distributed by a trusted means,

>then, as long as there are no compromises at the Root CA, subsequent CA 
>certificates can be trusted without trusted distribution of the public key.

That was apparently added after I was no longer involved, and I don't
understand the reasoning.  Obviously if the hash of the next key is known,
it must have already been generated, so it is potentially vulnerable to
compromise before it has ever been put inbto use.  (It just can't be
cryptoanalytically attacked, as it hasn't been disclosed yet.)

Other than the possible fear for a cryptanalytic attack, why not just
digitally sign (cross-certify) the next one, and distribute it along with
the first certificate? This would also allow subsequent CA certificates to
be distributed safely, making the same assumiptions regarding the lack of
compromise.

I must be missing something -- what does this accomplish that couldn't be
done just as easily using existing standards, without an attribute
extension?

>
>The syntax used by SET is:
>1587 -- Set protocol private extensions -- 
>1588
>1589 hashedRootKey EXTENSION ::= { -- Only in root certificates 
>1590 SYNTAX HashedRootKeySyntax
>1591 CRITICAL TRUE
>1592 IDENTIFIED BY id-set-hashedRootKey 1593 }
>1594
>1595 HashedRootKeySyntax ::= RootKeyThumb 1596
>1597 RootKeyThumb ::= SEQUENCE {
>1599 rootKeyThumbprint DD { SubjectPublicKeyInfo{{SupportedAlgorithms}} } 
>1600 }
>
>Are any other communities planning to use this mechanism?
>
>If many communities want to use this mechanism, then we should add it to 
>PKIX Part 1 to make sure that certificate users are prepared for this 
>CRITICAL extension.  If only the SET community is interested in this 
>extension, then we should not add it to PKIX Part 1.
>
>Russ

Bob

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: John Marchioni <[email-masked]>
To: "'Peter Williams'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: RSA mandatory for PKIX CMP?!
Date: Tue, 8 Jul 1997 18:15:35 +0100

So Verisign is "... committed to supporting other digital signature standards as market demand materializes for alternatives."

Consider PGP's installed base--which I think is on the order of 3 to 4 million users, and the fact that PGP now supports DSS and Diffie-Hellman, and PGP will also support the import and export of X.509 certificates; this seems to indicate that there is more than adequate market demand for, not to mention some pretty good business (couldn't resist the pun) in DSA certificates.  Does Verisign consider DSA to be on your alternative-standard-candidate list at all?

We seem to have digressed on this thread--my apologies to the PKIX DL.

- John

-----Original Message-----
From:	Peter Williams [SMTP:[email-masked]]
Sent:	Tuesday, July 08, 1997 3:40 PM
To:	John Marchioni
Cc:	Charles Breed; [email-masked]
Subject:	Re: RSA mandatory for PKIX CMP?!

John Marchioni wrote:

> Peter -
>
> Are you hinting that if PGP responds "Yes" then Verisign may start
> issuing DSA certificates?  Now that would be a major event!
>
> - John

John,

VeriSign's position has been consistent for over 12 months: see

https://www.verisign.com/repository/CPS1.2/CPSCH2.HTM section 2.1.2.

Peter.

Date: Tue, 08 Jul 1997 15:40:19 +0100
From: Peter Williams <[email-masked]>
To: John Marchioni <[email-masked]>
CC: Charles Breed <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: RSA mandatory for PKIX CMP?!

John Marchioni wrote:

> Peter -
>
> Are you hinting that if PGP responds "Yes" then Verisign may start
> issuing DSA certificates?  Now that would be a major event!
>
> - John

John,

VeriSign's position has been consistent for over 12 months: see

https://www.verisign.com/repository/CPS1.2/CPSCH2.HTM section 2.1.2.

Peter.

Date: Tue, 08 Jul 1997 16:35:51 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: RSA mandatory for PKIX CMP?!

I think this is a fine question.  I've been looking for this sort of thing
too.  I don't care WHO does it, but someone should give away/sell a
toolkit/show an implementation that is fairly publically available.  I like
the logic of using DSA/etc. for PKIX.  

Now, then, exactly where can I buy a cert?  Or a toolkit?

>Date: Tue, 08 Jul 1997 11:38:04 +0100
>From: Peter Williams <[email-masked]>
>To: Charles Breed <[email-masked]>
>CC: [email-masked]
>Subject: Re: RSA mandatory for PKIX CMP?!
>
>Charles,
>
>Can you confirm for the WG/list that PGP now has an intent to implement
>PKIX [parts] and
>X.509 (DSA) certs?
>
>I think this would improve your arguments, if its confirmed, and would
>be major
>event in our industry!
>
>yes or no, will do fine as an answer.
>
>Peter.
>
>
>

-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
   246 Walnut St Newton MA 02160 USA  +1 617 332 7292 +1 617 332 7970(Fax)

From: Ebbe Hansen <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: RSA mandatory for PKIX CMP?!
Date: Tue, 8 Jul 1997 13:45:52 -0700

I accordance with US government guidelines, the CA that Cylink has developed for the United States Postal Service supports DSA based certificates as the primary choice of certificate protection algorithm. Support of  RSA based certificates may be considered in the future, only if such need is justified by business considerations.

My opinion is that the use of the RSA algorithm suite should not become mandatory in the PKIX profile. Let the market forces determine the future and show how many certificates will be based upon proprietary algorithms.

Ebbe Hansen @ Cylink Corp.

----------
From: 	Charles Breed[SMTP:[email-masked]]
Sent: 	Tuesday, July 08, 1997 10:43 AM
To: 	[email-masked]
Subject: 	Re: RSA mandatory for PKIX CMP?!

Referring to the latest PKIX draft on CMP:

I sure hope someone is keeping score here; as you know, many have had 
great difficulty with the RSA licensing agreement, it's restrictive 
nature prohibits some software developers abilities and promotes a 
select few wrt issuing X.509 certificates, (being a public CA). 

I agree with John Marchioni, Li Gong, Amit Kapoor, Carlisle Adams and 
Tom Markham. Since there is no strong technical reason for using RSA 
as the mandatory Public Key Algorithm, check out 
	http://www.cylink.com/products/security/rsa/rsa-dss2.htm

the PKIX draft should use what is 
 - publicly available, 
 - open for review, 
 - widely interoperable,
 - patent free,
 - implementations are available,
 - major platforms support including NT, Mac, Unix, Java,
 - US government approved
 - separate key-pair for signing and encrypting session keys,
 - quickly becoming more deployed than RSA for better 
   interoperability 

and that is... Diffie-Hellman/Elgamal/DSS

The PKIX group should note that the IESG Remanded the TLS document back 
to the working group. One of the reasons was that it required licensing 
of proprietary technology. The Remand message suggested that TLS 
needed to make Diffie-Hellman/Elgamal/DSS as mandatory to implement cipher 
suite.

Charles Breed

Date: Tue, 08 Jul 1997 16:24:29 -0400
From: Dwight Arthur <[email-masked]>
To: Sharon Boeyen <[email-masked]>
CC: PKIX List <[email-masked]>
Subject: Re: FW: CRL Push over S/Mime

Sharon Boeyen wrote:
> <...> but email is bordering pretty close to
> application specific. Also, I don't see the value of using a store and
> forward protocol for either retrieval or management of repository
> information and think that from a user's perspective the delays would
> not be acceptable. I am yet to be convinced that we need (or want) and
> email protocol in pkix 2. 

Hi, I am addressing this from the viewpoint of an actual user
organization.
NSCC is an industry owned utility that does clearing and settlement for
the Securities Industry. We potentially have much to gain from the use
of 
PKI for validation of the source of a trade submitted for settlement,
but
I need to be very conscious of the issues of performance, reliability,
availability, recovery, etc. across a wide range of transaction types
ranging from $50Million for settlement in five minutes, to $500 for 
settlement  in three days.

I have trouble imagining any sort of high volume transaction processing 
that involves CRL pull or online check on a per-transaction basis: the
volumes of messages and the network latency would have a severe impact
on our data centers and network managers.  This is especially the case 
where the transactions themselves are being processed on an overnight 
basis. I believe that our only viable options for many of our
transaction 
types are (1) Polling for CRL's on established intervals, or (2) CRL
push by participating CA's whenever there is a new revocation. I believe
that the latter offers the smallest window of exposure.

Possibly, LDAP will be the mechanism by which this type of information 
gets pushed, but I believe that there will be a long wait before the
Securities Industry has a sufficiently broad deployment of
geographically
distributed, replicated, reliable, high capacity LDAP-capable directory 
servers accessible over public networks. For example, if I were to start
today I would estimate that it would take a year before I could enable
incoming LDAP protocols through my firewall. That's just one small
obstacle out of many.

FTP could be an excellent choice: but I have some issues ... I do not
understand a need for encryption but I do understand a clear and strong
need to authenticate the source of a CRL: it should be signed. I also
need it to come with an expiration. I also need to negotiate with my CA 
to be aware of and address unsuccessful delivery requests. Each of these
seems very possible with SMTP-based protocols, and as an added bonus I
already have, today, a firewall that accepts incoming SMTP and scans for
viruses, where incoming FTP is blocked as a security measure.

Does this mean that MIME should be the preferred mode for CRL 
distribution? no. But there must be a low-end choice where business
issues call for it and I believe that SMTP (S/MIME?) offers certain
advantages over FTP which is the only low-end alternative I see.

Also, if I am not mistaken, Netscape Communicator's current 
implementation presumes CRL distribution as a dated, signed, S-Mime 
attachment

-Dwight

Date: Tue, 08 Jul 1997 13:16:01 -0700
To: Peter Williams <[email-masked]>
From: Charles Breed <[email-masked]>
Subject: Re: RSA mandatory for PKIX CMP?!
Cc: [email-masked]

Peter,

Traditionally, the IETF list is for individual postings, but since you ask…

Yes, to ensure interoperability of openly-available protocols (including strong algorithms), PGP, Inc. will do what's right. PGP, Inc is receptive to useful, widely deployed public key infrastructures, which we believe is already the case wrt PGP. We have no problems with the 'wonderful' ASN.1 encoding rules, in fact, we plan to allow the import and export of X.509 (DSA) certificates to and from a PGP Key Ring.

Charles Breed

At 11:38 AM 7/8/97 +0100, Peter Williams wrote:
>Charles,
>
>Can you confirm for the WG/list that PGP now has an intent to implement
>PKIX [parts] and
>X.509 (DSA) certs?
>
>I think this would improve your arguments, if its confirmed, and would
>be major
>event in our industry!
>
>yes or no, will do fine as an answer.
>
>Peter.
>
>
>

Date: Tue, 08 Jul 1997 14:10:29 -0600
From: John Kennedy <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re:  RSA mandatory for PKIX CMP?!

Folks,

I also have to strongly object to making RSA a mandatory part of this
standard.  As John Marchioni pointed out, there is no technical reason for
doing this and the financial ramifications for deploying RSA (at least in
North America) remain exclusionary and an impediment to deployment by anyone
other than current RSADSI licensees.  While this may serve the early
pioneers in this space, it is inconsistent with the concept of creating
standards which are conducive to maintaining a level playing field for all
potential implementors.

This tack also seems inconsistent with draft mandatory algorithm
recommendations in some of the other security working groups.  Hasn't IPSEC
been moving in the Diffie-Hellman and DSA direction for quite some time now?
 Is there some mystery why Cisco and Sun made free IPSEC code available
which used DH and DSA? And what about the push in TLS for using
Diffie-Hellman and DSA?

If there is a no technical argument for choosing one algorithm over another,
then I cannot understand why we should choose one that is financially
encumbered.  I mean it seems ridiculous that DSAwithSHA1 wasn't even
permitted as an alternate signature algorithm.

We're going the wrong way here.

-John Kennedy

----Original Message-----
From: John Marchioni [SMTP:[email-masked]] 
Sent: Monday, July 07, 1997 5:45 PM
To: [email-masked] 
Subject: RSA mandatory for PKIX CMP?!

Referring to the latest PKIX draft on CMP:

I strongly disagree with making RSA mandatory for any IETF "standard".  Keep
in mind that not every user community or vendor can or wants to pay the
royalties or license fees involved with RSA.  Mandatory RSA certainly makes
sense for companies like Entrust because they have a license for the
technology and thus, if CMP as drafted passes, will give such vendors an
unfair competitive advantage over vendors who cannot acquire such a license.

>From a practical point of view, what if I have a CA that issues DSS
certificates only?  Meaning my user community has no desire nor need for RSA
signatures.  This draft would require that inorder to be compliant I would
need to put enough RSA in my CA product to handle the CMPs only--get real!

Bottom line, there is no sound technical reason for making RSA mandatory. 
DSS and Diffie-Hellman can provide all of the same functions as RSA
including encryption-key negotiation with an EE without a pre-issued
certificate.

To the editors of the CMP specification I beg that you rethink or think
deeper about the issue.  PKIX should do what is best for all vendors and
their user communities if it is to be taken seriously.

Sorry if I'm coming on too strong but this just doesn't smell good to me.

- John

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

From: John Marchioni <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, Charles Breed <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: RSA mandatory for PKIX CMP?!
Date: Tue, 8 Jul 1997 12:50:35 +0100

Peter -

Are you hinting that if PGP responds "Yes" then Verisign may start issuing DSA certificates?  Now that would be a major event!

- John

-----Original Message-----
From:	Peter Williams [SMTP:[email-masked]]
Sent:	Tuesday, July 08, 1997 11:38 AM
To:	Charles Breed
Cc:	[email-masked]
Subject:	Re: RSA mandatory for PKIX CMP?!

Charles,

Can you confirm for the WG/list that PGP now has an intent to implement
PKIX [parts] and
X.509 (DSA) certs?

I think this would improve your arguments, if its confirmed, and would
be major
event in our industry!

yes or no, will do fine as an answer.

Peter.

Date: Tue, 08 Jul 1997 12:19:40 +0100
From: Peter Williams <[email-masked]>
To: Sharon Boeyen <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: FW: CRL Push over S/Mime

Sharon Boeyen wrote:

Re an email mechanism - this was not agreed in Memphis, but was a

> suggestion on the pkix list in April I believe. Personally I have some
>
> concerns over adding this. I think what we are trying to do here is
> standardize tools for communication between a repository and other
> entities and in the case of OCSP between a CA and other entities for
> purposes of certificate and crl retrieval and
> addition/deletion/modification as well as for possibly other data
> types
> eg CPS.
>
> If we continue to add more protocols for satisfying the same
> requirement
> we will seriously hamper any ability to interoperate. We can't have
> all
> repositories, for instance, required to support x number of protocols
> and neither can we do the same to the relying party or CA systems. We
> need to agree on as small a set as possible and try to make them
> application independent. LDAP, FTP and OCSP all fit that category.
> HTTP
> probably does as well, but email is bordering pretty close to
> application specific.

This is fair enough, though I argued for messenging, versus email. Lets
generalisethe notion. What the messenging case was pointing out was that
there is push as well as pull.
There is no basis for denying an ever-growing tide of channel-centric
distribution
technologies which allow the repository or a directory provider to push
valid
certs deltas and updated CRLs to local caches, and end-used UAs, using
java and other solutions.

Whilst for white-pages search,  X.500 solutions are "obviously" the
best way to go, and http/ftp is fine for simple URI-based certificate
retrieval, propogation
of dynamic state is obviously a case benefiting from
multicast-file-push  and java-style
push to embrace the scaling issues, and the need to ensure timely
availablity and
confirmed delivery of revocation information from multiple distribution
sources as
close to the user as can be acheived to minimse the vulnerability of
active attack
on the network succeeding to disrupt physical flow capability

My bigger picture on S/MIME in this argument was really perhaps better
expressed in terms of PKCS7, where that convenient (unsigned) *format*
for representation of PKIX cert and CRL lists could be used commonly -
as
is happening de facto anyway in many potential PKIX-using commercial
products -
however the stream is pushed around or got by a simple query
protocol. I'd be perfectly happy to agree to the notion that
alternatively the Netscape application/x-x509-user-cert mime
type become part of PKIX-2, so as not to force
folk into generating PKCS7 ASN.1 list and transport formats when they
dont
want it but can go with its simpler options in low-end
products/services..

> Also, I don't see the value of using a store and
> forward protocol for either retrieval or management of repository
> information and think that from a user's perspective the delays would
> not be acceptable. I am yet to be convinced that we need (or want) and
>
> email protocol in pkix 2. If it is agreed that this is required, I
> need
> the input pretty soon or it will miss the deadline.
>

Im willing to draft material concerning use of PKCS7 (.p7c) and a
MIME type for use in pushing cert/CRL  repository information to UA,
UA caches, firewall proxies, or other  form of replicated/cached
repositories.

More than this I dont think perhaps we should touch; there seems
no benefit (at this juncture of understanding!)[...]

> As for the requirement Denis raised for the "S" of S/MIME, I think he
> raises some valid issues that pkix part 2 needs to deal with. Access
> controls help somewhat in restricting those adding/deleting/modifying
> information, but there are additional requirements potentially for
> strong authentication, digital signatures and/or encryption on mainly
> the "write" operations with a repository.

I dont think the Dwight's question concerned a 1424 type auto-responder
service for repositories, but rather recognise that 1421-style caching
of certs
and CRLs can be explioted for free, in a push context (be
this bitnet distribution lists, or marimba, backweb, pointcast, etc)
which might use  PKCS7 *format* as the transfer vehicle for
distrbuting CRLs to outlying UAs. Choose another format
if we must, but the point is now clear.

> LDAP v3 will allow for strong
> authentication and I think we need to look into that as part of the
> solution.

 If digital signatures and/or encryption are also required

> (still to be determined) then we need to at least look into LDAP v3
> possible solutions for that. PKCS # 7  may be appropriate or others
> such
> as the signing and encryption support added to X.500 which
> accommodates
> SPKM. But let's get the requirements straight first.

A replication channel (be it Oracle, X.500 or Microsoft content
replication
service) will need to be protected if these technologies are used
by the CA when distributing their repositories internally, or exernally.
but
this seems premature to standardize in PKIX-2  (lets issue some PKIX
certs first!)

>
>
>
>
> ------------------
> NOTE: WE'VE MOVED
>
> Sharon Boeyen
> Entrust Technologies
> 750 Heron Road, Suite E08
> Ottawa, Ontario Canada K1V 1A7
>
> mailto:[email-masked]       Tel: (613) 247-3181
> http://www.entrust.com          Fax: (613) 247-3690
>          Orchestrating Enterprise Security
>
> >----------
> >From:  Peter Williams[SMTP:[email-masked]]
> >Sent:  July 7, 1997 7:36 AM
> >To:    Trevor Freeman
> >Cc:    Dwight Arthur; PKIX List
> >Subject:       Re: CRL Push over S/Mime
> >
> >Trevor Freeman wrote:
> >
> >> I have been asked to write up a mail based distribution for pkix
> part
> >> two.
> >
> >Nice for someone to inform the WG and  list about the activity;
> >comments
> >might
> >then be introduced to gain as much techncial input and concensus as
> >possible
> >before writing.
> >
> >> I do not understand the reasoning behind using s/mine for
> >> certificate/crl distribution. The data being distributed is signed.
> so
> >>
> >> its integrity not in question. Its published data so why do we need
>
> >> confidentiality.
> >
> >The purpose is to use S/MIME as one, conveninent, ubiquitous bearer
> for
> >the pushed
> >CRL protocol element (and updating the cert repositories & caches),
> not
> >to exploit its
> >message origination security service. As all conforming S/MIME
> >implementations can process
> >such indications, and mailboxes can process such message types
> >automatically, the property
> >now exists to automatially, efficiently propogate and cache CRL/cert
> >information, using X.400 and
> >bitnet-style distribution lists.
> >
> >The X.400 elements of Microsoft Exchange should have no particular
> >problem
> >with this at the quality end of the message solution space, reliably
> >propogating CRLs thereby to business users, particularly. Other
> >MIME-transporting
> >messaging protocols can also bear the S/MIME message also, of course
> >through benefits during transport and delivery may be less than with
> >X.400-style UAs due to the nature of the protocols or their actual
> >deployments.
> >
> >I suspect the above is the conventional thinking; perhaps read the
> PEM
> >specs
> >for other backgrounders on the theory of reliable messaging as a
> >security
> >infrastructure.
> >
> >Thinking unconventionally, of course practial solutions also exist
> when
> >using S/MIME in massively available products. Just as Authenticode,
> >when downloading certs in MSIE, invokes a vbscript-scipted control
> >to actually effect transfer of info on the local UA system according
> to
> >local
> >permission policy , so then a S/MIME protected control/script could
> >effect the update of
> >the CRL./cert cache during delivery - the S/MIME signature being
> >responsible
> >for security control of such acts, exactly as with Authenticode
> >signatures currently on java/activeX components delivering personal
> >certs/CRLs
> >at enrollment time..
> >
> >>
> >>
> >> If someone has some insight it would be welcome before I finish the
>
> >> work.
> >
> >Hope this helps.
> >
> >>
> >>
> >> Dr Trevor Freeman
> >> Senior Consultant
> >> Microsoft Consulting Services
> >> Microsoft Ltd ECU
> >> > Tel:  UK(+44) 1734 270412
> >> Fax: UK(+44) 1734 270435
> >>
> >> > -----Original Message-----
> >> > From: Dwight Arthur [SMTP:[email-masked]]
> >> > Sent: Thursday, July 03, 1997 5:53 PM
> >> > To:   PKIX List
> >> > Subject:      CRL Push over S/Mime
> >> >
> >> > Part Two describes CRL distribution via LDAP and FTP, and also
> OCSP,
> >>
> >> > presumably over HTTP. There is no description of S/Mime as a
> >> protocol
> >> > for the distribution of CRL's.
> >> >
> >> > If I understood some prior information published to this list by
> >> > Netscape, Communicator 4 is most effectively able to respond to
> >> CRL's
> >> > received via S/Mime, and can even handle the expiration time
> >> specified
> >> > for a CRL.
> >> >
> >> > Is an enhancement to Part Two to describe CRL distribution over
> >> S/Mime
> >> > in the offing?
> >> >
> >> > -Dwight << File: Card for Dwight Arthur >>
> >
> >
> >
> >

Date: Tue, 08 Jul 1997 11:38:04 +0100
From: Peter Williams <[email-masked]>
To: Charles Breed <[email-masked]>
CC: [email-masked]
Subject: Re: RSA mandatory for PKIX CMP?!

Charles,

Can you confirm for the WG/list that PGP now has an intent to implement
PKIX [parts] and
X.509 (DSA) certs?

I think this would improve your arguments, if its confirmed, and would
be major
event in our industry!

yes or no, will do fine as an answer.

Peter.

Date: Tue, 08 Jul 1997 11:09:27 +0100
From: Peter Williams <[email-masked]>
To: Sharon Boeyen <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: FW: CRL Push over S/Mime

Sharon Boeyen wrote:

Re an http mechanism - I believe that the draft minutes indicated

> someone was going to submit this to me for inclusion, but there were
> changes proposed to the minutes and with my temporary loss of
> connectivity I may have missed something. I have received no input on
> this mechanism to date.

As I remember, there was an http I-D posted, which was going to be
possibly integrated, appropriately, or at least the author was to be
invited
to harmonise the material with the PKIX-2 framework. I think
you were the person Sharon who introduced this fact. I certainly
remember
trying to back up the obvious legitimacy of the approach. As far as I
can
learn, the only force arguing for the archaic ftp approach was US and
DoD-based (for
who knows what reason) and logically an http approach would
functionally replace that mechanism entirely just as http (with
keep-alive)
has replaced simple ftp-getfile operations everywhere else.

Perhaps accept the following edit to ID-2, part 3 as an indication of
what minimal changes are required for what I suggested:-

3. Hypertext Transfer Protocol (HTTP)

Some CAs mandate the use of on-line validation services, while
others distribute CRLs to allow certificate users to perform
certificate validation themselves.  In general, CAs make CRLs
available to certificate users by posting them in the Directory.
The Directory is also the normal distribution mechanism for
certificates.  However, Directory Services are not available in
many parts of the Internet today, and the Hypertext Transfer Protocol
(HTTP), defined in RFC 2068,  offers an alternate method for
certificate and CRL distribution.

Within certificate extensions and CRL extensions, URI form of
GeneralName is used to specify the location where issuer
certificates and CRL may be obtained.  For instance, a URI
identifying the subject of a certificate can be carried in
subjectAltName certificate extension. An IA5String describes the
use of anonymous, or authenticated HTTP to fetch certificate or CRL
information.
For example:

   http://www.netcom.com/sp/spyrus/housley.cer
   shttp://www.your.org/pki/id48.cer
   https://www.your.org/pki/id48.crl?numberB

Internet users may publish the URI reference to a file that
contains their certificate on their business card.  This practice
is useful when there is no Directory entry for that user. HTTP is
widely deployed, and anonymous HTTP is accommodated by many
firewalls.  Thus, HTTP is an attractive alternative to Directory
access protocols for certificate and CRL distribution.

For convenience, the names of files that contain certificates
should have a suffix of ".cer".  Likewise, the names of files that
contain CRLs should have a suffix of ".crl". Files that contain
both certificates and CRLs should have a suffix of ".p7c".

Note that this service satisfies the the requirement to retrieve
information related to a certificate which is already identified by
a URI. It is not intended to satisfy the more general problem of
finding a certificate for a user about whom some other information,
such as their email address or corporate affiliation, is known.

Date: Tue, 08 Jul 1997 10:41:09 -0700
To: Charles Breed <[email-masked]>
From: Bob Kohn <[email-masked]>
Subject: Re: RSA mandatory for PKIX CMP?!
Cc: [email-masked]

Could you send me Li Gong's message?

At 10:43 AM 7/8/97 -0700, Charles Breed wrote:

>Referring to the latest PKIX draft on CMP:

>

>I sure hope someone is keeping score here; as you know, many have had 

>great difficulty with the RSA licensing agreement, it's restrictive 

>nature prohibits some software developers abilities and promotes a 

>select few wrt issuing X.509 certificates, (being a public CA). 

>

>I agree with John Marchioni, Li Gong, Amit Kapoor, Carlisle Adams and 

>Tom Markham. Since there is no strong technical reason for using RSA 

>as the mandatory Public Key Algorithm, check out 

>	http://www.cylink.com/products/security/rsa/rsa-dss2.htm

>

>the PKIX draft should use what is 

> - publicly available, 

> - open for review, 

> - widely interoperable,

> - patent free,

> - implementations are available,

> - major platforms support including NT, Mac, Unix, Java,

> - US government approved

> - separate key-pair for signing and encrypting session keys,

> - quickly becoming more deployed than RSA for better 

>   interoperability 

>

>and that is... Diffie-Hellman/Elgamal/DSS

>

>The PKIX group should note that the IESG Remanded the TLS document back 

>to the working group. One of the reasons was that it required licensing 

>of proprietary technology. The Remand message suggested that TLS 

>needed to make Diffie-Hellman/Elgamal/DSS as mandatory to implement cipher 

>suite.

>

>Charles Breed

>

>

>

>

Robert H. Kohn

Vice President, Business Development

PRETTY GOOD PRIVACY, INC.

2121 S. El Camino Real, 9th Floor

San Mateo, California 94403

Direct: (415) 524-6220

Cellular: (415) 297-6527

Main: (415) 572-0430

Fax: (415) 572-1932

[email-masked]

PGP Home Page: http://www.pgp.com

Personal Home page: http://www.kohnmusic.com/people/bkohn.html

<smaller>"If all the personal computers in the world - ~260 million
computers - were put to work on a single PGP-encrypted message, it would
still take an estimated 12 million times the age of the universe, on
average, to break a single message."

 -- William Crowell, Deputy Director of the National Security Agency, 

	testifying before the U.S. Congress on March 20, 1997</smaller>

Date: Tue, 08 Jul 1997 10:43:37 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Re: RSA mandatory for PKIX CMP?!

Referring to the latest PKIX draft on CMP:

I sure hope someone is keeping score here; as you know, many have had 
great difficulty with the RSA licensing agreement, it's restrictive 
nature prohibits some software developers abilities and promotes a 
select few wrt issuing X.509 certificates, (being a public CA). 

I agree with John Marchioni, Li Gong, Amit Kapoor, Carlisle Adams and 
Tom Markham. Since there is no strong technical reason for using RSA 
as the mandatory Public Key Algorithm, check out 
	http://www.cylink.com/products/security/rsa/rsa-dss2.htm

the PKIX draft should use what is 
 - publicly available, 
 - open for review, 
 - widely interoperable,
 - patent free,
 - implementations are available,
 - major platforms support including NT, Mac, Unix, Java,
 - US government approved
 - separate key-pair for signing and encrypting session keys,
 - quickly becoming more deployed than RSA for better 
   interoperability 

and that is... Diffie-Hellman/Elgamal/DSS

The PKIX group should note that the IESG Remanded the TLS document back 
to the working group. One of the reasons was that it required licensing 
of proprietary technology. The Remand message suggested that TLS 
needed to make Diffie-Hellman/Elgamal/DSS as mandatory to implement cipher 
suite.

Charles Breed

Date: Tue, 08 Jul 1997 10:36:56 -0700
To: "[email-masked]" <[email-masked]>
From: Luis Valente <[email-masked]>
Subject: RE: SET Root CA Extension

We (Navio Communications) currently use the SET Root CA extension in our
private certificate management hierarchy.

/Luis

At 04:51 PM 7/7/97 -0700, Ebbe Hansen wrote:
>Russ,
>
>The United States Postal Service has plans for using same private extension.
>
>Regards Ebbe Hansen @ Cylink Corp.
>
>----------
>From: 	Housley, Russ[SMTP:[email-masked]]
>Sent: 	Monday, July 07, 1997 7:20 AM
>To: 	[email-masked]
>Subject: 	SET Root CA Extension
>
>
>All:
>
>In the SET environment, the Root CA has a private extension that carries 
>the hash of the next public key to be used by the CA.  This extension 
>allows a single key (the current one) to be distributed by a trusted means, 
>then, as long as there are no compromises at the Root CA, subsequent CA 
>certificates can be trusted without trusted distribution of the public key.
>
>The syntax used by SET is:
>1587 -- Set protocol private extensions -- 
>1588
>1589 hashedRootKey EXTENSION ::= { -- Only in root certificates 
>1590 SYNTAX HashedRootKeySyntax
>1591 CRITICAL TRUE
>1592 IDENTIFIED BY id-set-hashedRootKey 1593 }
>1594
>1595 HashedRootKeySyntax ::= RootKeyThumb 1596
>1597 RootKeyThumb ::= SEQUENCE {
>1599 rootKeyThumbprint DD { SubjectPublicKeyInfo{{SupportedAlgorithms}} } 
>1600 }
>
>Are any other communities planning to use this mechanism?
>
>If many communities want to use this mechanism, then we should add it to 
>PKIX Part 1 to make sure that certificate users are prepared for this 
>CRITICAL extension.  If only the SET community is interested in this 
>extension, then we should not add it to PKIX Part 1.
>
>Russ
>
>
>
>

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: CRL Push over S/Mime
Date: Tue, 8 Jul 1997 12:37:18 -0400

Apologies for not jumping in sooner, but somehow gremlins had me dropped
temporarily from the pkix list and I thought it was just rather quiet!!

Here's the status, from my perspective on PKIX part 2:

I am in the process of preparing the revised I-D for PKIX part 2. I have
already made all the modifications that were agreed at the Memphis
meeting and together with the other authors are in a review of that text
and trying to finalize some of the details. The main changes that have
been made so far are:
- addition of a sentence in 4.1.2 re the caching of signed responses
- addition of text in 3 re the specific contents of a .cer and .crl file
- new section 2.3 and modifications to 1,2, and 2.5 to include the LDAP 
  operations for writing information (certs and crls) to a repository

Some other minor changes are expected during the next week as the other
authors review this text and a few outstanding comments on the
pre-Memphis draft. I plan to submit a revised draft on July 18th as I
will be overseas after that and am not confident I will have email
connectivity at my hotel. 

Re an email mechanism - this was not agreed in Memphis, but was a
suggestion on the pkix list in April I believe. Personally I have some
concerns over adding this. I think what we are trying to do here is
standardize tools for communication between a repository and other
entities and in the case of OCSP between a CA and other entities for
purposes of certificate and crl retrieval and
addition/deletion/modification as well as for possibly other data types
eg CPS.

If we continue to add more protocols for satisfying the same requirement
we will seriously hamper any ability to interoperate. We can't have all
repositories, for instance, required to support x number of protocols
and neither can we do the same to the relying party or CA systems. We
need to agree on as small a set as possible and try to make them
application independent. LDAP, FTP and OCSP all fit that category. HTTP
probably does as well, but email is bordering pretty close to
application specific. Also, I don't see the value of using a store and
forward protocol for either retrieval or management of repository
information and think that from a user's perspective the delays would
not be acceptable. I am yet to be convinced that we need (or want) and
email protocol in pkix 2. If it is agreed that this is required, I need
the input pretty soon or it will miss the deadline.

Re an http mechanism - I believe that the draft minutes indicated
someone was going to submit this to me for inclusion, but there were
changes proposed to the minutes and with my temporary loss of
connectivity I may have missed something. I have received no input on
this mechanism to date.

As for the requirement Denis raised for the "S" of S/MIME, I think he
raises some valid issues that pkix part 2 needs to deal with. Access
controls help somewhat in restricting those adding/deleting/modifying
information, but there are additional requirements potentially for
strong authentication, digital signatures and/or encryption on mainly
the "write" operations with a repository. LDAP v3 will allow for strong
authentication and I think we need to look into that as part of the
solution. If digital signatures and/or encryption are also required
(still to be determined) then we need to at least look into LDAP v3
possible solutions for that. PKCS # 7  may be appropriate or others such
as the signing and encryption support added to X.500 which accommodates
SPKM. But let's get the requirements straight first.

------------------
NOTE: WE'VE MOVED 

Sharon Boeyen                  
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario Canada K1V 1A7

mailto:[email-masked]       Tel: (613) 247-3181 
http://www.entrust.com          Fax: (613) 247-3690 
         Orchestrating Enterprise Security

>----------
>From: 	Peter Williams[SMTP:[email-masked]]
>Sent: 	July 7, 1997 7:36 AM
>To: 	Trevor Freeman
>Cc: 	Dwight Arthur; PKIX List
>Subject: 	Re: CRL Push over S/Mime
>
>Trevor Freeman wrote:
>
>> I have been asked to write up a mail based distribution for pkix part
>> two.
>
>Nice for someone to inform the WG and  list about the activity;
>comments
>might
>then be introduced to gain as much techncial input and concensus as
>possible
>before writing.
>
>> I do not understand the reasoning behind using s/mine for
>> certificate/crl distribution. The data being distributed is signed. so
>>
>> its integrity not in question. Its published data so why do we need
>> confidentiality.
>
>The purpose is to use S/MIME as one, conveninent, ubiquitous bearer for
>the pushed
>CRL protocol element (and updating the cert repositories & caches), not
>to exploit its
>message origination security service. As all conforming S/MIME
>implementations can process
>such indications, and mailboxes can process such message types
>automatically, the property
>now exists to automatially, efficiently propogate and cache CRL/cert
>information, using X.400 and
>bitnet-style distribution lists.
>
>The X.400 elements of Microsoft Exchange should have no particular
>problem
>with this at the quality end of the message solution space, reliably
>propogating CRLs thereby to business users, particularly. Other
>MIME-transporting
>messaging protocols can also bear the S/MIME message also, of course
>through benefits during transport and delivery may be less than with
>X.400-style UAs due to the nature of the protocols or their actual
>deployments.
>
>I suspect the above is the conventional thinking; perhaps read the PEM
>specs
>for other backgrounders on the theory of reliable messaging as a
>security
>infrastructure.
>
>Thinking unconventionally, of course practial solutions also exist when
>using S/MIME in massively available products. Just as Authenticode,
>when downloading certs in MSIE, invokes a vbscript-scipted control
>to actually effect transfer of info on the local UA system according to
>local
>permission policy , so then a S/MIME protected control/script could
>effect the update of
>the CRL./cert cache during delivery - the S/MIME signature being
>responsible
>for security control of such acts, exactly as with Authenticode
>signatures currently on java/activeX components delivering personal
>certs/CRLs
>at enrollment time..
>
>>
>>
>> If someone has some insight it would be welcome before I finish the
>> work.
>
>Hope this helps.
>
>>
>>
>> Dr Trevor Freeman
>> Senior Consultant
>> Microsoft Consulting Services
>> Microsoft Ltd ECU
>> > Tel:  UK(+44) 1734 270412
>> Fax: UK(+44) 1734 270435
>>
>> > -----Original Message-----
>> > From: Dwight Arthur [SMTP:[email-masked]]
>> > Sent: Thursday, July 03, 1997 5:53 PM
>> > To:   PKIX List
>> > Subject:      CRL Push over S/Mime
>> >
>> > Part Two describes CRL distribution via LDAP and FTP, and also OCSP,
>>
>> > presumably over HTTP. There is no description of S/Mime as a
>> protocol
>> > for the distribution of CRL's.
>> >
>> > If I understood some prior information published to this list by
>> > Netscape, Communicator 4 is most effectively able to respond to
>> CRL's
>> > received via S/Mime, and can even handle the expiration time
>> specified
>> > for a CRL.
>> >
>> > Is an enhancement to Part Two to describe CRL distribution over
>> S/Mime
>> > in the offing?
>> >
>> > -Dwight << File: Card for Dwight Arthur >>
>
>
>
>

From: [email-masked] (Amit Kapoor)
Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)
To: [email-masked] (pkix)
Date: Tue, 8 Jul 1997 09:03:58 -0700 (PDT)
Content-Length: 1067

> From: [email-masked] (David P. Kemp)
> 
> > From: [email-masked] (Amit Kapoor)
> > 

<snip>

> The purpose of IETF mandatory algorithms is to attempt to guarantee
> interoperability between all conforming implementations.  But TLS (SSL)

You have mentioned a excellent example in SSL.  The world is being split
in two diverging camps, RSA & D-H/DSA.  It makes it a tad difficult to
*guarantee* interoperability. If interoperability is a key goal (as it
should be) we should go with one algorithm.  DSA/D-H make sense as they
are patent free (or will be).

This does not preclude CA's to use RSA.  Companies can use it for internal
use or even between companies, if they so choose, but not for 
interoperability with public CA's.  It is much easier for companies with
RSA patents to add DSA/D-H then vice-versa.

A somewhat similar example is the email world.  Even though SMTP is
a IETF standard, companies are still using other email products.  But
SMTP has become the de-facto way of communicating between disparate
email systems.

cheers-

Amit

<snip>

Date: Tue, 08 Jul 1997 11:43:20 -0400
From: John DesJardins <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: RSA mandatory for PKIX CMP?!

I also disagree with mandating RSA for the same reasons others have put
forth.

Re:
Subject: 
        RSA mandatory for PKIX CMP?!
  Date: 
        Mon, 7 Jul 1997 17:44:34 +0100
  From: 
        John Marchioni <[email-masked]>
    To: 
        "[email-masked]" <[email-masked]>

Referring to the latest PKIX draft on CMP:

I strongly disagree with making RSA mandatory for any IETF "standard". 
Keep in mind that not every user community or vendor can or wants to pay
the royalties or license fees involved with RSA.  Mandatory RSA
certainly makes sense for companies like Entrust because they have a
license for the technology and thus, if CMP as drafted passes, will give
such vendors an unfair competitive advantage over vendors who cannot
acquire such a license.

>From a practical point of view, what if I have a CA that issues DSS certificates only?  Meaning my user community has no desire nor need for RSA signatures.  This draft would require that inorder to be compliant I would need to put enough RSA in my CA product to handle the CMPs only--get real!

Bottom line, there is no sound technical reason for making RSA
mandatory.  DSS and Diffie-Hellman can provide all of the same functions
as RSA including encryption-key negotiation with an EE without a
pre-issued certificate.

To the editors of the CMP specification I beg that you rethink or think
deeper about the issue.  PKIX should do what is best for all vendors and
their user communities if it is to be taken seriously.

Sorry if I'm coming on too strong but this just doesn't smell good to
me.

- John

Date: Tue, 08 Jul 1997 17:26:51 +0200
From: "Dr. Juergen Schneider" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [Fwd: Re: FW: RSA mandatory for PKIX CMP?! (fwd)]

This is a multi-part message in MIME format.

--------------418933BD43B0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David P. Kemp wrote:
> 
> As an employee of a government which until recently tried to make
> DSA mandatory, I believe that is the wrong approach.
> 
> Speaking from experience, I doubt that the regulatory approach of
> mandating *any* algorithm set will accelerate that process.  I
> recommend that PKIX profile the use of RSA, DSA, and EDSA, but not
> make any of them a MUST-implement.

A look into the cryptographer's bible (Bruce Schneier, Applied
Cryptography) seems to support David's view. On p. 493 it is
mentioned that DSA might infringe on a patent held by Schnorr (valid 
until 2008). So, using DSA might lead to similar patent restrictions
than using RSA.

Any comments ?

If no minimal subset of mechanisms can be guaranteed by the standard
it is up to bilateral agreement between communication partners to
make it work, right ?

-- 
Dr. Juergen Schneider                                                   
SAP AG                                             Tel. +49-6227-34-8273
Basis-01, Neurottstr. 16                           Fax. +49-6227-34-5336
D-69190 Walldorf, Germany                  E-mail. [email-masked]

--------------418933BD43B0
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Date: Tue, 8 Jul 1997 09:10:25 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)

> From: [email-masked] (Amit Kapoor)
> 
> I had a minor email exchange with Carlisle Adams on the same point.
> I disagree with the use of RSA for the same reasons mentioned
> by John Marchioni & Li Gong.
> 
> I think it would make more sense to use DSA and D-H as the
> mandatory algorithms. Reasons:

As an employee of a government which until recently tried to make
DSA mandatory, I believe that is the wrong approach.

The purpose of IETF mandatory algorithms is to attempt to guarantee
interoperability between all conforming implementations.  But TLS (SSL)
has no mandatory supported algorithms and yet market forces have resulted
in a substantial degree of interoperability between SSL implementations.
To date, that interoperability has been RSA-based, but there is support
for DSA/DH in both commercial and free (SSLeay) implementations.  If
the costs (monetary, administrative, and performance) of fielding
RSA-based solutions become too onerous, as they clearly have recently
for some segments of the marketplace, DSA (or perhaps EDSA) will gain
market share to the point where interoperability is no longer a
concern for DSA-only implementations.

Speaking from experience, I doubt that the regulatory approach of
mandating *any* algorithm set will accelerate that process.  I
recommend that PKIX profile the use of RSA, DSA, and EDSA, but not
make any of them a MUST-implement.

--------------418933BD43B0--

Date: Tue, 8 Jul 1997 09:10:25 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)

> From: [email-masked] (Amit Kapoor)
> 
> I had a minor email exchange with Carlisle Adams on the same point.
> I disagree with the use of RSA for the same reasons mentioned
> by John Marchioni & Li Gong.
> 
> I think it would make more sense to use DSA and D-H as the
> mandatory algorithms. Reasons:

As an employee of a government which until recently tried to make
DSA mandatory, I believe that is the wrong approach.

The purpose of IETF mandatory algorithms is to attempt to guarantee
interoperability between all conforming implementations.  But TLS (SSL)
has no mandatory supported algorithms and yet market forces have resulted
in a substantial degree of interoperability between SSL implementations.
To date, that interoperability has been RSA-based, but there is support
for DSA/DH in both commercial and free (SSLeay) implementations.  If
the costs (monetary, administrative, and performance) of fielding
RSA-based solutions become too onerous, as they clearly have recently
for some segments of the marketplace, DSA (or perhaps EDSA) will gain
market share to the point where interoperability is no longer a
concern for DSA-only implementations.

Speaking from experience, I doubt that the regulatory approach of
mandating *any* algorithm set will accelerate that process.  I
recommend that PKIX profile the use of RSA, DSA, and EDSA, but not
make any of them a MUST-implement.

Date: Tue, 8 Jul 1997 07:11:09 -0500
To: [email-masked] (Amit Kapoor)
From: [email-masked] (Tom Markham)
Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)
Cc: [email-masked] (pkix)

>I disagree with the use of RSA for the same reasons mentioned
>by John Marchioni & Li Gong.

I also disagree with making RSA mandatory. I have a number of customers who
use DSS for very good reasons. Forcing the use of RSA will not build
support for the standard.

Tom Markham

From: [email-masked] (Amit Kapoor)
Subject: Re: FW: RSA mandatory for PKIX CMP?! (fwd)
To: [email-masked] (pkix)
Date: Mon, 7 Jul 1997 21:29:01 -0700 (PDT)
Content-Length: 1975

I had a minor email exchange with Carlisle Adams on the same point.
I disagree with the use of RSA for the same reasons mentioned
by John Marchioni & Li Gong.

I think it would make more sense to use DSA and D-H as the
mandatory algorithms. Reasons:

1.  DSA is patent free and implementations are available
    on most platforms including Java.

2.  D-H patent will expire (I believe Sept-Oct of this year)
    soon.  I think it will be at least that long for this
    draft spec to stabilize or get converted to a "standard".
    D-H along with 56-bit DES should be sufficient to provide
    for privacy.

Carlisle (I will paraphrase since I deleted his message) responded
with:

a.  The idea had been debated and RSA was chosen as it was most
    common (for signing).

b.  For privacy he mentioned some problem for EE without pre-certificates.

(Carlisle, please correct me if I am totally off-track).

Point a seems debatable as John and Li's message indicate :)  However
since it is not a technical reason, it can be skipped IMO.  I have talked
to couple of people here on b and they mentioned that the same can
be achieved using D-H and DES without any problems.  Requires the CA
to publish its D-H public number and so on....

Another point is that CMP is both a client & server side technology.
Mandating RSA will mean that even client side developer's will be required
to buy RSA patents (e.g an email client wanting to get a certificate from 
CA).  As it is the cost of setting up a infrastructure like this one is high,
let us not add to it.  If the idea is to make CMP a universal technology,
we should use underlying technology available to everyone.

To stress John's point I think it is stacking odds againist small
developer's (like myself :)) by mandating the use of a patented
algorithm.  So unless there is a strong technical reason for using
RSA, it should be dropped for something that is *universally* available
(or will be soon :)).

cheers-

Amit

Date: Mon, 7 Jul 1997 18:50:13 -0700
From: Li Gong <[email-masked]>
To: [email-masked]
Subject: Re: FW: RSA mandatory for PKIX CMP?!

Hi,

I do not normally follow this mailing list, so apologies for posting.
It has recently been brought to my attention that certain IETF
standards (PKIX draft in particular) are proposing to make RSA a
"mandatory" feature.

This is clearly unacceptable for the Java platform.

The main problem is that RSA public key technology is not available
royalty free on the Java platform (when I say royalty free, I mean
that you can include an RSA implemention in your Java-based product
and expose the RSA APIs without the fear of ending up in some court).

Until RSA public key technology becomes freely available on the Java
platform, picking RSA as a mandatory feature will not help but to
derail a potential IETF standard, because developers on the Java
platform will likely be forced to adopt an alternative feature.

By the way, the *only sure sign* that RSA is freely available in Java
is when JavaSoft ships an exposed RSA implementation in the baseline
Java platform, such as the Java Cryptography Extension (JCE).

Best regards,

Li
--
Li Gong, PhD
Java Security Architect and Senior Engineering Manager
JavaSoft, Cupertino, California, USA
Email: [email-masked]
Web: http://java.sun.com/people/gong
Tel: 408-343-1825 and Fax: 408-343-1993

From: John Marchioni <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RSA mandatory for PKIX CMP?!
Date: Mon, 7 Jul 1997 17:44:34 +0100

Referring to the latest PKIX draft on CMP:

I strongly disagree with making RSA mandatory for any IETF "standard".  Keep in mind that not every user community or vendor can or wants to pay the royalties or license fees involved with RSA.  Mandatory RSA certainly makes sense for companies like Entrust because they have a license for the technology and thus, if CMP as drafted passes, will give such vendors an unfair competitive advantage over vendors who cannot acquire such a license.

>From a practical point of view, what if I have a CA that issues DSS certificates only?  Meaning my user community has no desire nor need for RSA signatures.  This draft would require that inorder to be compliant I would need to put enough RSA in my CA product to handle the CMPs only--get real!

Bottom line, there is no sound technical reason for making RSA mandatory.  DSS and Diffie-Hellman can provide all of the same functions as RSA including encryption-key negotiation with an EE without a pre-issued certificate.

To the editors of the CMP specification I beg that you rethink or think deeper about the issue.  PKIX should do what is best for all vendors and their user communities if it is to be taken seriously.

Sorry if I'm coming on too strong but this just doesn't smell good to me.

- John

From: Ebbe Hansen <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: SET Root CA Extension
Date: Mon, 7 Jul 1997 16:51:44 -0700

Russ,

The United States Postal Service has plans for using same private extension.

Regards Ebbe Hansen @ Cylink Corp.

----------
From: 	Housley, Russ[SMTP:[email-masked]]
Sent: 	Monday, July 07, 1997 7:20 AM
To: 	[email-masked]
Subject: 	SET Root CA Extension

All:

In the SET environment, the Root CA has a private extension that carries 
the hash of the next public key to be used by the CA.  This extension 
allows a single key (the current one) to be distributed by a trusted means, 
then, as long as there are no compromises at the Root CA, subsequent CA 
certificates can be trusted without trusted distribution of the public key.

The syntax used by SET is:
1587 -- Set protocol private extensions -- 
1588
1589 hashedRootKey EXTENSION ::= { -- Only in root certificates 
1590 SYNTAX HashedRootKeySyntax
1591 CRITICAL TRUE
1592 IDENTIFIED BY id-set-hashedRootKey 1593 }
1594
1595 HashedRootKeySyntax ::= RootKeyThumb 1596
1597 RootKeyThumb ::= SEQUENCE {
1599 rootKeyThumbprint DD { SubjectPublicKeyInfo{{SupportedAlgorithms}} } 
1600 }

Are any other communities planning to use this mechanism?

If many communities want to use this mechanism, then we should add it to 
PKIX Part 1 to make sure that certificate users are prepared for this 
CRITICAL extension.  If only the SET community is interested in this 
extension, then we should not add it to PKIX Part 1.

Russ

Date: Mon, 07 Jul 97 14:20:55 
From: "Housley, Russ" <[email-masked]>
Encoding: 1147 Text
To: [email-masked]
Subject: SET Root CA Extension

All:

In the SET environment, the Root CA has a private extension that carries 
the hash of the next public key to be used by the CA.  This extension 
allows a single key (the current one) to be distributed by a trusted means, 
then, as long as there are no compromises at the Root CA, subsequent CA 
certificates can be trusted without trusted distribution of the public key.

The syntax used by SET is:
1587 -- Set protocol private extensions -- 
1588
1589 hashedRootKey EXTENSION ::= { -- Only in root certificates 
1590 SYNTAX HashedRootKeySyntax
1591 CRITICAL TRUE
1592 IDENTIFIED BY id-set-hashedRootKey 1593 }
1594
1595 HashedRootKeySyntax ::= RootKeyThumb 1596
1597 RootKeyThumb ::= SEQUENCE {
1599 rootKeyThumbprint DD { SubjectPublicKeyInfo{{SupportedAlgorithms}} } 
1600 }

Are any other communities planning to use this mechanism?

If many communities want to use this mechanism, then we should add it to 
PKIX Part 1 to make sure that certificate users are prepared for this 
CRITICAL extension.  If only the SET community is interested in this 
extension, then we should not add it to PKIX Part 1.

Russ

Date: Mon, 07 Jul 1997 12:36:25 +0100
From: Peter Williams <[email-masked]>
To: Trevor Freeman <[email-masked]>
CC: Dwight Arthur <[email-masked]>, PKIX List <[email-masked]>
Subject: Re: CRL Push over S/Mime

Trevor Freeman wrote:

> I have been asked to write up a mail based distribution for pkix part
> two.

Nice for someone to inform the WG and  list about the activity; comments
might
then be introduced to gain as much techncial input and concensus as
possible
before writing.

> I do not understand the reasoning behind using s/mine for
> certificate/crl distribution. The data being distributed is signed. so
>
> its integrity not in question. Its published data so why do we need
> confidentiality.

The purpose is to use S/MIME as one, conveninent, ubiquitous bearer for
the pushed
CRL protocol element (and updating the cert repositories & caches), not
to exploit its
message origination security service. As all conforming S/MIME
implementations can process
such indications, and mailboxes can process such message types
automatically, the property
now exists to automatially, efficiently propogate and cache CRL/cert
information, using X.400 and
bitnet-style distribution lists.

The X.400 elements of Microsoft Exchange should have no particular
problem
with this at the quality end of the message solution space, reliably
propogating CRLs thereby to business users, particularly. Other
MIME-transporting
messaging protocols can also bear the S/MIME message also, of course
through benefits during transport and delivery may be less than with
X.400-style UAs due to the nature of the protocols or their actual
deployments.

I suspect the above is the conventional thinking; perhaps read the PEM
specs
for other backgrounders on the theory of reliable messaging as a
security
infrastructure.

Thinking unconventionally, of course practial solutions also exist when
using S/MIME in massively available products. Just as Authenticode,
when downloading certs in MSIE, invokes a vbscript-scipted control
to actually effect transfer of info on the local UA system according to
local
permission policy , so then a S/MIME protected control/script could
effect the update of
the CRL./cert cache during delivery - the S/MIME signature being
responsible
for security control of such acts, exactly as with Authenticode
signatures currently on java/activeX components delivering personal
certs/CRLs
at enrollment time..

>
>
> If someone has some insight it would be welcome before I finish the
> work.

Hope this helps.

>
>
> Dr Trevor Freeman
> Senior Consultant
> Microsoft Consulting Services
> Microsoft Ltd ECU
> > Tel:  UK(+44) 1734 270412
> Fax: UK(+44) 1734 270435
>
> > -----Original Message-----
> > From: Dwight Arthur [SMTP:[email-masked]]
> > Sent: Thursday, July 03, 1997 5:53 PM
> > To:   PKIX List
> > Subject:      CRL Push over S/Mime
> >
> > Part Two describes CRL distribution via LDAP and FTP, and also OCSP,
>
> > presumably over HTTP. There is no description of S/Mime as a
> protocol
> > for the distribution of CRL's.
> >
> > If I understood some prior information published to this list by
> > Netscape, Communicator 4 is most effectively able to respond to
> CRL's
> > received via S/Mime, and can even handle the expiration time
> specified
> > for a CRL.
> >
> > Is an enhancement to Part Two to describe CRL distribution over
> S/Mime
> > in the offing?
> >
> > -Dwight << File: Card for Dwight Arthur >>

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part4-01.txt
Date: Mon, 07 Jul 1997 09:47:41 -0400
Sender: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Public-Key Infrastructure 
 (X.509) Working Group of the IETF.                                        

       Title     : Internet Public Key Infrastructure  Part IV: Certificate
                   Policy and Certification Practices Framework            
       Author(s) : S. Chokhani, W. Ford
       Filename  : draft-ietf-pkix-ipki-part4-01.txt
       Pages     : 45
       Date      : 07/03/1997

This document presents a framework to assist the writers of certificate 
policies or certification practice statements for certification authorities
and public key infrastructures.   In particular, the framework provides a 
comprehensive list of topics that potentially (at the writer's discretion) 
need to be covered in a certificate policy definition or a certification 
practice statement. It is intended that this document, when fully 
developed, be published as an Informational RFC.                           

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-pkix-ipki-part4-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part4-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-pkix-ipki-part4-01.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-part4-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-pkix-ipki-part4-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 04 Jul 1997 14:19:43 -0400
From: Dwight Arthur <[email-masked]>
To: PKIX List <[email-masked]>
Subject: Re: CRL Push over S/Mime

Dwight Arthur wrote:

Trevor Freeman wrote:
>
> I have been asked to write up a mail based distribution for pkix part
> two.
> I do not understand the reasoning behind using s/mine for
> certificate/crl distribution. The data being distributed is signed. so
> its integrity not in question. Its published data so why do we need
> confidentiality.
>
> If someone has some insight it would be welcome before I finish the
> work.
>
I would be comfortable with:
a. The CRL is signed
b. The signature is backed by an X509 cert signed by the
   CA whose CRL is being distributed
c. The CRL has an expiration date/time.
Is S/Mime needed for this?

-Dwight

From: Trevor Freeman <[email-masked]>
To: [email-masked]
Cc: Dwight Arthur <[email-masked]>, PKIX List <[email-masked]>
Subject: RE: CRL Push over S/Mime
Date: Fri, 4 Jul 1997 10:44:06 -0700

Dennis, 
This raises an interesting point, but I am not sure that s/mime
distribution of CRL fixes the underlying problem. The CA has no control
over how quickly a CRL is distributed once it has been published
regardless of the method of publication. If a user already has a valid
CRL, they are under no obligation to re-query for a new one. In the case
of this email based distribution, the email server process is not a CA,
so what is the latency between the CA issuing a new CRL and it reaching
the email server. True, the s/mime distribution of the fixes one
problem, but then the next target would be stopping the new CRL reaching
the email server. If the result of the certificate validation is so
sensitive e.g. financial transaction, legal contract etc. that the
latency introduced by the CRL process is an issue, then this is a case
for on-line validation. In a sense, I think the man in the middle relay
of an existing CRL is just another delay.
Trevor
> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Friday, July 04, 1997 10:07 PM
> To:	Trevor Freeman
> Cc:	Dwight Arthur; PKIX List
> Subject:	Re: CRL Push over S/Mime
> 
> Trevor Freeman wrote:
> > 
> > I have been asked to write up a mail based distribution for pkix
> part
> > two.
> > I do not understand the reasoning behind using s/mine for
> > certificate/crl distribution. The data being distributed is signed.
> so
> > its integrity not in question. Its published data so why do we need
> > confidentiality.
> > 
> > If someone has some insight it would be welcome before I finish the
> > work.
> 
> I have had a discussion about this with Sharon. For certificates,
> S/MIME
> is not needed at all. For CRLs, S/MIME with a content type of
> "SignedData" *may* be useful to counter the thread of the replay of a
> previous, but apparently valid CRL.
> 
> Let me explain. CRLs are normally issued regularly before the date of
> the next publication. In case of emergency a CRL may be issued well
> before that date. An attacker could intercept that CRL and replace it
> by
> the previous but yet valid CRL. Unless the response is signed and
> incorporates a challenge from the requester, this will not be noticed
> by
> the requester.
> 
> Denis
> 
> -- 
> 
>       Denis Pinkas     Bull S.A.         E-mail :
> [email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 04 Jul 1997 11:36:36 -0700
To: Nick Pope <[email-masked]>, Sharon Boeyen <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: Authority Revocation List - cont'd
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Molesworth Roger (Exchange)" <[email-masked]>

Nick:

The intent was that if the issuingDistributionPoint extension is absent,
the CRL shall contain...  This is regardless of whether the CRL is stored
in the CRL or ARL attribute which, as you correctly point out, is not a
reliable security control.

Owing to an editorial error, the sentence is attached to the wrong para,
and this needs to be fixed. 

Warwick

At 10:29 AM 7/4/97 +0000, Nick Pope wrote:
>Sharon,
>
>Sorry to come back to the issue of Authority Revocation List but I have 
>some concern that there is:
>
>- Ambiguity in the current text on use of ARL & CRLs,  
>the use of the flags onlyContainsUserCerts and onlyContainsCACerts in 
>12.6.3.1
>
>-  potential for a security weakness resulting from confusion between 
>CRLs and ARLs.
>
>The sentence in 2nd para of 12.6.3.1 that I referred to earlier 
> "If this field is absent the CRL shall contain entries for all revoked 
>unexpired certificates issued by the CRL issuer." could be read two 
>ways:
>
>a)  the issuingDistributionPoint ("this field") is absent then the CRL 
>must be complete.
>
>b)  if the distributionPoint component of the issuingDistributionPoint 
>is absent (but the whole field present) then the CRL must be complete.
>
>(a) above implies that if ARLs are used then the issing distribution 
>point field must be present.
>
>(b) implies that if the Issue Distribution distribution point 
>field is to be used then either there must be a distribution point name 
>or indirect CRL must be used.
>
>Coming on to the potential weakness, if ARLs are used without any 
>onlyContainsCACerts flag then it is possible for an attacker to switch 
>the values in the CRL and ARL attributes so that when a CRL attribute 
>is retrieved it does not contain his/her revoked certificate.  I don't 
>believe that it is sufficient to trust the directory attribute type 
>which is unprotected.
>
>Thus, I believe that onlyContainsCACerts should be required for ARLs.
>
>How do you interpret this text?
>Do you agree that there is a need for clarification? 
>Should the use of onlyContainsCACerts be required for ARLs?
>Do you agree this warents a defect report?
>Can this be briefly discussed at Hesinki?
>
>Nick
>
>
>
>-------------------------------------
>
>
>Security & Standards
>Suite A
>191 Moulsham St.
>Chelmsford
>Essex
>CM2 0LG
>U.K.
>
>Tel: +44 1245 495018
>Fax: +44 1245 494517
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date: Fri, 04 Jul 1997 14:05:04 UT
From: Michael Leahy <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: questions about name constraints extension

Hi

I have looking at the NameConstraint extension and I would like some clarification on whether my examples are correct or incorrect. I also have a few questions/thoughts that I like some comments on

Example 1:
permittedSubTrees = { base: c=ie, o=isocor,  Maximum 2 }

does this mean that "c=ie, o=isocor, cn=XXXXX" is *invalid* (because it's not on the permitted List) while anything in the form "c=ie, o=isocor, ou=YYYYY, cn=XXXXX" is valid  (Maximum 2 making it valid)

Example 2:
excludedSubTrees = { base: c=ie, o=isocor, ou=Purchasing,  Minimum 2 }

does this mean that "c=ie, o=isocor, ou=Purchasing, cn=XXXXX" is not allowed (identified by the excluded list)  while "c=ie, o=isocor, ou=Purchasing, ou1=YYYYY, cn=XXXXX" is ok because it's not identified.

Some more questions:
1) Is it safe to assume that an entry on the PermittedSubTree would *not* use the Minimum value (the default is zero so ignore it) ?   

IMHO the CA should not use the Minimum value on the PermittedSubTree - The only reason I think they might want to use it - would be to ensure that the CA would/could only issue subject names within a certain range. But if they want to do that they should be *explicit* and add the suitable value to the ExcludedSubTree 

Is this a valid assumption ?

2) Is it safe to assume that the ExcludedSubTree would not use the Maximum value. My logic here would be the base name specifies the starting excluded name while the Minumum value effectively bounds the name space by saying beyond this level we are fine

excludedSubTrees = { base: c=ie, o=isocor, ou=Purchasing,  Minimum 2}

Regards
Michael Leahy
ISOCOR

Date: Fri, 04 Jul 1997 14:06:50 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Trevor Freeman <[email-masked]>
Cc: Dwight Arthur <[email-masked]>, PKIX List <[email-masked]>
Subject: Re: CRL Push over S/Mime

Trevor Freeman wrote:
> 
> I have been asked to write up a mail based distribution for pkix part
> two.
> I do not understand the reasoning behind using s/mine for
> certificate/crl distribution. The data being distributed is signed. so
> its integrity not in question. Its published data so why do we need
> confidentiality.
> 
> If someone has some insight it would be welcome before I finish the
> work.

I have had a discussion about this with Sharon. For certificates, S/MIME
is not needed at all. For CRLs, S/MIME with a content type of
"SignedData" *may* be useful to counter the thread of the replay of a
previous, but apparently valid CRL.

Let me explain. CRLs are normally issued regularly before the date of
the next publication. In case of emergency a CRL may be issued well
before that date. An attacker could intercept that CRL and replace it by
the previous but yet valid CRL. Unless the response is signed and
incorporates a challenge from the requester, this will not be noticed by
the requester.

Denis

-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Sharon Boeyen <[email-masked]>
Date: Fri, 4 Jul 1997 10:29:31 +0000
Subject: Re: Authority Revocation List - cont'd
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Molesworth Roger (Exchange)" <[email-masked]>
Priority: normal

Sharon,

Sorry to come back to the issue of Authority Revocation List but I have 
some concern that there is:

- Ambiguity in the current text on use of ARL & CRLs,  
the use of the flags onlyContainsUserCerts and onlyContainsCACerts in 
12.6.3.1

-  potential for a security weakness resulting from confusion between 
CRLs and ARLs.

The sentence in 2nd para of 12.6.3.1 that I referred to earlier 
 "If this field is absent the CRL shall contain entries for all revoked 
unexpired certificates issued by the CRL issuer." could be read two 
ways:

a)  the issuingDistributionPoint ("this field") is absent then the CRL 
must be complete.

b)  if the distributionPoint component of the issuingDistributionPoint 
is absent (but the whole field present) then the CRL must be complete.

(a) above implies that if ARLs are used then the issing distribution 
point field must be present.

(b) implies that if the Issue Distribution distribution point 
field is to be used then either there must be a distribution point name 
or indirect CRL must be used.

Coming on to the potential weakness, if ARLs are used without any 
onlyContainsCACerts flag then it is possible for an attacker to switch 
the values in the CRL and ARL attributes so that when a CRL attribute 
is retrieved it does not contain his/her revoked certificate.  I don't 
believe that it is sufficient to trust the directory attribute type 
which is unprotected.

Thus, I believe that onlyContainsCACerts should be required for ARLs.

How do you interpret this text?
Do you agree that there is a need for clarification? 
Should the use of onlyContainsCACerts be required for ARLs?
Do you agree this warents a defect report?
Can this be briefly discussed at Hesinki?

Nick

-------------------------------------

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

Date: Thu, 03 Jul 1997 17:07:54 -0500
To: [email-masked]
From: Rick Hornbeck <[email-masked]>

subscribe
Richard N. Hornbeck, J.D., M.S.
Electronic Commerce Services 

From: Trevor Freeman <[email-masked]>
To: Dwight Arthur <[email-masked]>
Cc: PKIX List <[email-masked]>
Subject: RE: CRL Push over S/Mime
Date: Thu, 3 Jul 1997 14:15:14 -0700

I have been asked to write up a mail based distribution for pkix part
two. 
I do not understand the reasoning behind using s/mine for
certificate/crl distribution. The data being distributed is signed. so
its integrity not in question. Its published data so why do we need
confidentiality. 

If someone has some insight it would be welcome before I finish the
work.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel:  UK(+44) 1734 270412 
Fax: UK(+44) 1734 270435

> -----Original Message-----
> From:	Dwight Arthur [SMTP:[email-masked]]
> Sent:	Thursday, July 03, 1997 5:53 PM
> To:	PKIX List
> Subject:	CRL Push over S/Mime
> 
> Part Two describes CRL distribution via LDAP and FTP, and also OCSP,
> presumably over HTTP. There is no description of S/Mime as a protocol
> for the distribution of CRL's.
> 
> If I understood some prior information published to this list by
> Netscape, Communicator 4 is most effectively able to respond to CRL's
> received via S/Mime, and can even handle the expiration time specified
> for a CRL.
> 
> Is an enhancement to Part Two to describe CRL distribution over S/Mime
> in the offing?
> 
> -Dwight << File: Card for Dwight Arthur >> 

Date: Thu, 03 Jul 1997 12:52:43 -0400
From: Dwight Arthur <[email-masked]>
To: PKIX List <[email-masked]>
Subject: CRL Push over S/Mime

This is a multi-part message in MIME format.
--------------32FBAA03AA99F383372BA304
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Part Two describes CRL distribution via LDAP and FTP, and also OCSP,
presumably over HTTP. There is no description of S/Mime as a protocol
for the distribution of CRL's.

If I understood some prior information published to this list by
Netscape, Communicator 4 is most effectively able to respond to CRL's
received via S/Mime, and can even handle the expiration time specified
for a CRL.

Is an enhancement to Part Two to describe CRL distribution over S/Mime
in the offing?

-Dwight
--------------32FBAA03AA99F383372BA304
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dwight Arthur
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Dwight Arthur
n:              Arthur;Dwight
org:            National Securities Clearing
adr:            55 Water Street;;22nd Floor;New York;NY;10041-0082;US
email;internet: [email-masked]
title:          Managing Director, Systems
tel;work:       (212) 412-8687
tel;fax:        (212) 908-2345
tel;home:       pager: (917) 646-6682
x-mozilla-cpt:  <none>;1
x-mozilla-html: TRUE
end:            vcard

--------------32FBAA03AA99F383372BA304--

Date: Thu, 03 Jul 1997 18:39:49 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: [email-masked]
Subject: PKIX Part 1 : validity period

Since the next meeting is slowly coming, I took a look at the latest
specification draft-ietf-pkix-ipki-part1-04.txt from March 26 1996
(1997) and the text on validity (section 4.1.2.5 ) still looks like
that:         ^^
           
This field indicates the dates on which the certificate becomes valid
(notBefore) and on which the certificate ceases to be valid (notAfter). 
(...)

This text still needs to be ammended to reflect the discussion we had in
San Jose. 
I am expecting something along the following lines:

This field indicates the time period during which the CA warrants that
it will maintain information about the status of the certificate, i.e.
maintain revocation data. 

Other changes are needed as well.

When is the next version scheduled ?

Denis
-- 

      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Wed, 2 Jul 1997 16:56:01 -0400
To: Bob Jueneman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: RE: Safe Key Generation
Cc: [email-masked]

Bob,

	I think you are correct in stating that only NT has been C2
evaluated and that evaluation does not include the networking software,
which brings into question the utility of the evaluation in just about any
practical setting.

Steve

Date: Wed, 2 Jul 1997 12:15:55 -0700
From: [email-masked] (Matt Bishop)
To: [email-masked]
Subject: CFP: 1998 SNDSS (updated; last reminder!)

CALL FOR PAPERS

The Internet Society Symposium on Network and Distributed System Security

Where: Catamaran Resort, San Diego, California
When: March 11-13, 1998

GOAL: The symposium will foster information exchange between hardware and
software developers of network and distributed system security services.
The intended audience is those who are interested in the practical aspects
of network and distributed system security, focusing on actual system
design and implementation, rather than theory.  Encouraging and enabling
the Internet community to apply, deploy, and advance the state of available
security technology is the major focus of symposium.  Symposium proceedings
will be published by the Internet Society.  Topics for the symposium
include, but are not limited to, the following:

* Architectures for large-scale, heterogeneous distributed systems
* Security in malleable systems: mobile code, mobile agents, dynamic policy
  updates, etc.
* Special problems: e.g. interplay between security goals and other goals --
  efficiency, reliability, interoperability, resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies -- very
  large systems like the Internet, high-speed systems like the gigabit 
  testbeds, wireless systems, and personal communication systems.
* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, Archie, and WAIS.
* Electronic commerce:  payment services, fee-for-access, EDI, notary;
  endorsement, licensing, bonding, and other forms of assurance; intellectual 
  property protections

GENERAL CHAIR:
	David Balenson, Trusted Information Systems
PROGRAM CHAIRS:
	Matt Bishop, University of California at Davis
	Steve Kent, BBN
PROGRAM COMMITTEE:
	Steve Bellovin, AT&T Labs -- Research
	Doug Engert, Argonne National Laboratories
	Warwick Ford, VeriSign
	Li Gong, JavaSoft
	Rich Graveman, Bellcore
	Ari Juels, RSA Laboratories
	Tom Longstaff, CERT/CC
	Doug Maughan, National Security Agency
	Dan Nessett, 3Com Corporation
	Rich Parker, NATO
	Michael Roe, Cambridge University
	Rob Rosenthal, DARPA
	Wolfgang Schneider, GMD Darmstadt
	Christoph Schuba, Purdue University
	Win Treese, Open Market, Inc.
	Jonathan Trostle, Novell
	Gene Tsudik, USC/Information Sciences Institute
	Steve Welke, Institute for Defense Analyses
LOCAL ARRANGEMENTS CHAIR:
	Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
	Steve Welke, Institute for Defense Analyses
LOGISTICS CHAIR:
	Torryn Brazell, Internet Society

SUBMISSIONS: The committee invites technical papers and panel
proposals, for topics of technical and general interest.  Technical
papers should be 10-20 pages in length.  Panel proposals should be two
pages and should describe the topic, identify the panel chair, explain
the format of the panel, and list three to four potential panelists.
Technical papers will appear in the proceedings.  A description of each
panel will appear in the proceedings, and may at the discretion of the
panel chair, include written position statements from each panelist.

Each submission must contain a separate title page with the type of
submission (paper or panel), the title or topic, the names of the
author(s), organizational affiliation(s), telephone and FAX numbers,
postal addresses, Internet electronic mail addresses, and must list a
single point of contact if more than one author.  The names of authors,
affiliations, and other identifying information should appear only on
the separate title page.

Submissions must be received by 1 August 1997, and should be made via
electronic mail in either PostScript or ASCII format.  If the committee
is unable to print a PostScript submission, it will be returned and
hardcopy requested.  Therefore, PostScript submissions should arrive
well before 1 August.  If electronic submission is difficult,
submissions should be sent via postal mail.

All submissions and program related correspondence (only) should be
directed to the program chair:  Matt Bishop, Department of Computer
Science, University of California at Davis, Davis CA  95616-8562,
Email: [email-masked]. Phone: +1 (916) 752-8060,
FAX: +1 (916) 752-4767,

Dates, final call for papers, advance program, and registration
information will be available at the URL:
http://www.isoc.org/conferences/ndss98.

Each submission will be acknowledged by e-mail.  If acknowledgment is
not received within seven days, please contact the program chair as in-
dicated above.  Authors and panelists will be notified of acceptance by
1 October 1997.  Instructions for preparing camera-ready copy for the
proceedings will be sent at that time.  The camera-ready copy must be
received by 1 November 1997.

Date: Wed, 02 Jul 1997 11:12:06 -0600
From: Bob Jueneman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RE: Safe Key Generation

Peter sent this to me off the list, but I would be very remiss if I did not
acknowledge the significant contribution that Entrust has made, even as a
Canadian company, in getting their product certified against the US FIPS
140-1 standard.

But unless I slept though something momentous, I never heard of a C2 version
of Windows  3.1 or Windows 95, for that matter.  Windows NT, yes, maybe, if
properly installed, although I don't believe Microsoft has received their
official NCSC certification yet (I may be wrong -- I know it is coming). 
And to the best of my knowledge, that certification goes out the Window (no
pun intended) as soon as you connect NT to a network.  And how many NT's do
you know of that are not connected to a network?

But my real point was, without some Truth in Advertising labeling of the
vcertificate or of each digital signature, how do you know?  And without
knowing, how can you really know how much credence to associate with any
particular digital signature?

Bob

>>> Peter Whittaker <[email-masked]> 07/02/97 05:21AM >>>
>At 10:08 AM -0700 7/1/97, Bob Jueneman wrote:
>>How many user key pairs do you know of that were generated on TCSEC-rated
A1
>>systems using FIPS 140-1 rated level 4 cryptographic implementations? 
None,
>>you say?  OK, how many key pairs do you know of that were at least
generated
>>on a C2 rated system, using a FIPS 140-1 level 1 rated crypto?  Again,
>>virtually none, you say?

I missed the original post, so sorry for jumping in a post or two late.

Virtually none?  To be perfectly pedantic, you are probably right, given
that most people do not run a C2 version of Windows 3.1.  To be more
practical, the Entrust cryptomodule was FIPS 140-1 level 1 validated
under the C2 flavour of Windows 3.1.  Given that the cryptomodule code
is the same under C2 Windows and non-C2 Windows, then we can guess that
some significant fraction of Entrust signing key pairs were so generated
(guessing a significant fraction based on the idea that only some of the
non-C2 Windows boxes out there have been compromised).

pww

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

                                                                            

Date: Tue, 01 Jul 1997 11:48:07 -0700
To: Nada Kapidzic Cicovic <[email-masked]>, [email-masked]
From: Luis Valente <[email-masked]>
Subject: Re: registering a new object identifier

In the US you would do so by requesting an OID for your company from ANSI
(see http://cell-relay.indiana.edu/cell-relay/FAQ/nsap/fact.html for details).

I suspect that in the Sweden the Swedish National Standards Body (whatever
its name is) will also be the registration authority for OIDs.

/Luis

At 10:21 AM 7/1/97 +0200, Nada Kapidzic Cicovic wrote:
>I was wondering what would be the best way of registering a new
>organisational object identifier (in order to be able to make object
>identifiers for private extensions and certification policies)? 
>
>It seems that IANA is doing that job for SNMP business. Are there any other
>efficient ways for the registration? 
>
>Any help is very appreciated.
>
>
>Regards,
>
>Nada
>______________________________________________________________
>
>Nada Kapidzic Cicovic
>COST - Computer Security Technologies CST AB 
>(subsidiary of Entegrity Solutions Corporation)
>office:   + 46 (0)8 477 77 37
>mobile:   + 46 (0)495 09 03
>fax:      + 46 (0)8 477 77 31
>e-mail:   [email-masked] or [email-masked]
>address:  Finlandsgatan 60, 164 74 Kista, Sweden
>
>

Date: Tue, 01 Jul 1997 09:09:26 -0700
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: Nada Kapidzic Cicovic <[email-masked]>
CC: [email-masked]
Subject: Re: registering a new object identifier

In general, you have to find out from ISO; they may have delegated
the authority for your region or for the subtree in which you wish
to register.  Perhaps someone has the information for Sweden.

In the US, ISO has delegated the authority to ANSI for
numeric object identifier prefixes and Distinguished
Name registration.

Here is the last contact information I have for that.
Note this is a personal e-mail address rather than
a role address.

I am not sure if it is current; but it was ok as late as
last summer.  One may be able to find more recent information
at their web site http://www.ansi.org

     Tel: 212 642 4884
     Fax: 212 398 0023
     e-mail: ATTMAIL.COM!MMAAS
     X.400: C=US AD=ATTMAIL G=MICHELLE S=MAAS USER NAME=MMAAS

     Internet e-mail [email-masked]

Date: Tue, 01 Jul 97 05:59:17 
From: "Housley, Russ" <[email-masked]>
Encoding: 1206 Text
To: [email-masked], [email-masked] (David P. Kemp)
Subject: Re: PKIX Part 1 Certificate Policies extension

Dave:

I think you are correct.

Russ

______________________________ Reply Separator _________________________________
Subject: PKIX Part 1 Certificate Policies extension
Author:  [email-masked] (David P. Kemp) at internet
Date:    6/24/97 9:52 AM

Prodded by the release of the new Part 3, I've been working on examples 
for Part 1, and have a question about the syntax of the Certificate 
Policies extension.

The text of section 4.2.1.5 shows:

  PolicyQualifierId ::= ENUMERATED { id-pkix-cps, id-pkix-unotice }

where id-pkix-cps and id-pkix-unotice are OIDs.  I'm not sure this is 
legal syntax - isn't ENUMERATED required to have integer values, not OIDs? 
But the use of the pkix OIDs agrees with the text in X.509, which says:

   CERT-POLICY-QUALIFIER ::= CLASS {
        &id           OBJECT IDENTIFIER UNIQUE, 
        &Qualifier    OPTIONAL }

However, PKIX part 1 section 9 (the ASN.1 appendix) says:

  PolicyQualifierID ::= ENUMERATED {
        qualId1 (1), qualId2 (2), ... qualId5 (5) }

I believe section 9 is incorrect, and that section 4 is only half 
correct - the ENUMERATED should be replaced by a CHOICE.

Comments?

Dave Kemp

Date: Tue, 01 Jul 1997 10:21:02 +0200
To: [email-masked]
From: Nada Kapidzic Cicovic <[email-masked]>
Subject: registering a new object identifier

I was wondering what would be the best way of registering a new
organisational object identifier (in order to be able to make object
identifiers for private extensions and certification policies)? 

It seems that IANA is doing that job for SNMP business. Are there any other
efficient ways for the registration? 

Any help is very appreciated.

Regards,

Nada
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB 
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date: Tue, 1 Jul 1997 00:00:06 -0700
From: Operator <[email-masked]>
To: [email-masked], [email-masked]
Subject: Monthly reminder (IETF-PKIX list)

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "[email-masked]"
(NOT [email-masked]):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 

                Warwick Ford at [email-masked]  
                             or 
                Jean Pawluk at [email-masked].

If you have any questions about this list service in general, you
can contact [email-masked].