CA Liabilty - How does it REALLY work?

[Anders Rundgren <[e-mail]>]

Hi,
During conversations with PKI-customers I often get questions regarding CA guarantees and
insurances, sometimes involving huge sums.   The more I think about it, the harder it seems.
I.e. what can (should) you REALLY guarantee?

If a private key is stolen, some CAs are prepared to insure for that.   What does stolen mean
in the digital world and how do you prove it?  The latter requires at least logging of all kind of
uses by relying parties in order to have any proofs at all.  Unfortunately, locally performed (in
contrast to server-based) signings do not seem possible to log with respect to abuse.

If you store a certificate & key (or card & PIN-code) in a sloppy way: Who is responsible?  Isn't that
just an ordinary user error that should be covered by other insurances that the customer MAY have?
I.e. are not certificate and keys in this respect identical to physical keys?

And IF the "unbreakable" RSA-keys are broken by a criminal genius, who is responsible?

If CA personnel creates keys and certificates for illegal use of other's resources it seems that ordinary
laws should be applicable.   Provided that it is ever found out...

Naturally a CA can insure whatever they want (at some cost for the customer), but I have a
feeling that future CAs will (when/if PKI really takes off), probably be less bold in their statements,
particularly if the customer is to blame.

Just some thoughts

Anders




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA15302 for ietf-pkix-bks; Mon, 31 May 1999 04:43:38 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA15294 for <[e-mail]>; Mon, 31 May 1999 04:43:26 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id NAA17384 for <[e-mail]>; Mon, 31 May 1999 13:44:31 +0200
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA84198; Mon, 31 May 1999 13:44:26 +0200
Received: by HYDRA with Microsoft Mail id <01BEAB6B.871E8FD0@HYDRA>; Mon, 31 May 1999 13:43:12 +0200
Message-ID: <01BEAB6B.871E8FD0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'SEIS-List'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: CA Liabilty - How does it REALLY work?
Date: Mon, 31 May 1999 13:43:11 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
During conversations with PKI-customers I often get questions regarding CA guarantees and
insurances, sometimes involving huge sums.   The more I think about it, the harder it seems.
I.e. what can (should) you REALLY guarantee?

If a private key is stolen, some CAs are prepared to insure for that.   What does stolen mean
in the digital world and how do you prove it?  The latter requires at least logging of all kind of
uses by relying parties in order to have any proofs at all.  Unfortunately, locally performed (in
contrast to server-based) signings do not seem possible to log with respect to abuse.

If you store a certificate & key (or card & PIN-code) in a sloppy way: Who is responsible?  Isn't that
just an ordinary user error that should be covered by other insurances that the customer MAY have?
I.e. are not certificate and keys in this respect identical to physical keys?

And IF the "unbreakable" RSA-keys are broken by a criminal genius, who is responsible?

If CA personnel creates keys and certificates for illegal use of other's resources it seems that ordinary
laws should be applicable.   Provided that it is ever found out...

Naturally a CA can insure whatever they want (at some cost for the customer), but I have a
feeling that future CAs will (when/if PKI really takes off), probably be less bold in their statements,
particularly if the customer is to blame.

Just some thoughts

Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA11789 for ietf-pkix-bks; Mon, 31 May 1999 00:43:21 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA11785 for <[e-mail]>; Mon, 31 May 1999 00:43:20 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id JAA06003; Mon, 31 May 1999 09:44:14 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 31 May 1999 09:44:13 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id JAA13546; Mon, 31 May 1999 09:44:12 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id JAA25379; Mon, 31 May 1999 09:44:12 +0200
Date: Mon, 31 May 1999 09:44:12 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Another possibility is to say that the ESSCertid hash should use
the hash function used for signing the authenticated attributes. 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28491 for ietf-pkix-bks; Sun, 30 May 1999 08:03:20 -0700 (PDT)
Received: from mx.arx.com (mx.arx.com [212.25.66.96]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28487 for <[e-mail]>; Sun, 30 May 1999 08:03:14 -0700 (PDT)
Received: by mx.arx.com with Internet Mail Service (5.5.2232.9) id <L4D7TDBH>; Sun, 30 May 1999 17:58:14 +0300
Message-ID: <[e-mail]>
From: Ilan Shacham <[e-mail]>
To: "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: Error in encoding of DSA signature in RFC 2459?
Date: Sun, 30 May 1999 17:58:14 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The DSA signature is defined in rfc 2459 as

           Dss-Sig-Value  ::=  SEQUENCE  {
                   r       INTEGER,
                   s       INTEGER  }

where r and s are positive integers (according to the mathematics).
The signature in the first example (D.1) is encoded like this:

0650 03 2f         47: . BIT STRING  (0 unused bits)
                     : 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f
                     : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a
                     : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68

integers are encoded in DER in two's compliment, which means a 
positive value with the MSB on, should be encoded with a leading 0
octet, and so the signature sould look like this:

                    : 30 2d 02 15 00 a0 66 c1 76 33 99 13 51 8d 93 64 2f
                     : ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a
                     : bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68

This is repeated in the next examples too.
Am I missing anything here?

Ilan

------------------------------------------------------------------------
Ilan Shacham				mailto:[e-mail]
Algorithmic Research Ltd.		http://www.arx.com
10 Nevatim St.,			phone:	972 - 3 - 9279540
Petach-Tikva, Israel			Fax:	972 - 3 - 9230864



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27890 for ietf-pkix-bks; Sun, 30 May 1999 05:50:23 -0700 (PDT)
Received: from cale.checkpoint.com (ns.checkpoint.com [199.203.73.197]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27886 for <[e-mail]>; Sun, 30 May 1999 05:50:20 -0700 (PDT)
Received: from cale.checkpoint.com (gray.checkpoint.com [199.203.71.94]) by cale.checkpoint.com (8.9.1/8.9.1) with ESMTP id PAA06375; Sun, 30 May 1999 15:54:16 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Sun, 30 May 1999 15:49:53 +0300
From: Moshe Litvin <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Aram Perez <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------35C92C37951D58A71EF76910"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------35C92C37951D58A71EF76910
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

There are two uses for unique certificate ID:

A. Certificate comparison: Alice has a certificate, Bob has a good guess about
the certificate and they want to make sure that the certificate they are signing
is the same.

B. Certificate search: Alice has a certificate, Bob has a large database of
certificates and alice want to tell Bob which certificate to look for.

If we want to allow only the first then there is no reason to fix a certain
algorithm and your suggestion is appropriate.

If we want to allow the second then the database should be indexed by the unique
identifier in order to be able to search by it. This means that Alice has to know
in advance what algorithm Bob uses before it sends the message.

There are several options to solve this problem:

1. Decide that algorithm independancy is not important enough in this context.

2. Ignore the problem - Hopefully every one will use the same hash and we will
have algorithm dependency not in the standard but in common use.

3. Decide that we use only one algorithm for indexing database but allow other
for comparison. The ASN.1 will be something like:

  ESSCertID ::=  SEQUENCE {
     certHash  Hash,
     issuerSerial  IssuerSerial OPTIONAL }

  Hash ::= SEQUENCE {
     sha1Hash  HashValue,
     otherHash  HashAlgAndValue OPTIONAL  }

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier,
     hashValue HashValue }

  HashValue ::= OCTET STRING

That is the ESSCertID will always contain sha-1 for data base searches but we
want to compare with a stronger algorithm we can add other hash.

4. Allow Alice to send several hashes to Bob hoping that his database is indexed
by one of them. This option like option #2 assumes a common hash algorithm shared
by everyone but allows migration to other hash algorithm.

The ASN.1 one will be:

  ESSCertID ::=  SEQUENCE {
     certHash  Hash,
     issuerSerial  IssuerSerial OPTIONAL }

  Hash ::= CHOICE {
     sha1Hash  HashValue,
     otherHash  SEQUENCE OF HashAlgAndValue  }

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier,
     hashValue HashValue }

  HashValue ::= OCTET STRING

Regards,

Moshe

Russ Housley wrote:

> I aggree that including the hash algirith identifier would be preferable.
> For ESS, it is too late, but we can do it in a backward compatible way:
>
>   ESSCertID ::=  SEQUENCE {
>      certHash  Hash,
>      issuerSerial  IssuerSerial OPTIONAL }
>
>   Hash ::= CHOICE {
>      sha1Hash  HashValue,
>      otherHash  HashAlgAndValue }
>
>   HashAlgAndValue ::= SEQUENCE {
>      hashAlgorithm AlgorithmIdentier DEFAULT (id-sha1),
>      hashValue HashValue }
>
>   HashValue ::= OCTET STRING
>
> Russ
>
> At 10:12 AM 5/28/99 -0700, Aram Perez wrote:
> >Hi Steve,
> >
> >> Aram,
> >>
> >> We need to remain algotihm independent, and thus we cannot insist on just
> >> one hash function.  Our data structures that rely on hashes also specify
> >> which hash was employed, to prevent ambiguity.
> >
> >The ASN.1 that Denis Pinkas wrote is:
> >
> >ESSCertID ::=  SEQUENCE {
> >     certHash                 Hash,
> >     issuerSerial             IssuerSerial OPTIONAL
> >}
> >
> >Hash ::= OCTET STRING -- SHA1 hash of entire certificate
> >
> >I'm not an ASN.1 expert, but where is the hash specified (other than in the
> >comment)? Is the definition of "Hash" wrong? Should it be something like:
> >
> >Hash ::= SEQUENCE {
> >    hashAlgorithm AlgorithmIdentier,
> >    hashValue HashValue
> >}
> >
> >HashValue ::= OCTET STRING
> >
> >
> >If I can paraphrase Solomon: "There is a time to be algorithm independent
> >and there is a time to be algorithm dependent." Why complicate and decrease
> >the performance of the software that has to look up a certificate. I doubt
> >that the data store/directory/database where the certificates are kept wants
> >to have a field/attribute for any and every possible hash we allow.
> >
> >This also begs the question "Why the hash and not just the IssuerSerial?" It
> >might be my misunderstanding of X.509, but I was under the
> >impression/assumption that the Issuer and Serial Number uniquely identified
> >an X.509 certificate.
> >
> >> The use of hashes as
> >> fingerprints for self-signed certs, to facilitate out of band verification
> >> has not been a subject of standardization so far, and that is the cause of
> >> some of the problems you cite.  We can try to encourage vendors to do the
> >> right thing, but if we don't standardize it, ...
> >
> >Well I believe we should standardize it (i.e. pick 1 hash algorithm).
> >
> >Regards,
> >Aram
> >

--------------35C92C37951D58A71EF76910
Content-Type: text/x-vcard; charset=us-ascii;
 name="moshe.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Moshe Litvin
Content-Disposition: attachment;
 filename="moshe.vcf"

begin:vcard 
n:Litvin;Moshe
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
fn:Moshe Litvin
end:vcard

--------------35C92C37951D58A71EF76910--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA04605 for ietf-pkix-bks; Sat, 29 May 1999 06:59:15 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA04601 for <[e-mail]>; Sat, 29 May 1999 06:59:14 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (209-122-254-62.s62.tnt1.lnh.md.dialup.rcn.com [209.122.254.62]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA05231; Sat, 29 May 1999 06:57:22 -0700 (PDT)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 28 May 1999 17:38:58 -0400
To: "Aram Perez" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I aggree that including the hash algirith identifier would be preferable.
For ESS, it is too late, but we can do it in a backward compatible way:

  ESSCertID ::=  SEQUENCE {
     certHash  Hash,
     issuerSerial  IssuerSerial OPTIONAL }

  Hash ::= CHOICE {
     sha1Hash  HashValue,
     otherHash  HashAlgAndValue }

  HashAlgAndValue ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentier DEFAULT (id-sha1),
     hashValue HashValue }

  HashValue ::= OCTET STRING

Russ

At 10:12 AM 5/28/99 -0700, Aram Perez wrote:
>Hi Steve,
>
>> Aram,
>> 
>> We need to remain algotihm independent, and thus we cannot insist on just
>> one hash function.  Our data structures that rely on hashes also specify
>> which hash was employed, to prevent ambiguity.
>
>The ASN.1 that Denis Pinkas wrote is:
>
>ESSCertID ::=  SEQUENCE {
>     certHash                 Hash,
>     issuerSerial             IssuerSerial OPTIONAL
>}
>
>Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>
>I'm not an ASN.1 expert, but where is the hash specified (other than in the
>comment)? Is the definition of "Hash" wrong? Should it be something like:
>
>Hash ::= SEQUENCE {
>    hashAlgorithm AlgorithmIdentier,
>    hashValue HashValue
>}
>
>HashValue ::= OCTET STRING
>
>
>If I can paraphrase Solomon: "There is a time to be algorithm independent
>and there is a time to be algorithm dependent." Why complicate and decrease
>the performance of the software that has to look up a certificate. I doubt
>that the data store/directory/database where the certificates are kept wants
>to have a field/attribute for any and every possible hash we allow.
>
>This also begs the question "Why the hash and not just the IssuerSerial?" It
>might be my misunderstanding of X.509, but I was under the
>impression/assumption that the Issuer and Serial Number uniquely identified
>an X.509 certificate.
>
>> The use of hashes as
>> fingerprints for self-signed certs, to facilitate out of band verification
>> has not been a subject of standardization so far, and that is the cause of
>> some of the problems you cite.  We can try to encourage vendors to do the
>> right thing, but if we don't standardize it, ...
>
>Well I believe we should standardize it (i.e. pick 1 hash algorithm).
>
>Regards,
>Aram
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA28975 for ietf-pkix-bks; Fri, 28 May 1999 18:39:43 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA28971 for <[e-mail]>; Fri, 28 May 1999 18:39:42 -0700 (PDT)
Received: from mcg.org.br (pm09-15.sac.verio.net [209.162.65.128]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id SAA14588; Fri, 28 May 1999 18:40:20 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 28 May 1999 18:30:58 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Ed Gerck <[e-mail]>, [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <v04020a04b3709e767a28@[128.89.0.110]> <v04020a13b372163bc212@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> Ed,
>
> >Actually, if you want to bind X to an identity cert the only secure way is
> >via that cert's hash as a whole, not the public-key hash.  In fact, the cert
> >hash is not simply the only unique reference that you can rely on for that
> >identity cert, but also one which (by extension from the cert) already
> >includes a revocation mechanism (CRL or OCSP) and possibly also
> >insurance or derived warranties (via CA CPS).
>
> Interesting point.  If one wants to ensure that the whole context of the
> identity cert is bound to the AC then you are right.  That is the most
> conservative, and probably the most secure appraoch.

That is why I suggested that  PKIX should follow this approach -- also
because the corresponding CRLs, OCSP, CPS, warranties and
insurance are included by unambiguous reference. A lot more can thus be
easily gained if so desired by the verifier, not just improved validation
assurances.

> There might be
> occasions where I don't want so tight a binding, and where just the key
> would be OK, which does have a more SPKI-like flavor.

I just commented on the SPKI list that this is a security fault also in
SPKI, where the issuer is the same entity as the verifier.  Here, however,
this thread deals with X.509-SPKI -- not SPKI-SPKI for issuer-verifier.

As I also just commented there, the SPKI-SPKI case can be even
simpler. In fact, who needs even the key hash in that SPKI attribute cert?
Simply by signing the SPKI attribute cert with the corresponding private-key,
the issuer would force himself at a later date (when he becomes the verifier)
to use the corresponding public-key in order to verify the attribute cert's
signature. No need for a key hash entry for that same public-key in the
attribute cert -- the binding of the attribute with that public-key is implict
but strong, in the cert signature itself.

Things do tend to get simpler thus, when one is talking to himself.

Can this be useful? Perhaps, as a type of crypto memory  for myself --
but not for this X.509 ACs vs. SPKI thread.

Thus, if communication or e-commerce enter the picture and the
verifier is no longer the issuer, then one can no longer assume that to
each public-key there is a unique certificate (as SPKI does).

Is there a solution? I believe so as I wrote before, both for SPKI-SPKI
as well as for SPKI-X.509  -- by simply using the whole cert hash instead
of the key hash. Then, the key is referred together with its validation and
revocation context.

> >I note that the cert hash has been suggested as an intrinsic DN two years
> >ago [Ger97a], which can be entirely locally defined and with a local
> >decision tree that allows its local reconstruction at any time -- yet globally
> >unambiguous.
>
> Cert hashes are not, IMNSHO, a good ID form. For example, they don't admit
> to easy searching over a distributed set of databases, unlike
> tree-structured names, e.g., DNs or DNS names, or IP addresses. It's not
> enough to make an ID globally unique.

There is a simple confusion above, IMVHO. It is misleading to say that
cert hashes are not "a good ID form" -- and then try to support this
affirmation by noting their undesirable *pointer form* while, at the
same time, affirming at the end that indeed they have a good ID form
because they are "globally unique".

An apple is a bad speedboat, allright.

Thus, the issue here is quite different. Is a cert hash a good ID form in  the
sense that it allows *all* relevant variables (public-key, date of issuance,
issuer, etc.) that define the issuance and validity of a public-key to be
unambiguously and compactly referenced in it -- as their joint  ID? Yes,
must be the answer here. Contrary to the previously preferred key hash,
for which the answer must be a flat No.

Now, regarding their performance as hierarchical *pointers* -- obviously,
*both* hashes are equally bad. So, I would say IMVHO that using cert hashes
instead of key hashes certainly did NOT make the matter *worse* in this
regard. Which matter was however already acceptable, so there is no reason
to refute it now, based on these grounds.

But, this can also be solved -- by using cert hash fingerprints, directly derived
from the cert hashes, as a conveniently small but probably unique pointer. In
the same way that we use key fingerprints for CAs, no?


> >Of course, if you want to bind X to a public-key then you are justified to
> >do what you mentioned. But,  the CRL-authority for that public-key
> >cannot be securely defined neither by the keyholder nor by delegation
> >to the identity cert issuer -- which is a serious security fault. Besides, you
> >would lack insurance and other warranties which can be directly derived
> >by extension from the cert -- since no cert is named.
>
> A common model for use of ACs is that they are issued by an authority for
> later presentation to an access controller for resources controlled within
> the same domain as the issuing authority.  Under than model, it is unlikely
> that the trace back to a specific cert (in case multiple certs hold the
> same public key) is really a problem.  Also, since the authority that
> issued the AC would have had access to the identity cert as part of the
> issuance process, it can always keep a copy in an audit trail for later
> matching to the specific cert against which the AC was issued, if a dispute
> arises.

This reasoning only applies to networks, not to internets. Take away that
common authoritative point and the problem surfaces. But, even to networks,
it applies only very poorly. For example, if the same authority issues two
different certs for the  same key (the newer cert with less warranty, for
example), then neither can you define which identity cert supports the
attribute cert nor, in the case of a revocation of the older identity cert
with more warranties, whether that attribute cert is even valid at all.
Conversely, even when restricted to a network, you can be easily
spoofed into accepting an invalid attribute cert since you do not know
which identity cert supports it -- the one with more or less warranties.

That is why I considered such usage a serious security fault. But,
there are other examples of this logic.

> >> Look at the draft profile for attribute certs recently published by Stephen
> >> Farrell and it's easy to locate the key hash as pointer.  The real
> >> difference here is that X.509 believes that certs with public keys should
> >> contain a name that is not purely a local matter.
> >
> >This is not correct, though a common misconception and unfortunately often
> >so cited in some SPKI  documents. Let me divide the issue in three parts:
> >
> >1. Section 3.3.3 of X.509v3 defines a certificate as: "user certificate;
> >public key certificate; certificate:  The public keys of a user, together
> >with some other information, rendered unforgeable by encipherment
> >with the private key of the certification authority which issued it.". But,
> >what is "some other information"?
> >
> >2. Section 11.2 of X.509v3, "Management of certificates", states that
> >the certificate allows an association between a name called "unique
> >distinguished name" or DN for the user and the user's public-key:
> >"A  certificate  associates  the public key and unique distinguished
> >name of the user it describes.", while Section 7 explains that such
> >DNs are essential to the security design of X.509: "Authentication
> >relies on each user possessing a unique distinguished name." But,
> >how are such DNs assigned? Where are they unique? Locally,
> >globally?
> >
> >3. The DN is denoted by a NA (Naming Authority) and accepted by a
> >CA (Certification Authority) as unique within the CA's domain, where
> >the CA can double as a NA. It is interesting to note that the same user
> >can have different DNs in different CAs, or can use the same DN in
> >different CAs even if it is not the first one to use it in a CA -- so
> >different
> >DNs for different CAs do not necessarily mean different users and vice-
> >versa.  Further, a DN does not have to contain the user's real-world
> >name or location. Thus, semantically, the CA certificate refers to a name;
> >however it does not denote it.
> >
> >Thus,  these three points deny the affirmation that a X.509 name is "not
> >purely a local matter" -- yes it is since the CA is local, but it could
> >nonetheless *also* have a global significance (for example, if that name
> >correctly dials a fully-qualified phone number).
> >
> >However, there is one more point in X.509 which can be interesting here,
> >regarding the validation of such DNs -- which is also *local* to the CA,
> >not global at all and also not necessarily auditable:
>
> Nice analysis, but it ignores the context in which X.509 exists, i.e., the
> X.500 directory model.

No, it does not, please read again  -- *even* if X.500 would exist, a DN
in an X.509 certificate would still be a locally defined name. As I originally
commented below and I requote:

 In legal reliance terms, one may trust the DN confirmation procedures
 of the CAduring certificate reliance, but one cannot rely upon them for
 other than their value as a representation of the CA's authentication
 management act expressed in the CA's own terms and rules (CPS) --
 therefore, a DN in a X.509 certificate is *by X.509 definition* a purely
 local matter (local to the CA and its CPS) even if X.500 global
 directories were used (X.509v3, Section 11.2).


> People do issue X.509 certs with subject and issuer
> names that may not be globally unique, but that was not the context in
> which cert issuance was envisioned.

This was not the point. Even if the name were globally unique the validation
was envisioned by X.509 to be local to the CA and that is why each CA
can define its own CPS.  To repeat, from X.509, Section 11.2:

 "a certification authority shall be satisfied of the identity of a user before
 creating a certificate for it",

which affirms that any CA is authoritative over any X.500 directory, in the
CA's own terms and rules (CPS), contrary to what you suggest would
have been envisioned.  The whole text of X.509 is clear on this distinction
and that is why I cited more than one passage. Yet, this is often a source
of confusion -- perhaps because X.500 was an identification dream while
X.509 was living it ;-) But, X.509 had it right, IMO -- names are indeed
locally defined even if they have a very global significance or uniqueness.

There is thus an inherent conflict between the "global" affirmations of the
X.500 names mandated in X.509 and the laissez-faire doctrine behind
the X.509 definition of the CPS terms -- which is strictly local to *each*
CA. So, the very rules which define *what is valid* are local in X.509.

That is why names cannot take a global significance even if X.500 would
be "a dream come true", unless the CA would so define. But, the CAs
are ever so careful to affirm the opposite in their CPS. And, rightly so
[as I comment in http://www.mcg.org.br/cert.htm].  Also, given the fact
that 50% of the world's lawyers are in the US and the growing US
tendency for "jackpot justice" one wonders what else could be
expected from CAs -- and the Utah experience was an eye-openner
in this regard. Technical reliance cannot come from legal reliance --
but, exactly the opposite (BTW, this also applies to non-repudiation).


> I don't worry too much about folks
> issuing certs with names that are unique local to a CA context, as you
> observe, so long as they understand the possible adverse implications of
> such.  Given the lack of a global X.500 directory, I usually advise folks
> to stick with name spaces that do have global uniqueness and some extant
> authority for managing the name space, e.g., the DNS, or to construct a
> purely local system.

Your suggestion is IMO good. But, at the end, the name is locally defined
and is thus local. This also includes a broader issue -- that DNS and DN
names are intersubjective, not objective. Their meaning depends on both
ends. For example, if I give you the URL www.gifts.com -- what do you
think they sell? Surely, it is a simple name.

In general, it is useful to distinguish between names as syntatic expressions
(references, byte strings) in contrast to semantic expressions (sense, what
they mean or denote). And, this leads to the realization that reference and
sense are independent variables -- there can be no global meaning even
if the name is syntatically global.

> >4. X.509 is moot on validation procedures for data included in a certificate
> >such as the user's name, with the exception of validation procedures for the
> >user's public-key which are suggested (not mandated) in Section 10 of
> >X.509v3. For example, regarding validation procedures for the user's
> >identity, Section 11.2.a states that: "a certification authority shall be
> >satisfied of the identity of a user before creating a certificate for it",
> >which
> >means that identity validation procedures are to be satisfied in the CA's
> >frame of reference by following the CA's own self-defined rules (called CPS),
> >which are declared outside the scope of X.509 and can be entirely different
> >for different CAs. Further, all public CA's CPSs accept indirect references
> >of "trust" when issuing certificates, which is a security risk that could
> >only be
> >acessed by  auditing, to verify the procedures used to accept an ID for
> >example
> >-- but, auditing is not possible with today's CPS and X.509 is also moot
> >on such
> >requirement.
> >
> >Thus, X.509 focuses on defining a mechanism by which information can be made
> >available in a secure way to a third-party. However, X.509 does not intend to
> >address the level of effort which is needed to validate the information in
> >a certificate
> >neither define a *global* meaning to that information outside the CA's
> >management
> >acts.
>
> Of course X.509 does not establish the criteria that a CA will employ for
> authenticating the right of an EE to use the subject name.  That is a local
> policy matter, even for globaly names.

Yes. This is one of the points, as I call attention to, that deny reading X.509
as mandating "global names" -- it does not, even though it supposes (wrongly,
see the sense vs. reference discussion above) that they exist somewhere
(X.500).

> >In legal reliance terms, one may trust the DN confirmation procedures of
> >the CA
> >during certificate reliance, but one cannot rely upon them for other than
> >their value
> >as a representation of the CA's authentication management act expressed in the
> >CA's own terms and rules (CPS) -- therefore, a DN in a X.509 certificate
> >is *by
> >X.509 definition* a purely local matter (local to the CA and its CPS) even if
> >X.500 global directories were used (X.509v3, Section 11.2). Of course, if
> >the US
> >INS accepts (rather, "uses") UK birth certificates in order to issue residence
> >permits to the US, this does not mean that the INS is declaring that such
> >birth
> >certificates are valid in the UK. So, the eventual use by a CA of a DN
> >supplied
> >by a X.500 directory does not mean that the CA is declaring that such DN is
> >global.
>
> To expand on your example, when the US issues a passport, it states that
> the named individual is a citizen of the US and that the name represented
> in the passport is a legal name for the passport holder (the later binding
> established via the photo).  If one were to issue an electronic passport,
> the DN for the passport holder probably would include the passport number
> as a component of the terminal RDN. to ensure uniqueness in the space for
> which the US Dept of State is authoritative.

Yes, as well as date of issuance, validity, authority name, etc -- voila, a certificate ;-)

> >Here, in PKIX, the main purpose of a CA is also to bind a public key to
> >the name
> >contained in the certificate and thus assure third parties that some
> >measure of care
> >was taken to ensure that this binding is valid for both -- i.e., name and
> >key. However,
> >the issue whether a user's DN actually corresponds to identity credentials
> >that are
> >*globally* linked to a person, or to a local alias or, simply to an e-mail
> >address -- and
> >how such association was verified --   is also outside the scope of PKIX
> >and depends
> >on each CA's CPS.
>
> Yes, the means fo verification is a CPS issue, but also don't get too hung
> up on DNs, per se.  PKIX encourages use of altName forms suitable to the
> Internet environment, where global uniqueness is a reasonable presumption.

Agreed. It seems that we are in substantial agreement especially as the reading
of this e-mail progressed to here, though less of a violent agreement in the
beginning ;-)

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27374 for ietf-pkix-bks; Fri, 28 May 1999 15:53:05 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27364 for <[e-mail]>; Fri, 28 May 1999 15:52:59 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA04656 for <[e-mail]>; Fri, 28 May 1999 18:53:48 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb374ce9d8309@[128.89.0.110]>
Date: Fri, 28 May 1999 18:52:37 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: our meeting slots in Oslo
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

PKIX is tentatively scheduled as follows:

	Wednesday, July 14 at 0900-1130
		other groups scheduled at that time: disman, manet, avt, ipngwg
	Wednesday, July 14 at 1300-1500
		other groups scheduled at that time: ipfc, trade, manet,
sigtran, mboned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27372 for ietf-pkix-bks; Fri, 28 May 1999 15:53:01 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27365 for <[e-mail]>; Fri, 28 May 1999 15:52:59 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA04653; Fri, 28 May 1999 18:53:47 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a09b374b163a4ae@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a06b3749afb60ae@[128.89.0.110]> <[e-mail]>
Date: Fri, 28 May 1999 18:50:08 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony,

>I have always been a bit puzzled by the position that indexing by hash value
>is a "problem".  Technically, it seems simple to structure/index an efficient
>tree (order log n) search by hash value.  Previous discussions reveal perhaps
>that the culprit is distributed DB/Directory management:  Its easy to say
>that a given party controls the "OU=xxx" branch of the space, whereas division
>of the tree by arbitrary numeric values does not lend itself to this kind of
>delegated management.
>
>However, the DN-based tree structure seems (unfortunately) to lend itself all
>to easily to "trolling".  (Let's see what lies in the C=X, OU=Y,... area.)

The problem with searching based on an arbitrary number, like a hash, is
the flip side of the featrure you cite for such schemes.  We find that most
naming schemes are tree structured, in part because that allows delegation
of parts of the name space, and that facilitates management and searching.
The downside is that it also facilitates trolling, but we assume the use of
local access controls to make sure that searching a (local) directory is
authorized.

A hash creates a nominally flat name space, which can be aggregated into
clumps, to allow distributed searching.  but who manages the clumps?
because the clumps don't aling with organizational boundaries, there are no
natural organizations to assume responsibility for the repositories, and
access control to entries now requires reliance on third parties.

So, that's the basis for my comments re the appropriateness of hashes as
keys for searching in a large scale, distributed system that crosses
administrative boundaries.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26139 for ietf-pkix-bks; Fri, 28 May 1999 13:21:49 -0700 (PDT)
Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26135 for <[e-mail]>; Fri, 28 May 1999 13:21:48 -0700 (PDT)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <L5T81CQ0>; Fri, 28 May 1999 16:22:51 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Aram Perez'" <[e-mail]>
Cc: [e-mail]
Subject: RE: X.509 ACs vs. SPKI?
Date: Fri, 28 May 1999 16:25:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Aram,

	Before this threat reaches total and complete entropy (and this
message should certainly do it!), the phenomenon of "uniqueness" applies
only to the PKI that issued the cert.  If you have a cert from each of the
30-40 or so self-signing CAs that come with your "out-of-the-box" browser,
chances are that there will be some duplications (say, in CN and/or cert
serial number) between but NEVER within PKIs--if there are any within a PKI,
I'd find myself another cert source pronto.  However, the combination of CN,
end-user public key, cert serial number, phase of the moon, and how many
times you've seen Episode I in the past 10 days all but guarantees the
uniqueness of ANY cert ever issued by ANY entity at least in this galaxy.

Best regards,
Bill Flanigan
 
> ----------
> From: 	Aram Perez[SMTP:[e-mail]]
> Sent: 	Friday, May 28, 1999 2:31 PM
> To: 	[e-mail]; [e-mail]
> Subject: 	Re: X.509 ACs vs. SPKI?
> 
[snip]

> > Finally, an Issuer name and serial number SHOULD uniquely identify a
> cert,
> > but in reality there is insufficient control over Issuer names to
> guarantee
> > uniqueness.  
> 
[snip]

> Regards,
> Aram
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26125 for ietf-pkix-bks; Fri, 28 May 1999 13:20:09 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26121 for <[e-mail]>; Fri, 28 May 1999 13:20:08 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id NAA19253; Fri, 28 May 1999 13:20:44 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 28 May 1999 13:20:24 -0700
To: Stephen Kent <[e-mail]>, "Aram Perez" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
In-Reply-To: <v04020a06b3749afb60ae@[128.89.0.110]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 03:24 PM 5/28/99 -0400, Stephen Kent wrote:
>
>No, the seacrching problem I refer to is due to the use of ANY hash as an ID.
>
>Steve

Slight digress from single/multiple hash algorithm support (I tend to agree
with Steve - a fixed algorithm seems destined for trouble...)

I have always been a bit puzzled by the position that indexing by hash value
is a "problem".  Technically, it seems simple to structure/index an efficient
tree (order log n) search by hash value.  Previous discussions reveal perhaps
that the culprit is distributed DB/Directory management:  Its easy to say
that a given party controls the "OU=xxx" branch of the space, whereas division
of the tree by arbitrary numeric values does not lend itself to this kind of
delegated management.

However, the DN-based tree structure seems (unfortunately) to lend itself all
to easily to "trolling".  (Let's see what lies in the C=X, OU=Y,... area.)

Comments?

___tony___
 

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25717 for ietf-pkix-bks; Fri, 28 May 1999 12:31:57 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25713 for <[e-mail]>; Fri, 28 May 1999 12:31:55 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA16217; Fri, 28 May 1999 15:32:45 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a06b3749afb60ae@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Fri, 28 May 1999 15:24:58 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aram,

>>
>> I see the structure that raised your concern, and we'll clearly have to do
>> something in our context to ensure that the ambiguity does not persist.  (I
>> assume that this was not an issue in the context where the structure was
>> used initially, due to the hash alg being identified elsewhere.)
>>
>> We relly love algorithm independence here in the IETF, so I will not try to
>> spend time on the list justifying it.
>
>If I'm not mistaken, the definition for ESSCertID came from *IETF's S/MIME*
>effort, so is appears that someone else at IETF does not "love algorithm
>independence".

Have you looked at the larger context in S/MIME where it is used?  if not,
then this statement seems premature.

>>  Clearly it has been important in the
>> encryption algorithm arena, where independence is making it possible to
>> transition from DES to 3DES or AES, or whatever.  Similar arguments apply
>> to hash algorithms as well.
>
>Believe me, I'm a strong believer is algorithm independence but only where
>it makes sense. And in the case of using the hash to identify a certificate
>I don't believe it makes sense. I agree with the current definition of
>ESSCertID. My objection was to Denis Pinkas comment about allowing more hash
>algorithms to be used as the identifier of a certificate.

I would find it most convenient to use the same hash here as the one used
in signing the cert, since that hash alg is, by definition, one that both
the CA and any relying party must implement.  But, since we don't mandate
any single algorithm for that purpose, why do so for this hash?

>>
>> Finally, an Issuer name and serial number SHOULD uniquely identify a cert,
>> but in reality there is insufficient control over Issuer names to guarantee
>> uniqueness.  Use of the hash as a backpointer is more secure, though by
>> itself a hash is not a great way to ID a cert, due to searching
>> limitations, as discussed previously.
>
>You seem to agree that there will be "searching limitations" by having
>algorithm independence. So why should PKIX impose these "searching
>limitations" if there is no security risk/extra cost/Y10K/etc issue with
>having one hash algorithm used to help identify a certificate?

No, the seacrching problem I refer to is due to the use of ANY hash as an ID.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25038 for ietf-pkix-bks; Fri, 28 May 1999 11:31:08 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25034 for <[e-mail]>; Fri, 28 May 1999 11:31:07 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id LAA63080 for <[e-mail]>; Fri, 28 May 1999 11:32:01 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 11:31:58 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id LAA15698; Fri, 28 May 1999 11:31:57 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 28 May 1999 11:31:57 -0700
Subject: Re: X.509 ACs vs. SPKI?
From: "Aram Perez" <[e-mail]>
To: [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Steve,

> Aram,
> 
> I see the structure that raised your concern, and we'll clearly have to do
> something in our context to ensure that the ambiguity does not persist.  (I
> assume that this was not an issue in the context where the structure was
> used initially, due to the hash alg being identified elsewhere.)
>
> We relly love algorithm independence here in the IETF, so I will not try to
> spend time on the list justifying it.

If I'm not mistaken, the definition for ESSCertID came from *IETF's S/MIME*
effort, so is appears that someone else at IETF does not "love algorithm
independence".

>  Clearly it has been important in the
> encryption algorithm arena, where independence is making it possible to
> transition from DES to 3DES or AES, or whatever.  Similar arguments apply
> to hash algorithms as well.

Believe me, I'm a strong believer is algorithm independence but only where
it makes sense. And in the case of using the hash to identify a certificate
I don't believe it makes sense. I agree with the current definition of
ESSCertID. My objection was to Denis Pinkas comment about allowing more hash
algorithms to be used as the identifier of a certificate.

>
> Finally, an Issuer name and serial number SHOULD uniquely identify a cert,
> but in reality there is insufficient control over Issuer names to guarantee
> uniqueness.  Use of the hash as a backpointer is more secure, though by
> itself a hash is not a great way to ID a cert, due to searching
> limitations, as discussed previously.

You seem to agree that there will be "searching limitations" by having
algorithm independence. So why should PKIX impose these "searching
limitations" if there is no security risk/extra cost/Y10K/etc issue with
having one hash algorithm used to help identify a certificate?

Regards,
Aram


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24830 for ietf-pkix-bks; Fri, 28 May 1999 11:02:28 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24826 for <[e-mail]>; Fri, 28 May 1999 11:02:25 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA01553; Fri, 28 May 1999 14:02:59 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a01b37489182cd0@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Fri, 28 May 1999 14:00:26 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aram,

I see the structure that raised your concern, and we'll clearly have to do
something in our context to ensure that the ambiguity does not persist.  (I
assume that this was not an issue in the context where the structure was
used initially, due to the hash alg being identified elsewhere.)

We relly love algorithm independence here in the IETF, so I will not try to
spend time on the list justifying it.  Clearly it has been important in the
encryption algorithm arena, where independence is making it possible to
transition from DES to 3DES or AES, or whatever.  Similar arguments apply
to hash algorithms as well.

Finally, an Issuer name and serial number SHOULD uniquely identify a cert,
but in reality there is insufficient control over Issuer names to guarantee
uniqueness.  Use of the hash as a backpointer is more secure, though by
itself a hash is not a great way to ID a cert, due to searching
limitations, as discussed previously.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24757 for ietf-pkix-bks; Fri, 28 May 1999 10:57:51 -0700 (PDT)
Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24746 for <[e-mail]>; Fri, 28 May 1999 10:57:46 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp8.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id NAA13572; Fri, 28 May 1999 13:56:20 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id NAA104218; Fri, 28 May 1999 13:57:33 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525677F.00629E6D ; Fri, 28 May 1999 13:57:10 -0400
X-Lotus-FromDomain: IBMUS
To: "Aram Perez" <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 28 May 1999 13:56:55 -0400
Subject: Re: X.509 ACs vs. SPKI?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     The easiest ASN.1 to use for Denis' construct is probably:
ESSCertID ::=  SEQUENCE {
     certHash       DigestInfo,          -- see PKCS-1
     issuerSerial        IssuerSerial OPTIONAL
}

     The syntax of DigestInfo is, in RFC 2437 (PKCS-1 version 2):
DigestInfo     ::=  SEQUENCE {
     digestAlgorithm     AlgorithmIdentifier,
     digest         OCTET STRING }
     which is basically the same as your suggestion.

          Tom Gindin


"Aram Perez" <[e-mail]> on 05/28/99 01:12:30 PM

To:   [e-mail], [e-mail]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  Re: X.509 ACs vs. SPKI?





Hi Steve,

> Aram,
>
> We need to remain algotihm independent, and thus we cannot insist on just
> one hash function.  Our data structures that rely on hashes also specify
> which hash was employed, to prevent ambiguity.

The ASN.1 that Denis Pinkas wrote is:

ESSCertID ::=  SEQUENCE {
     certHash                 Hash,
     issuerSerial             IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

I'm not an ASN.1 expert, but where is the hash specified (other than in the
comment)? Is the definition of "Hash" wrong? Should it be something like:

Hash ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentier,
    hashValue HashValue
}

HashValue ::= OCTET STRING


If I can paraphrase Solomon: "There is a time to be algorithm independent
and there is a time to be algorithm dependent." Why complicate and decrease
the performance of the software that has to look up a certificate. I doubt
that the data store/directory/database where the certificates are kept wants
to have a field/attribute for any and every possible hash we allow.

This also begs the question "Why the hash and not just the IssuerSerial?" It
might be my misunderstanding of X.509, but I was under the
impression/assumption that the Issuer and Serial Number uniquely identified
an X.509 certificate.

> The use of hashes as
> fingerprints for self-signed certs, to facilitate out of band verification
> has not been a subject of standardization so far, and that is the cause of
> some of the problems you cite.  We can try to encourage vendors to do the
> right thing, but if we don't standardize it, ...

Well I believe we should standardize it (i.e. pick 1 hash algorithm).

Regards,
Aram






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24396 for ietf-pkix-bks; Fri, 28 May 1999 10:27:57 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24392 for <[e-mail]>; Fri, 28 May 1999 10:27:56 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Fri, 28 May 1999 18:28:07 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 18:27:16 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id SAA03445; Fri, 28 May 1999 18:27:53 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id SAA03609; Fri, 28 May 1999 18:27:51 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Stephen Kent <[e-mail]>
Cc: "Dale Gustafson" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI? 
In-Reply-To: Your message of "Fri, 28 May 1999 10:46:08 EDT." <v04020a04b3745a512e71@[128.89.0.110]> 
MIME-Version: 1.0
Date: Fri, 28 May 1999 18:27:51 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Only minor quibble I'd have is...

> >2) Is there an assumption that an AC "must always" contain a reference to an
> >x.509 ID-cert ?
> 
> My view of the model says yes.  ACs don't exist independent of public key
> certs.

Its also possible, though most likely out of PKIX's scope, for an 
AC to be linked to e.g. Kerberos authentication or some other
symmetric based mechanism.

Regards,
Stephen (the one just finishing his shift:-)






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24176 for ietf-pkix-bks; Fri, 28 May 1999 10:11:51 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24172 for <[e-mail]>; Fri, 28 May 1999 10:11:50 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA21256 for <[e-mail]>; Fri, 28 May 1999 10:12:43 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 10:12:31 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA20310; Fri, 28 May 1999 10:12:30 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 28 May 1999 10:12:30 -0700
Subject: Re: X.509 ACs vs. SPKI?
From: "Aram Perez" <[e-mail]>
To: [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Steve,

> Aram,
> 
> We need to remain algotihm independent, and thus we cannot insist on just
> one hash function.  Our data structures that rely on hashes also specify
> which hash was employed, to prevent ambiguity.

The ASN.1 that Denis Pinkas wrote is:

ESSCertID ::=  SEQUENCE {
     certHash                 Hash,
     issuerSerial             IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

I'm not an ASN.1 expert, but where is the hash specified (other than in the
comment)? Is the definition of "Hash" wrong? Should it be something like:

Hash ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentier,
    hashValue HashValue
}

HashValue ::= OCTET STRING


If I can paraphrase Solomon: "There is a time to be algorithm independent
and there is a time to be algorithm dependent." Why complicate and decrease
the performance of the software that has to look up a certificate. I doubt
that the data store/directory/database where the certificates are kept wants
to have a field/attribute for any and every possible hash we allow.

This also begs the question "Why the hash and not just the IssuerSerial?" It
might be my misunderstanding of X.509, but I was under the
impression/assumption that the Issuer and Serial Number uniquely identified
an X.509 certificate.

> The use of hashes as
> fingerprints for self-signed certs, to facilitate out of band verification
> has not been a subject of standardization so far, and that is the cause of
> some of the problems you cite.  We can try to encourage vendors to do the
> right thing, but if we don't standardize it, ...

Well I believe we should standardize it (i.e. pick 1 hash algorithm).

Regards,
Aram



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23849 for ietf-pkix-bks; Fri, 28 May 1999 09:42:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23844 for <[e-mail]>; Fri, 28 May 1999 09:42:22 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA18916; Fri, 28 May 1999 12:43:11 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a00b3747759013c@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Fri, 28 May 1999 12:41:58 -0400
To: "Aram Perez" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aram,

We need to remain algotihm independent, and thus we cannot insist on just
one hash function.  Our data structures that rely on hashes also specify
which hash was employed, to prevent ambiguity.  The use of hashes as
fingerprints for self-signed certs, to facilitate out of band verification
has not been a subject of standardization so far, and that is the cause of
some of the problems you cite.  We can try to encourage vendors to do the
right thing, but if we don't standardize it, ...

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA23592 for ietf-pkix-bks; Fri, 28 May 1999 09:11:33 -0700 (PDT)
Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23588 for <[e-mail]>; Fri, 28 May 1999 09:11:32 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id JAA26158 for <[e-mail]>; Fri, 28 May 1999 09:12:24 -0700
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 09:12:14 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id JAA32446; Fri, 28 May 1999 09:12:13 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Fri, 28 May 1999 09:12:13 -0700
Subject: Re: X.509 ACs vs. SPKI?
From: "Aram Perez" <[e-mail]>
To: [e-mail], [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:

> Steve,
> 
> I agree with your response
> 
> In ESS (from the S/MIME WG) there is the following structure which
unambigously
> references an certificate.
>
> ESSCertID ::=  SEQUENCE {
>      certHash                 Hash,
>      issuerSerial             IssuerSerial OPTIONAL
> }
>
> Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>
> IssuerSerial ::= SEQUENCE {
>      issuer                   GeneralNames,
>      serialNumber             CertificateSerialNumber
>
> I suggest that we generalize it, to support any kind of HASH function,
> i.e. not limiting it to SHA 1.

I disagree with allowing any HASH function. If you don't specify just one
function, then you have to search the data store for every HASH function
allowed until I find the certificate.

Look at the current problem trying to verify root certificates and/or
"built-in certificates". Some browsers display the MD5 certHash (a.k.a. the
fingerprint), and others display the SHA-1 certHash. Some CAs publish their
root certificate certHashes using MD5, others using SHA-1. So the ability to
verify the root certificates of your browser depends on which browser you
have and which CA's root certificates you are trying to verify :-(  Not good
at all in my opinion.

[snip]

Regards,
Aram Perez


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA22683 for ietf-pkix-bks; Fri, 28 May 1999 08:03:45 -0700 (PDT)
Received: from penguin.prod.itd.earthlink.net (penguin.prod.itd.earthlink.net [207.217.120.134]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA22679 for <[e-mail]>; Fri, 28 May 1999 08:03:44 -0700 (PDT)
Received: from brick (sdn-ar-015casfraP013.dialsprint.net [158.252.219.15]) by penguin.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA16646; Fri, 28 May 1999 08:04:20 -0700 (PDT)
Message-ID: <051201bea91b$4ca33c90$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><[e-mail]> <v04020a0fb37336bc9254@[128.89.0.110]> <03d501bea898$dd96b750$930aff0c@brick> <[e-mail]>
Subject: Re: Comments on time-stamp-01: Identification of TSA
Date: Fri, 28 May 1999 08:03:49 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis, this is degrading at this point and so I apologize to the group. I am
taking the remainder of my commentary to you and the other Draft Creators
offline, so I don't have to burden the list with the rest of my thoughts on
this matter.

Todd

----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Todd S. Glassey - ELN <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, May 28, 1999 2:43 AM
Subject: Re: Comments on time-stamp-01: Identification of TSA


> Todd,
>
> Altough this E-mail is primarily for Steve, I would like to make a few
comments
> on it:
>
> 1° I think that the tone that is being used in your reply here is not
adequate
> and should be moderated.
>
> 2° We are defining a Time Stamping Protocol that can be used in many
dfferent
> contexts. We do not claim that it is usable in all the contexts. We have
made a
> few *simple* extensions that were beyond the original goal, in particular
to be
> able to answer to the simple question "What time is it ?" when the
requester has
> no local time available. The primary need is only to prove that a digital
> signature was created before a given date. That digital signature may be
any
> signature; e.g. from a user; from a CA for a user certificate,
> cross-certificate, CRL, ARL; from an Attribute Authority for an Attribute
> Certificate ... As there are too many examples of use, only a few are
mentioned
> in the annex.
>
> 3° The protocol is sufficient for our current needs. Thus I do not see the
need
> to extend the terms of reference of our charter to cover more.
>
> Regards,
>
> Denis
> (co-author of the current draft)
>
>
> > Stephen
> > I respect and appreciate your accomplishments but I think you dead wrong
> > here and everything I have had to live through for the last two years
tells
> > me I am right.  My issue in saying this publicly is that "Stephen Kent"
is a
> > name that carries a lot of weight when it is attached to an opinion,
which
> > is why I am so baffled as to your resistance to building in these
proofing
> > facilities into the timestamping process.
> >
> > It seems to me that what we are focusing on here is an elaborate
mechanism
> > to pass relative time through a distributed infrastructure, rather than
the
> > real goal - that being to have a system for representing events in time
that
> > is accurate, believable, and commercially viable.  Mark the phrase
> > "Commercially Viable", because it is the key to any market success we
will
> > have unless someone puts a law in place to mandate our products.
> >
> > Personally, I am starting to want to call this timestamping protocol the
> > Bradley Fighting Vehicle of the PKIX group - ever see Kelsey Grammer in
> > "Pentagon Wars" - and although I know that is not true, it's sorta how I
> > feel about all the abuse I have taken for questioning the use and
> > architecture of this effort's end goals.  The ultimate reason for my
> > responses here is driven in the simple economic fact that if I have to
shell
> > out money for this technology, it better pay me back somehow.
> >
> > As to your commentary particular that "it's not there" below, that is to
> > say, the ability in the protocol to prove the chain of custody against
the
> > time source - I know it's not there and I am trying to figure out why.
> >
> > What I think we have built here today is a system that requires the user
or
> > operator to jump through external hoops to prove the process and model
of
> > operations at the sites are OK, otherwise the timestamps issued are of
> > questionable veracity and as such there use and reception are likely to
be
> > limited.
> >
> > As to the existing draft's specification, my problem is that I have
still
> > not figured out a legally binding model for a large enough segment of
the co
> > mmercial world to use this timestamping technology, that this makes
> > commercial sense.
> >
> > DONT GET ME WRONG - I AM NOT TRYING TO TELL YOU THAT THE ZUCCERATTO, et
al.
> > DRAFT IS BROKEN, just that I want to understand the use models driving
all
> > this effort in detail.
> >
> > ----- Original Message -----
> > From: Stephen Kent <[e-mail]>
> > To: Todd S. Glassey - ELN <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Thursday, May 27, 1999 10:55 AM
> > Subject: Re: Comments on time-stamp-01: Identification of TSA
> >
> > > Todd,
> > >
> > > There is no requirement that the time stamp carry info that purports
to
> > > trace the origin of the time source.  That info may be expressed in
the
> > > TSA's policy, as a static assertion, unless the WG determines that
such a
> > > static assertion is not sufficiently flexible.
> >
> > I question this
> >
> > > For example, a TSA might
> > > say that they use GPS,
> >
> > Stephen, personally I don't think that this will ever happen in a
> > commercially functional sense.
> >
> > #1  no one would who needs a really viable audit done would use and rely
on
> > the timedata from GPS alone, since the US Air Force controls it. Also
there
> > is the real world a pretty major problem in that the GPS sattillites
that
> > are currently available are going to start decommissioning themselves
> > because their Atomic Clocks are out of cal [becuase of their age] and
as
> > such, they cannot be adjusted or refurbished in their current orbits.
> >
> > >From my last understanding, the US Congress has reallocated the
replacement
> > GPS Sattellite launch slots on the STS  (the Shuttle) to other
"projects"
> > including the international space station, so at last count GPS is sort
of
> > dying... or its at least being ignored. Also, I further understand that
> > there is a funny issue ofthe  Air Force trying to unload the operational
> > costs and responsibility for operating the GPS network since they don't
need
> > it to pilot warheads down a chimney pipe from orbital anymore. Intertial
Nav
> > being what it is these days and precision timepieces themselves...
> >
> > If I am wrong here, would someone from the Fed, NIST, or the Air Force
step
> > in and set  the record straight for all of us?
> >
> > #2  I  seem to recall Judah Levine, NIST's master timekeeper, mentioning
> > several occaisions where the Air Force had actually intentionally
diddled
> > the time to make it inaccurate for 'wartime service reasons', and since
GPS
> > has no authentication for the public users, this commercial relaince
just
> > doesn't make sense.  If you have any doubt of this check with Pat Cain,
the
> > remark was part of Judah's general presentation to the ISC in Seattle
last
> > September, and  we were both there so he can verify  this
> >
> > #3 Also, as another issue about the physical act of deploying GPS, most
> > commercial customers would need Roof Access or something similar to
support
> > their GPS site, unless they buy Datum's new RF system for locally
> > distributing GPS...  [Anyone from Datum want to jump in here? Dave,
Bill,
> > Ron, Greg?].
> >
> > #4 Not to mention GPS's epoch is coming this August 22nd and none of the
> > cheap systems will be able to deal with it that I know of.
> >
> > Datum and the other players had to extensive firmware updates to support
the
> > rollover in their receivers, since when the AF designed GPS they assumed
we
> > would all be dead now or the system no longer in operation. That's why
the
> > 10 bit wide week counter is it in GPS. Nice thought, eh?
> >
> > Don't lose complete faith, all in all, they (Congress) will likely
address
> > this when the multitude of Cadillac Owners gets PO'd that their
NorthStar
> > Autolocator's don't work, or you turn your GPS system on and it say's
> > "HELP - NO SATTELLITES ACQUIRED".
> >
> > Now, alternatively - there is GLONAS, but the Russian's are not looked
on
> > too favorably in the technical services arena to date, so it is unlikely
> > that this system will be implementad as a commercially viable timesource
> > without a new operator... like maybe the UN (just my own opinions here,
> > BTW). Likewise, in Germany the have the DFS77 system. My point is that
very
> > few countries outside the US trust GPS and rightly so.
> >
> > So, unless maybe some member of the Big-4 Audit staff wants to publicly
> > stand up and say GPS is OK by us and our customers the world over, I'll
> > rest this issue.
> >
> > >or use a specific NIST source,
> >
> > In this country or in any country that contracts with NIST to operate
their
> > "Clock's",  this would be fine - if you could show how the time data got
to
> > you and you could prove the chain of custody against it. Currently the
> > public NIST servers do this.
> >
> > >or whatever.
> >
> > Annnnnngggggggghhhhhh (insert "Buzzer" sound here)- This last one is the
> > wrong answer from my viewpoint, "whatever" means that we get to
'free-form'
> > our proofing models - so I have to ask the rhetorical question "whats
the
> > point of standardizing the methodology of building the token structure
as we
> > are with these efforts, if the time data is crap and unrelaible?",
becuase
> > then it all comes down to my word against your and thats worthless to me
as
> > a commercial provider. It seems to me that tghe real issue here in the
> > relative timestamping systems is that they cannot deal with the issue of
> > distributing legally relaible time. Its not that hard. Its just that its
> > something that you have to go talk to a physicist about rather than a
> > programmer, eh?
> >
> > > So long
> > > as the policy can be associated with the TSA that should suffice.
> >
> > I disagree here too - The value of the timestamping is in the stability
of
> > the event representation structure that is produced as  the evidentiary
> > output of the proofing services. Not in the TSA's policy that operates
it.
> > The TSA's policy is only an attribute of the engine creating the stamp.
> >
> > >I assume
> > > that a TSA will tend to be consistent, for fairly long periods, in its
> > > choice of time source,
> >
> > Steve, I think that this is a bad assumption to make. I think that
> > timestamping is something that will happen to the bigger picture and
that
> > the commercial world will absorb the overhead of the token structure and
> > processing info, but that they need absolute, not relative timestamping.
> >
> > In closing, I feel that this Time Stamping is important for making EC a
> > global thing like it could be. So pardon my "enthusiasm", but here the
real
> > issue is the International Standarization on the event representation
> > mechanism, i.e. the token itself. The method of creating it is
important,
> > but is a secondary consideration.This is why the BERT proposal is so
> > powerful (http://www.gmtsw.com/ietf).
> >
> > Todd
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22435 for ietf-pkix-bks; Fri, 28 May 1999 07:46:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22430 for <[e-mail]>; Fri, 28 May 1999 07:46:56 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA27267; Fri, 28 May 1999 10:47:28 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b3745a512e71@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a04b3709e767a28@[128.89.0.110]>		 <[e-mail]> <v04020a07b3731c29531b@[128.89.0.110]>
Date: Fri, 28 May 1999 10:46:08 -0400
To: "Dale Gustafson" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dale,

Two Stephen's no waiting :-).

>1) Has anyone described this AC Model in summary form ?

see the I-D as a starting point for PKIX discussion.

>2) Is there an assumption that an AC "must always" contain a reference to an
>x.509 ID-cert ?

My view of the model says yes.  ACs don't exist independent of public key
certs.

>3) Can an AC contain ...
>
> - a pointer to an ID-cert { Issuer DN, Serial Number, Key Hash } ?

yes.

> - a reference to an ID-cert (ID-cert Hash) ?

I hadn't thought about that, but maybe.

> - a full copy of an ID-cert ?

I hope not. just as we strive to incorporate policies by reference (through
OIDs) we would not want to stuff another cert into an AC.

my responses for these questions are based not on what one might be able to
do, syntatically, based on the X.509 spec, but what we ought to profile
based on a larged context model of how ACs are to be used.  we used to have
debates in PEM and in PKIX about whether one could use any attribute
defined for an X.500 directory entry as an RDN component in a subject or
issuer name.  there was no syntactic prohibition against it in X.509, but
it violated the model of what a DN is, and thus ought not be put in subject
or issuer names.  that same notion of what's the model and thus what ought
one do with ACs should be a part of discussion here.

>4) Is it a general and extensible model or something that can accomodate
>selected access control applications only?

We all want something general and flexible, but to ensure reasonable
interoperability we have to temper those characteristics a bit.  certainly
we envision use of ACs for a wide range of PKI-enabled Internet apps, e.g.,
S/MIME, SSL, IPsec, ...

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21924 for ietf-pkix-bks; Fri, 28 May 1999 06:56:01 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21920 for <[e-mail]>; Fri, 28 May 1999 06:56:00 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id PAA17889 for <[e-mail]>; Fri, 28 May 1999 15:56:51 +0200
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id PAA64786; Fri, 28 May 1999 15:56:00 +0200
Received: by HYDRA with Microsoft Mail id <01BEA922.6AB658F0@HYDRA>; Fri, 28 May 1999 15:54:49 +0200
Message-ID: <01BEA922.6AB658F0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Aram Perez <[e-mail]>, "'Stephen Farrell'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI? 
Date: Fri, 28 May 1999 15:54:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aram,
One solution is to use a PKC containing a pseudonym but where the CA guarantees that
you can trace the individual in case of criminal actions. 

I think that you should consider another much more flexible model of using ACs where the original
subject has been authorized with a pseudonym  AC (or just a dynamic credential) but where the AC
subject is the authorizing organization and associated PKC.

                 http://www.mobilephones-tng.com/v100/dynamiccerts.html

This solution could be even applied to governmental (official) use as well as it may (or may not) be of particular
interest who the individual officer is, but where the authorizer has full control (logging) of each officer's activities.

E.g. if you try to authorize an immigration form, the authorizing organization can check that you
have this authority during the signing and return the authority's sign with an AC containing the
minimum external identity information required.   Like a digital replacement for the currently used
authority stamp and officer's handwritten signature.

May I ask you if the application is something along those lines or entirely different?

Regards
Anders Rundgren


----------
From:  Stephen Farrell [SMTP:[e-mail]]
Sent:  Friday, May 28, 1999 12:21
To:  Aram Perez
Cc:  [e-mail]; [e-mail]
Subject:  Re: X.509 ACs vs. SPKI? 


Aram,

> Does either path offer the ability to grant a permission without revealing
> the identity of who is being granted the permission? I was talking with some
> folks yesterday who want to implement a very large PKI system used to access
> control but they have legal requirements in certain cases to keep the
> identity of the user private.

Can't recall for spki, but the ACs I-D does have support
for encrypted attributes, but this is more a case
of concealing the permissions, rather than the identity
which is presumably visible in a public key cert anyway.

Regards,
Stephen.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA20194 for ietf-pkix-bks; Fri, 28 May 1999 04:07:25 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA20189 for <[e-mail]>; Fri, 28 May 1999 04:07:20 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Fri, 28 May 1999 12:05:46 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 12:04:54 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id MAA17308; Fri, 28 May 1999 12:05:31 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id MAA02363; Fri, 28 May 1999 12:05:29 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Denis Pinkas <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, [e-mail]
Subject: attribute encryption (was: Re: X.509 ACs vs. SPKI?)
In-Reply-To: Your message of "Fri, 28 May 1999 12:40:13 +0200." <[e-mail]> 
MIME-Version: 1.0
Date: Fri, 28 May 1999 12:05:29 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

> I don't want to get into deep discussion here but ...

On this one, I'm happy to:-)

> I would not recommend to support encrypted attributes even if the ISO document and
> the current draft allow for it. It is an extra level of complexity and we can live
> without it for the moment (and maybe for ever).

I guess you know that we have a kind of Pre-AC based product
(based on a thing called SESAME:-). One of the most useful
features we've deployed (as opposed to implemented) is support 
for passing application username/password pairs as encrypted 
attributes (this is the service authentication info in the I-D).

There may also be many situations where the fact that I
possess a privilege is sensitive and attribute encryption
is a nice way to handle this rather than having to 
produce and manage many ACs and carefully control access
to the ACs themselves. 

Finally, when proxying an AC, (aka delegation in SESAME terms),
there are cases where I don't want each AC verifier in the
chain to know all of the privileges; again encrypted 
attributes help here.

In terms of complexity, its pretty easy as long as you have
a CMS/PKCS#7 EnvelopedData handler already, we've implemented
it, and I also know of one other implementation supporting
this. It didn't take long in either case.

Regards,
Stephen.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19919 for ietf-pkix-bks; Fri, 28 May 1999 03:40:16 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA19913 for <[e-mail]>; Fri, 28 May 1999 03:40:13 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id MAA15872; Fri, 28 May 1999 12:40:34 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 May 1999 12:40:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Farrell <[e-mail]>
CC: [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,

I don't want to get into deep discussion here but ...

> Aram,
>
> > Does either path offer the ability to grant a permission without revealing
> > the identity of who is being granted the permission? I was talking with some
> > folks yesterday who want to implement a very large PKI system used to access
> > control but they have legal requirements in certain cases to keep the
> > identity of the user private.
>
> Can't recall for spki, but the ACs I-D does have support
> for encrypted attributes,

I would not recommend to support encrypted attributes even if the ISO document and
the current draft allow for it. It is an extra level of complexity and we can live
without it for the moment (and maybe for ever).


> but this is more a case
> of concealing the permissions, rather than the identity
> which is presumably visible in a public key cert anyway.

Pseudonyms can be used in a public key certificate and thus the name of the signer
maybe be reasonably cancelled.

Regards,

Denis

>
> Regards,
> Stephen.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19767 for ietf-pkix-bks; Fri, 28 May 1999 03:25:39 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA19762 for <[e-mail]>; Fri, 28 May 1999 03:25:34 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Fri, 28 May 1999 11:25:26 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 11:24:36 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id LAA15384; Fri, 28 May 1999 11:25:14 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id LAA02272; Fri, 28 May 1999 11:25:12 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Dale Gustafson" <[e-mail]>
Cc: Stephen Kent <[e-mail]>, Terry Hayes <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI? 
In-Reply-To: Your message of "Thu, 27 May 1999 13:33:38 CDT." <[e-mail]> 
MIME-Version: 1.0
Date: Fri, 28 May 1999 11:25:11 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dale,

(Different Steve here, but never mind:-)

I hope that the ACs I-D does contain exactly that. I'd certainly
be interested in your comments if it doesn't!

The I-D's at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-00.txt

Regards,
Stephen.

> Steve,
> 
> A couple of questions:
> 
> 1) Has anyone described this AC Model in summary form ?
> 
> 2) Is there an assumption that an AC "must always" contain a reference to an
> x.509 ID-cert ?
> 
> 3) Can an AC contain ...
> 
>  - a pointer to an ID-cert { Issuer DN, Serial Number, Key Hash } ?
>  - a reference to an ID-cert (ID-cert Hash) ?
>  - a full copy of an ID-cert ?
> 
> 4) Is it a general and extensible model or something that can accomodate
> selected access control applications only?
> 
> Best Regards,
> 
> Dale Gustafson
> 
> ---------------------
> Stephen Kent wrote:
> 
> > Terry,
> >
> > >I believe that this is the point.  The AC would be associated with the
> > >key, not
> > >with any specific certificate.  Yes, that means there is no published
> > >expiration
> > >time for the key, no way to check revocation (except perhaps with the
> > >keyholder),
> > >and no way to associate a global name with it.  The last time I checked,
> > >it was
> > >still possible to use key pairs without having a certificate associated
> > >with them!
> > >:)
> >
> > In the X.509 AC model, the key is extracted from a validated identity cert,
> > and that cert does contain the management data about key lifetime, etc.
> > It's just that the AC is used as an important input for rule-based (maybe
> > role-based too) access control decisions, rather than just using the
> > identity in the certificate.  Putting a key hash in an AC does not make it
> > into a SPKI cert :-).
> >
> > Steve
> 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19697 for ietf-pkix-bks; Fri, 28 May 1999 03:21:21 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA19693 for <[e-mail]>; Fri, 28 May 1999 03:21:19 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Fri, 28 May 1999 11:21:32 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 11:20:47 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id LAA15193; Fri, 28 May 1999 11:21:25 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id LAA02253; Fri, 28 May 1999 11:21:24 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Aram Perez" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI? 
In-Reply-To: Your message of "Thu, 27 May 1999 11:25:45 PDT." <[e-mail]> 
MIME-Version: 1.0
Date: Fri, 28 May 1999 11:21:23 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aram,

> Does either path offer the ability to grant a permission without revealing
> the identity of who is being granted the permission? I was talking with some
> folks yesterday who want to implement a very large PKI system used to access
> control but they have legal requirements in certain cases to keep the
> identity of the user private.

Can't recall for spki, but the ACs I-D does have support
for encrypted attributes, but this is more a case
of concealing the permissions, rather than the identity
which is presumably visible in a public key cert anyway.

Regards,
Stephen.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA17934 for ietf-pkix-bks; Fri, 28 May 1999 03:08:26 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA17928 for <[e-mail]>; Fri, 28 May 1999 03:08:24 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Fri, 28 May 1999 10:51:12 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Fri, 28 May 1999 10:50:18 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id KAA13584; Fri, 28 May 1999 10:50:39 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id KAA29946; Fri, 28 May 1999 10:50:15 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: Petra Gloeckner <[e-mail]>
Cc: Russ Housley <[e-mail]>, Anders Rundgren <[e-mail]>, PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: Re: Unsettled topics, Qualified Certificates. 
In-Reply-To: Your message of "Thu, 27 May 1999 14:45:05 +0200." <[e-mail]> 
MIME-Version: 1.0
Date: Fri, 28 May 1999 10:50:14 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> in general I like the idea of attribute certificates but they are 
> quite difficult to handle.
> How do you assure that the certificate holder will send the respective
> attribute certificate along which contains the maximum value per 
> transaction? He could only send his signature certificate or a totally
> different attribute certificate and the recipient won't know that
> there is another attribute certificate containing a maximum value per
> transaction.

I don't want to get into deep discussion here but of course there
are interop problems which can arise with a server handling
transaction limits (e.g. a server which has handles
Sterling transactions has know what to do with a Euro limit,
which it mightn't). The use of ACs (in this case short-lived,
I'd guess) provides one way to implement limits (note that
I'm not saying this is the only, or the best, way, so lets
not have a big discussion on all the possibilities:-)

On the "how", side; one scheme is for the server can ask an AC 
issuer or search a repository for an AC "owned" by the 
certificate owner and which includes a transaction limit.

Regards,
Stephen.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16937 for ietf-pkix-bks; Fri, 28 May 1999 02:43:50 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16933 for <[e-mail]>; Fri, 28 May 1999 02:43:47 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id LAA15238; Fri, 28 May 1999 11:44:01 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 May 1999 11:43:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: "Todd S. Glassey - ELN" <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on time-stamp-01: Identification of TSA
References: <[e-mail]><[e-mail]> <v04020a0fb37336bc9254@[128.89.0.110]> <03d501bea898$dd96b750$930aff0c@brick>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

Altough this E-mail is primarily for Steve, I would like to make a few comments
on it:

1° I think that the tone that is being used in your reply here is not adequate
and should be moderated.

2° We are defining a Time Stamping Protocol that can be used in many dfferent
contexts. We do not claim that it is usable in all the contexts. We have made a
few *simple* extensions that were beyond the original goal, in particular to be
able to answer to the simple question "What time is it ?" when the requester has
no local time available. The primary need is only to prove that a digital
signature was created before a given date. That digital signature may be any
signature; e.g. from a user; from a CA for a user certificate,
cross-certificate, CRL, ARL; from an Attribute Authority for an Attribute
Certificate ... As there are too many examples of use, only a few are mentioned
in the annex.

3° The protocol is sufficient for our current needs. Thus I do not see the need
to extend the terms of reference of our charter to cover more.

Regards,

Denis
(co-author of the current draft)


> Stephen
> I respect and appreciate your accomplishments but I think you dead wrong
> here and everything I have had to live through for the last two years tells
> me I am right.  My issue in saying this publicly is that "Stephen Kent" is a
> name that carries a lot of weight when it is attached to an opinion, which
> is why I am so baffled as to your resistance to building in these proofing
> facilities into the timestamping process.
>
> It seems to me that what we are focusing on here is an elaborate mechanism
> to pass relative time through a distributed infrastructure, rather than the
> real goal - that being to have a system for representing events in time that
> is accurate, believable, and commercially viable.  Mark the phrase
> "Commercially Viable", because it is the key to any market success we will
> have unless someone puts a law in place to mandate our products.
>
> Personally, I am starting to want to call this timestamping protocol the
> Bradley Fighting Vehicle of the PKIX group - ever see Kelsey Grammer in
> "Pentagon Wars" - and although I know that is not true, it's sorta how I
> feel about all the abuse I have taken for questioning the use and
> architecture of this effort's end goals.  The ultimate reason for my
> responses here is driven in the simple economic fact that if I have to shell
> out money for this technology, it better pay me back somehow.
>
> As to your commentary particular that "it's not there" below, that is to
> say, the ability in the protocol to prove the chain of custody against the
> time source - I know it's not there and I am trying to figure out why.
>
> What I think we have built here today is a system that requires the user or
> operator to jump through external hoops to prove the process and model of
> operations at the sites are OK, otherwise the timestamps issued are of
> questionable veracity and as such there use and reception are likely to be
> limited.
>
> As to the existing draft's specification, my problem is that I have still
> not figured out a legally binding model for a large enough segment of the co
> mmercial world to use this timestamping technology, that this makes
> commercial sense.
>
> DONT GET ME WRONG - I AM NOT TRYING TO TELL YOU THAT THE ZUCCERATTO, et al.
> DRAFT IS BROKEN, just that I want to understand the use models driving all
> this effort in detail.
>
> ----- Original Message -----
> From: Stephen Kent <[e-mail]>
> To: Todd S. Glassey - ELN <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, May 27, 1999 10:55 AM
> Subject: Re: Comments on time-stamp-01: Identification of TSA
>
> > Todd,
> >
> > There is no requirement that the time stamp carry info that purports to
> > trace the origin of the time source.  That info may be expressed in the
> > TSA's policy, as a static assertion, unless the WG determines that such a
> > static assertion is not sufficiently flexible.
>
> I question this
>
> > For example, a TSA might
> > say that they use GPS,
>
> Stephen, personally I don't think that this will ever happen in a
> commercially functional sense.
>
> #1  no one would who needs a really viable audit done would use and rely on
> the timedata from GPS alone, since the US Air Force controls it. Also there
> is the real world a pretty major problem in that the GPS sattillites that
> are currently available are going to start decommissioning themselves
> because their Atomic Clocks are out of cal [becuase of their age] and  as
> such, they cannot be adjusted or refurbished in their current orbits.
>
> >From my last understanding, the US Congress has reallocated the replacement
> GPS Sattellite launch slots on the STS  (the Shuttle) to other "projects"
> including the international space station, so at last count GPS is sort of
> dying... or its at least being ignored. Also, I further understand that
> there is a funny issue ofthe  Air Force trying to unload the operational
> costs and responsibility for operating the GPS network since they don't need
> it to pilot warheads down a chimney pipe from orbital anymore. Intertial Nav
> being what it is these days and precision timepieces themselves...
>
> If I am wrong here, would someone from the Fed, NIST, or the Air Force step
> in and set  the record straight for all of us?
>
> #2  I  seem to recall Judah Levine, NIST's master timekeeper, mentioning
> several occaisions where the Air Force had actually intentionally diddled
> the time to make it inaccurate for 'wartime service reasons', and since GPS
> has no authentication for the public users, this commercial relaince just
> doesn't make sense.  If you have any doubt of this check with Pat Cain, the
> remark was part of Judah's general presentation to the ISC in Seattle last
> September, and  we were both there so he can verify  this
>
> #3 Also, as another issue about the physical act of deploying GPS, most
> commercial customers would need Roof Access or something similar to support
> their GPS site, unless they buy Datum's new RF system for locally
> distributing GPS...  [Anyone from Datum want to jump in here? Dave, Bill,
> Ron, Greg?].
>
> #4 Not to mention GPS's epoch is coming this August 22nd and none of the
> cheap systems will be able to deal with it that I know of.
>
> Datum and the other players had to extensive firmware updates to support the
> rollover in their receivers, since when the AF designed GPS they assumed we
> would all be dead now or the system no longer in operation. That's why the
> 10 bit wide week counter is it in GPS. Nice thought, eh?
>
> Don't lose complete faith, all in all, they (Congress) will likely address
> this when the multitude of Cadillac Owners gets PO'd that their NorthStar
> Autolocator's don't work, or you turn your GPS system on and it say's
> "HELP - NO SATTELLITES ACQUIRED".
>
> Now, alternatively - there is GLONAS, but the Russian's are not looked on
> too favorably in the technical services arena to date, so it is unlikely
> that this system will be implementad as a commercially viable timesource
> without a new operator... like maybe the UN (just my own opinions here,
> BTW). Likewise, in Germany the have the DFS77 system. My point is that very
> few countries outside the US trust GPS and rightly so.
>
> So, unless maybe some member of the Big-4 Audit staff wants to publicly
> stand up and say GPS is OK by us and our customers the world over, I'll
> rest this issue.
>
> >or use a specific NIST source,
>
> In this country or in any country that contracts with NIST to operate their
> "Clock's",  this would be fine - if you could show how the time data got to
> you and you could prove the chain of custody against it. Currently the
> public NIST servers do this.
>
> >or whatever.
>
> Annnnnngggggggghhhhhh (insert "Buzzer" sound here)- This last one is the
> wrong answer from my viewpoint, "whatever" means that we get to 'free-form'
> our proofing models - so I have to ask the rhetorical question "whats the
> point of standardizing the methodology of building the token structure as we
> are with these efforts, if the time data is crap and unrelaible?", becuase
> then it all comes down to my word against your and thats worthless to me as
> a commercial provider. It seems to me that tghe real issue here in the
> relative timestamping systems is that they cannot deal with the issue of
> distributing legally relaible time. Its not that hard. Its just that its
> something that you have to go talk to a physicist about rather than a
> programmer, eh?
>
> > So long
> > as the policy can be associated with the TSA that should suffice.
>
> I disagree here too - The value of the timestamping is in the stability of
> the event representation structure that is produced as  the evidentiary
> output of the proofing services. Not in the TSA's policy that operates it.
> The TSA's policy is only an attribute of the engine creating the stamp.
>
> >I assume
> > that a TSA will tend to be consistent, for fairly long periods, in its
> > choice of time source,
>
> Steve, I think that this is a bad assumption to make. I think that
> timestamping is something that will happen to the bigger picture and that
> the commercial world will absorb the overhead of the token structure and
> processing info, but that they need absolute, not relative timestamping.
>
> In closing, I feel that this Time Stamping is important for making EC a
> global thing like it could be. So pardon my "enthusiasm", but here the real
> issue is the International Standarization on the event representation
> mechanism, i.e. the token itself. The method of creating it is important,
> but is a secondary consideration.This is why the BERT proposal is so
> powerful (http://www.gmtsw.com/ietf).
>
> Todd



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16656 for ietf-pkix-bks; Fri, 28 May 1999 02:21:45 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16652 for <[e-mail]>; Fri, 28 May 1999 02:21:43 -0700 (PDT)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id LAA13584; Fri, 28 May 1999 11:22:35 +0200
Message-ID: <[e-mail]>
Date: Fri, 28 May 1999 11:22:14 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <v04020a04b3709e767a28@[128.89.0.110]> <v04020a04b37301f52a6c@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I agree with your response

In ESS (from the S/MIME WG) there is the following structure which unambigously
references an certificate.

ESSCertID ::=  SEQUENCE {
     certHash                 Hash,
     issuerSerial             IssuerSerial OPTIONAL
}

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

IssuerSerial ::= SEQUENCE {
     issuer                   GeneralNames,
     serialNumber             CertificateSerialNumber

I suggest that we generalize it, to support any kind of HASH function, i.e. not
limiting it to SHA 1. In addition IssuerSerial should be made mandatory instead
of optional (there was a good reason to make it optional in ESS/CMS, because
the information was normaly already present in the CMS structure).

Denis


> Denis,
>
> Yes, there is a problem with tying an AC so closely to a key, or even to a
> cert in its entity, as Russ pointed out to me in a private message.  One
> can imagine a spectrum of binding, from the subject name to the public key
> hash, to a hash of the whole cert.  The tighter the binding, the less
> opportunity for confusion or for malicious rebinding. Tighter bindings may
> require duplicate ACs, as in the examples you and Russ provided, and more
> frequent reissuance, based on identity cert reissuance.  However, I am very
> concerned about security lapses here, so we will need to carefully evaluate
> the benefits and costs of different approaches to effecting the binding.
> Issuing additional ACs because of a key hash or cert hash binding may not
> be so bad.  Still, I may have overstated the need to use these hashes in
> all cases in ourt profile.
>
> Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA14465 for ietf-pkix-bks; Thu, 27 May 1999 23:38:58 -0700 (PDT)
Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA14459 for <[e-mail]>; Thu, 27 May 1999 23:38:56 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2448.0) id <LZH2QLLT>; Fri, 28 May 1999 08:39:15 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Robert Zuccherato <[e-mail]>
Cc: [e-mail]
Subject: R: Comments on time-stamp-01: Identification of TSA
Date: Fri, 28 May 1999 08:39:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA14462
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That could be simply fixed by declaring the tsaName field OPTIONAL...and
stating in the text that it's intended purpose is just that of a "hint" or
as an alternative name, carrying however no definite value in itself (only
the subject of the accompanying certificate in the outer SigneData structure
counts, of course).

Adriano

-----Messaggio originale-----
Da: Denis Pinkas [mailto:[e-mail]]
Inviato: giovedì 27 maggio 1999 13.47
A: Robert Zuccherato
Cc: [e-mail]
Oggetto: Re: Comments on time-stamp-01: Identification of TSA


Robert,

I have been away during (only) 6 days and the number of ER-mails about the
TSP
draft is quite important. I will need to answer some other related E-mails
but
let us start by this one where you explicitly mention my name.

> The tsa field within the token is present to allow end users to obtain the
> identity of the supposed TSA without requiring them to obtain the TSAs
> certificate.  Considering that the tokens created by a TSA will be used
for
> non-repudiation in situations very removed (in time and space) from those
in
> which they were created, it may be useful to be able to refer to the token
> with serial number XXXXX from TSA YYYYY, without the only method of
> identifying the TSA being their subjectKeyIdentifier (or
> issuerAndSerialNumber).
>
> The ESSCertiID Attribute was added, as an option, upon the specific
request
> of Denis Pinkas.  I don't recall the arguments for it, so I will allow him
> to respond directly.

Hum! Since you raised the question, to tell the truth I was/am only
advocating
the use of ESSCertiID and the current document is the reflect of a (good/bad
?)
compromise.

Robert, you said : "The tsa field within the token is present to allow end
users
to obtain the identity of the supposed TSA without requiring them to obtain
the
TSAs certificate." A TSP caller will have anyway to verify the signature of
the
TSA, so it will always need the TSAs certificate (i.e. the
issuerAndSerialNumber
field). The name in the token itself is both insecure and useless. It is
insecure because it does not handle TSA name collission properly, so it can
only
be used as an hint. The hint is not very useful anyhow since it does not
allow
to point to all the TSA homonyms (if any). It is useless because it does not
allow to point unambigoulsly to the right certificate. So supporting the
identification of the TSA in the signer info is not really an option but a
need.
So I agree that there are too many ways to identify the TSA.

Denis


>
>         Robert.
>
> > ----------
> > From:         [e-mail][SMTP:[e-mail]]
> > Reply To:     [e-mail]
> > Sent:         Monday, May 24, 1999 4:53 PM
> > To:   [e-mail]
> > Subject:      Comments on time-stamp-01: Identification of TSA
> >
> > <<File: thayes.vcf>>
> > The current time-stamp draft contains several places that define fields
> > or recommend use of previously defined fields to identify the TSA
> > creating the token.  I believe that the draft provides too many ways to
> > do this, which will work against creation of interoperable
> > implementations.  In addition, I believe that some of the current
> > options are motivated by concerns that are better addressed in other
> > ways.
> >
> > First, the protocol uses a CMS SignedData object as the basic form of
> > the time-stamp token.  This object allows identification of the signer
> > in the SignerInfo section.  This data is sufficient to locate the
> > correct certificate, build the chain and validate TSA's identity.  This
> > should be the primary (and possibly only) method of identifying the TSA
> > that generated the token.  However, the current draft goes on to mention
> > several other identification fields.
> >
> > The draft contains the following text:
> >
> >      The purpose of the tsa field is to identify the name of the
> >      TSA.  If present, it MUST correspond to one of the subject
> >      names included in the certificate that is to be used to verify
> >      the token.  This field MAY be omitted if the Signing
> >      Certificate Attribute has been included as a signed
> >      attribute.  (See Section 5 of [ESS].) It MUST be present if
> >      the ESSCertID Attribute is not used to identify the TSA.
> >
> > 'tsa' is an optional GeneralName field defined within the TSTInfo
> > sequence.  Because it is optional, it cannot be relied upon to locate
> > the proper certificate needed to verify the token.  It may be useful to
> > locate the certificate if a verifier files certificates using values
> > other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
> > TSA would need to know what other types of GeneralName might be useful
> > to a client.  The 'tsa' field does have one difference from the
> > SignerInfo fields - it is signed with the message.  This has some
> > significance for some attacks on the protocol, which I'll discuss later.
> >
> > The 'substitution attack' ([ESS]) is prevented for TSA signatures in two
> > ways.  First, the key used for signing time-stamp tokens is required to
> > be used only for that purpose.  This means that existence of a second
> > certificate (with different capabilities) for the same key is already
> > prohibited by the draft.  Second, the token also contains a
> > PolicyIdentifier that is effect for the signature.  The verifier must
> > check that the certificate chain allows this policy to be used.  This
> > requirement prevents a second certificate (with different
> > PolicyIdentifier values) from being used to check the signature.  In
> > fact, the policy identifiers in the SigningCertificate sequence of [ESS]
> > duplicate the value already found in the token.
> >
> > Finally, the time-stamping draft expresses concern for attacks that may
> > occur when the CA does not perform proof-of-possession checks on the TSA
> > key.  To counter these, the draft encourages use of the fields mentioned
> > above (including the tsa field, and the SigningCertificate attribute)
> > which are included within the token signature.  This prevents a
> > substitution attack where the substitute certificate is for an entirely
> > different subject name.  However, since other drafts will address these
> > attacks during the certificate enrollment process (the CMC draft
> > contains proof-of-possession protocol), I think the time-stamp protocol
> > should not define its own mechanisms for dealing with the problem.
> >
> > In summary, there are too many ways to identify the TSA certificate.  We
> > should use the basic CMS SignerInfo for this data.  Attacks (as listed
> > in [ESS]) Concerns about proof-of-possession flaws should be addressed
> > elsewhere, specifically in the certificate request process.
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA02631 for ietf-pkix-bks; Thu, 27 May 1999 16:30:02 -0700 (PDT)
Received: from penguin.prod.itd.earthlink.net (penguin.prod.itd.earthlink.net [207.217.120.134]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA02626 for <[e-mail]>; Thu, 27 May 1999 16:30:01 -0700 (PDT)
Received: from brick (sdn-ar-015casfraP013.dialsprint.net [158.252.219.15]) by penguin.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id QAA17525; Thu, 27 May 1999 16:30:35 -0700 (PDT)
Message-ID: <03d501bea898$dd96b750$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><[e-mail]> <v04020a0fb37336bc9254@[128.89.0.110]>
Subject: Re: Comments on time-stamp-01: Identification of TSA
Date: Thu, 27 May 1999 16:29:34 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen
I respect and appreciate your accomplishments but I think you dead wrong
here and everything I have had to live through for the last two years tells
me I am right.  My issue in saying this publicly is that "Stephen Kent" is a
name that carries a lot of weight when it is attached to an opinion, which
is why I am so baffled as to your resistance to building in these proofing
facilities into the timestamping process.

It seems to me that what we are focusing on here is an elaborate mechanism
to pass relative time through a distributed infrastructure, rather than the
real goal - that being to have a system for representing events in time that
is accurate, believable, and commercially viable.  Mark the phrase
"Commercially Viable", because it is the key to any market success we will
have unless someone puts a law in place to mandate our products.

Personally, I am starting to want to call this timestamping protocol the
Bradley Fighting Vehicle of the PKIX group - ever see Kelsey Grammer in
"Pentagon Wars" - and although I know that is not true, it's sorta how I
feel about all the abuse I have taken for questioning the use and
architecture of this effort's end goals.  The ultimate reason for my
responses here is driven in the simple economic fact that if I have to shell
out money for this technology, it better pay me back somehow.

As to your commentary particular that "it's not there" below, that is to
say, the ability in the protocol to prove the chain of custody against the
time source - I know it's not there and I am trying to figure out why.

What I think we have built here today is a system that requires the user or
operator to jump through external hoops to prove the process and model of
operations at the sites are OK, otherwise the timestamps issued are of
questionable veracity and as such there use and reception are likely to be
limited.

As to the existing draft's specification, my problem is that I have still
not figured out a legally binding model for a large enough segment of the co
mmercial world to use this timestamping technology, that this makes
commercial sense.

DONT GET ME WRONG - I AM NOT TRYING TO TELL YOU THAT THE ZUCCERATTO, et al.
DRAFT IS BROKEN, just that I want to understand the use models driving all
this effort in detail.

----- Original Message -----
From: Stephen Kent <[e-mail]>
To: Todd S. Glassey - ELN <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, May 27, 1999 10:55 AM
Subject: Re: Comments on time-stamp-01: Identification of TSA


> Todd,
>
> There is no requirement that the time stamp carry info that purports to
> trace the origin of the time source.  That info may be expressed in the
> TSA's policy, as a static assertion, unless the WG determines that such a
> static assertion is not sufficiently flexible.

I question this

> For example, a TSA might
> say that they use GPS,

Stephen, personally I don't think that this will ever happen in a
commercially functional sense.

#1  no one would who needs a really viable audit done would use and rely on
the timedata from GPS alone, since the US Air Force controls it. Also there
is the real world a pretty major problem in that the GPS sattillites that
are currently available are going to start decommissioning themselves
because their Atomic Clocks are out of cal [becuase of their age] and  as
such, they cannot be adjusted or refurbished in their current orbits.

>From my last understanding, the US Congress has reallocated the replacement
GPS Sattellite launch slots on the STS  (the Shuttle) to other "projects"
including the international space station, so at last count GPS is sort of
dying... or its at least being ignored. Also, I further understand that
there is a funny issue ofthe  Air Force trying to unload the operational
costs and responsibility for operating the GPS network since they don't need
it to pilot warheads down a chimney pipe from orbital anymore. Intertial Nav
being what it is these days and precision timepieces themselves...

If I am wrong here, would someone from the Fed, NIST, or the Air Force step
in and set  the record straight for all of us?

#2  I  seem to recall Judah Levine, NIST's master timekeeper, mentioning
several occaisions where the Air Force had actually intentionally diddled
the time to make it inaccurate for 'wartime service reasons', and since GPS
has no authentication for the public users, this commercial relaince just
doesn't make sense.  If you have any doubt of this check with Pat Cain, the
remark was part of Judah's general presentation to the ISC in Seattle last
September, and  we were both there so he can verify  this

#3 Also, as another issue about the physical act of deploying GPS, most
commercial customers would need Roof Access or something similar to support
their GPS site, unless they buy Datum's new RF system for locally
distributing GPS...  [Anyone from Datum want to jump in here? Dave, Bill,
Ron, Greg?].

#4 Not to mention GPS's epoch is coming this August 22nd and none of the
cheap systems will be able to deal with it that I know of.

Datum and the other players had to extensive firmware updates to support the
rollover in their receivers, since when the AF designed GPS they assumed we
would all be dead now or the system no longer in operation. That's why the
10 bit wide week counter is it in GPS. Nice thought, eh?

Don't lose complete faith, all in all, they (Congress) will likely address
this when the multitude of Cadillac Owners gets PO'd that their NorthStar
Autolocator's don't work, or you turn your GPS system on and it say's
"HELP - NO SATTELLITES ACQUIRED".

Now, alternatively - there is GLONAS, but the Russian's are not looked on
too favorably in the technical services arena to date, so it is unlikely
that this system will be implementad as a commercially viable timesource
without a new operator... like maybe the UN (just my own opinions here,
BTW). Likewise, in Germany the have the DFS77 system. My point is that very
few countries outside the US trust GPS and rightly so.

So, unless maybe some member of the Big-4 Audit staff wants to publicly
stand up and say GPS is OK by us and our customers the world over, I'll
rest this issue.

>or use a specific NIST source,

In this country or in any country that contracts with NIST to operate their
"Clock's",  this would be fine - if you could show how the time data got to
you and you could prove the chain of custody against it. Currently the
public NIST servers do this.

>or whatever.

Annnnnngggggggghhhhhh (insert "Buzzer" sound here)- This last one is the
wrong answer from my viewpoint, "whatever" means that we get to 'free-form'
our proofing models - so I have to ask the rhetorical question "whats the
point of standardizing the methodology of building the token structure as we
are with these efforts, if the time data is crap and unrelaible?", becuase
then it all comes down to my word against your and thats worthless to me as
a commercial provider. It seems to me that tghe real issue here in the
relative timestamping systems is that they cannot deal with the issue of
distributing legally relaible time. Its not that hard. Its just that its
something that you have to go talk to a physicist about rather than a
programmer, eh?

> So long
> as the policy can be associated with the TSA that should suffice.

I disagree here too - The value of the timestamping is in the stability of
the event representation structure that is produced as  the evidentiary
output of the proofing services. Not in the TSA's policy that operates it.
The TSA's policy is only an attribute of the engine creating the stamp.

>I assume
> that a TSA will tend to be consistent, for fairly long periods, in its
> choice of time source,

Steve, I think that this is a bad assumption to make. I think that
timestamping is something that will happen to the bigger picture and that
the commercial world will absorb the overhead of the token structure and
processing info, but that they need absolute, not relative timestamping.

In closing, I feel that this Time Stamping is important for making EC a
global thing like it could be. So pardon my "enthusiasm", but here the real
issue is the International Standarization on the event representation
mechanism, i.e. the token itself. The method of creating it is important,
but is a secondary consideration.This is why the BERT proposal is so
powerful (http://www.gmtsw.com/ietf).

Todd



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00823 for ietf-pkix-bks; Thu, 27 May 1999 14:52:06 -0700 (PDT)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA00818 for <[e-mail]>; Thu, 27 May 1999 14:52:05 -0700 (PDT)
Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id OAA14212; Thu, 27 May 1999 14:52:39 -0700 (PDT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id <KVLG5MP4>; Thu, 27 May 1999 14:52:38 -0700
Message-ID: <[e-mail]>
From: "Ellison, Carl M" <[e-mail]>
To: Denis Pinkas <[e-mail]>, Terry Hayes <[e-mail]>
Cc: "Ellison, Carl M" <[e-mail]>, "'Carl Ellison'" <[e-mail]>, [e-mail], [e-mail]
Subject: Paper  (was RE: X.509 ACs vs. SPKI?)
Date: Thu, 27 May 1999 14:52:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



> -----Original Message-----
> From: Carl Ellison [mailto:[e-mail]]
> Sent: Thursday, May 27, 1999 9:22 AM
> To: Terry Hayes
> Cc: Denis Pinkas; Ellison, Carl M; [e-mail]; [e-mail]
> Subject: Re: X.509 ACs vs. SPKI?
 
[snip]

> When I give talks on this subject, I draw a triangle whose vertices
> are labeled Name, Permission and Key.  (I draw it with name on top and
> key on the right.)

E.g., Figure 2, p.826 in

Ellison, "The nature of a useable PKI", Computer Networks 31 (1999) 823-830.


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQA/AwUBN02+u8xqBGb+WvJAEQIoGwCgkSjoH89casYcBdpjTmvIaUTzbAoAoM/H
sBom5ZfhOaXdwtz0IIL9dB/R
=jiOM
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA26177 for ietf-pkix-bks; Thu, 27 May 1999 11:31:23 -0700 (PDT)
Received: from dkeynt1.DATAKEY.COM (dkeynt1.datakey.com [205.218.59.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA26168 for <[e-mail]>; Thu, 27 May 1999 11:31:14 -0700 (PDT)
Received: from datakey.com ([205.218.59.75]) by dkeynt1.DATAKEY.COM (Netscape Messaging Server 3.5)  with ESMTP id 390; Thu, 27 May 1999 13:37:12 -0500
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 13:33:38 -0500
From: "Dale Gustafson" <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: Terry Hayes <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <v04020a04b3709e767a28@[128.89.0.110]> <[e-mail]> <v04020a07b3731c29531b@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

A couple of questions:

1) Has anyone described this AC Model in summary form ?

2) Is there an assumption that an AC "must always" contain a reference to an
x.509 ID-cert ?

3) Can an AC contain ...

 - a pointer to an ID-cert { Issuer DN, Serial Number, Key Hash } ?
 - a reference to an ID-cert (ID-cert Hash) ?
 - a full copy of an ID-cert ?

4) Is it a general and extensible model or something that can accomodate
selected access control applications only?

Best Regards,

Dale Gustafson

---------------------
Stephen Kent wrote:

> Terry,
>
> >I believe that this is the point.  The AC would be associated with the
> >key, not
> >with any specific certificate.  Yes, that means there is no published
> >expiration
> >time for the key, no way to check revocation (except perhaps with the
> >keyholder),
> >and no way to associate a global name with it.  The last time I checked,
> >it was
> >still possible to use key pairs without having a certificate associated
> >with them!
> >:)
>
> In the X.509 AC model, the key is extracted from a validated identity cert,
> and that cert does contain the management data about key lifetime, etc.
> It's just that the AC is used as an important input for rule-based (maybe
> role-based too) access control decisions, rather than just using the
> identity in the certificate.  Putting a key hash in an AC does not make it
> into a SPKI cert :-).
>
> Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA26003 for ietf-pkix-bks; Thu, 27 May 1999 11:25:08 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25999 for <[e-mail]>; Thu, 27 May 1999 11:25:07 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id LAA65832 for <[e-mail]>; Thu, 27 May 1999 11:25:53 -0700
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 27 May 1999 11:25:48 -0700
Received: from [17.205.41.166] (aram1.apple.com [17.205.41.166]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id LAA18708 for <[e-mail]>; Thu, 27 May 1999 11:25:46 -0700
Message-Id: <[e-mail]>
X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410)
Date: Thu, 27 May 1999 11:25:45 -0700
Subject: Re: X.509 ACs vs. SPKI?
From: "Aram Perez" <[e-mail]>
To: [e-mail]
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl Ellison wrote:

[snip]
> 
> In SPKI, we distinguish between the terms "attribute cert" and "authorization
> cert".
>
> When I give talks on this subject, I draw a triangle whose vertices
> are labeled Name, Permission and Key.  (I draw it with name on top and
> key on the right.)
>
> The goal for us application developers is to map a Permission to a Key,
> but we can go from left to right in two different ways.
>
> We can take an authorization cert directly from Permission to Key or
> we can take a pair of certs:  attrubute cert from Permission to Name and
> id cert from Name to Key.

Does either path offer the ability to grant a permission without revealing
the identity of who is being granted the permission? I was talking with some
folks yesterday who want to implement a very large PKI system used to access
control but they have legal requirements in certain cases to keep the
identity of the user private.

Thanks,
Aram Perez


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25266 for ietf-pkix-bks; Thu, 27 May 1999 10:53:39 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25262 for <[e-mail]>; Thu, 27 May 1999 10:53:37 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA05973; Thu, 27 May 1999 13:54:16 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0fb37336bc9254@[128.89.0.110]>
In-Reply-To: <02fc01bea866$0eb33a30$930aff0c@brick>
References: <[e-mail]> <[e-mail]>
Date: Thu, 27 May 1999 13:55:18 -0400
To: "Todd S. Glassey - ELN" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Comments on time-stamp-01: Identification of TSA
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

There is no requirement that the time stamp carry info that purports to
trace the origin of the time source.  That info may be expressed in the
TSA's policy, as a static assertion, unless the WG determines that such a
static assertion is not sufficiently flexible.  For example, a TSA might
say that they use GPS, or use a specific NIST source, or whatever.  So long
as the policy can be associated with the TSA that should suffice.  I assume
that a TSA will tend to be consistent, for fairly long periods, in its
choice of time source, so a facility to record this data in each token seem
like overkill.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24738 for ietf-pkix-bks; Thu, 27 May 1999 10:26:15 -0700 (PDT)
Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24734 for <[e-mail]>; Thu, 27 May 1999 10:26:14 -0700 (PDT)
Received: from brick (sdn-ar-015casfraP144.dialsprint.net [158.252.219.146]) by goose.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id KAA09245; Thu, 27 May 1999 10:26:45 -0700 (PDT)
Message-ID: <02fc01bea866$0eb33a30$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Robert Zuccherato" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Comments on time-stamp-01: Identification of TSA
Date: Thu, 27 May 1999 10:26:21 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Robert Zuccherato <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, May 27, 1999 4:47 AM
Subject: Re: Comments on time-stamp-01: Identification of TSA


> Robert,
>
> I have been away during (only) 6 days and the number of ER-mails about the
TSP
> draft is quite important. I will need to answer some other related E-mails
but
> let us start by this one where you explicitly mention my name.
>
> > The tsa field within the token is present to allow end users to obtain
the
> > identity of the supposed TSA without requiring them to obtain the TSAs
> > certificate.  Considering that the tokens created by a TSA will be used
for
> > non-repudiation in situations very removed (in time and space) from
those in
> > which they were created, it may be useful to be able to refer to the
token
> > with serial number XXXXX from TSA YYYYY, without the only method of
> > identifying the TSA being their subjectKeyIdentifier (or
> > issuerAndSerialNumber).
> >
> > The ESSCertiID Attribute was added, as an option, upon the specific
request
> > of Denis Pinkas.  I don't recall the arguments for it, so I will allow
him
> > to respond directly.

How does this architecture allow me to trace the origin of the time data
itself and what qualifies it in the timestamp as being legitimate. Just
because said so?

>
> Hum! Since you raised the question, to tell the truth I was/am only
advocating
> the use of ESSCertiID and the current document is the reflect of a
(good/bad ?)
> compromise.
>
> Robert, you said : "The tsa field within the token is present to allow end
users
> to obtain the identity of the supposed TSA without requiring them to
obtain the
> TSAs certificate." A TSP caller will have anyway to verify the signature
of the
> TSA, so it will always need the TSAs certificate (i.e. the
issuerAndSerialNumber
> field). The name in the token itself is both insecure and useless. It is
> insecure because it does not handle TSA name collission properly, so it
can only
> be used as an hint. The hint is not very useful anyhow since it does not
allow
> to point to all the TSA homonyms (if any). It is useless because it does
not
> allow to point unambigoulsly to the right certificate. So supporting the
> identification of the TSA in the signer info is not really an option but a
need.
> So I agree that there are too many ways to identify the TSA.
>
> Denis
>
>
> >
> >         Robert.
> >
> > > ----------
> > > From:         [e-mail][SMTP:[e-mail]]
> > > Reply To:     [e-mail]
> > > Sent:         Monday, May 24, 1999 4:53 PM
> > > To:   [e-mail]
> > > Subject:      Comments on time-stamp-01: Identification of TSA
> > >
> > > <<File: thayes.vcf>>
> > > The current time-stamp draft contains several places that define
fields
> > > or recommend use of previously defined fields to identify the TSA
> > > creating the token.  I believe that the draft provides too many ways
to
> > > do this, which will work against creation of interoperable
> > > implementations.  In addition, I believe that some of the current
> > > options are motivated by concerns that are better addressed in other
> > > ways.
> > >
> > > First, the protocol uses a CMS SignedData object as the basic form of
> > > the time-stamp token.  This object allows identification of the signer
> > > in the SignerInfo section.  This data is sufficient to locate the
> > > correct certificate, build the chain and validate TSA's identity.
This
> > > should be the primary (and possibly only) method of identifying the
TSA
> > > that generated the token.  However, the current draft goes on to
mention
> > > several other identification fields.
> > >
> > > The draft contains the following text:
> > >
> > >      The purpose of the tsa field is to identify the name of the
> > >      TSA.  If present, it MUST correspond to one of the subject
> > >      names included in the certificate that is to be used to verify
> > >      the token.  This field MAY be omitted if the Signing
> > >      Certificate Attribute has been included as a signed
> > >      attribute.  (See Section 5 of [ESS].) It MUST be present if
> > >      the ESSCertID Attribute is not used to identify the TSA.
> > >
> > > 'tsa' is an optional GeneralName field defined within the TSTInfo
> > > sequence.  Because it is optional, it cannot be relied upon to locate
> > > the proper certificate needed to verify the token.  It may be useful
to
> > > locate the certificate if a verifier files certificates using values
> > > other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
> > > TSA would need to know what other types of GeneralName might be useful
> > > to a client.  The 'tsa' field does have one difference from the
> > > SignerInfo fields - it is signed with the message.  This has some
> > > significance for some attacks on the protocol, which I'll discuss
later.
> > >
> > > The 'substitution attack' ([ESS]) is prevented for TSA signatures in
two
> > > ways.  First, the key used for signing time-stamp tokens is required
to
> > > be used only for that purpose.  This means that existence of a second
> > > certificate (with different capabilities) for the same key is already
> > > prohibited by the draft.  Second, the token also contains a
> > > PolicyIdentifier that is effect for the signature.  The verifier must
> > > check that the certificate chain allows this policy to be used.  This
> > > requirement prevents a second certificate (with different
> > > PolicyIdentifier values) from being used to check the signature.  In
> > > fact, the policy identifiers in the SigningCertificate sequence of
[ESS]
> > > duplicate the value already found in the token.
> > >
> > > Finally, the time-stamping draft expresses concern for attacks that
may
> > > occur when the CA does not perform proof-of-possession checks on the
TSA
> > > key.  To counter these, the draft encourages use of the fields
mentioned
> > > above (including the tsa field, and the SigningCertificate attribute)
> > > which are included within the token signature.  This prevents a
> > > substitution attack where the substitute certificate is for an
entirely
> > > different subject name.  However, since other drafts will address
these
> > > attacks during the certificate enrollment process (the CMC draft
> > > contains proof-of-possession protocol), I think the time-stamp
protocol
> > > should not define its own mechanisms for dealing with the problem.
> > >
> > > In summary, there are too many ways to identify the TSA certificate.
We
> > > should use the basic CMS SignerInfo for this data.  Attacks (as listed
> > > in [ESS]) Concerns about proof-of-possession flaws should be addressed
> > > elsewhere, specifically in the certificate request process.
> > >
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24298 for ietf-pkix-bks; Thu, 27 May 1999 09:54:00 -0700 (PDT)
Received: from ridge.spiritone.com (ridge.spiritone.com [205.139.108.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24294 for <[e-mail]>; Thu, 27 May 1999 09:53:59 -0700 (PDT)
Received: from acm.org ([e-mail] [208.130.240.208]) by ridge.spiritone.com (8.8.8/8.8.8) with ESMTP id JAA25157; Thu, 27 May 1999 09:54:38 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 09:53:54 -0700
From: Carl Ellison <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.30 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>, Denis Pinkas <[e-mail]>, "Ellison, Carl M" <[e-mail]>, [e-mail], [e-mail]
Subject: DN's (was Re: X.509 ACs vs. SPKI?)
References: <v04020a04b3709e767a28@[128.89.0.110]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl Ellison wrote:
> unique way.  Since there are no globally unique (ie., distinguished)
> textual names and there never will be (IMHO), we choose to make
> names unique by using what we call a Fully Quanlified name:

I used sloppy wording here and want to forestall a storm of replies
pointing that out.

There are *many* globally unique names: phone numbers, e-mail addresses,
US SSN, ....  What there isn't is a *single* globally unique name system.
That's what I mean by "distinguished name" (lowercase, to distinguish it
from an X.500 DN).  Of course, X.500 once thought it was going to produce
distinguished names and much of its design is based on that assumption.
This implies a value system difference and we know from psychology
that a value system difference produces religious debates that never
resolve.

 - Carl

-- 
 Carl M. Ellison   [e-mail]     http://www.pobox.com/~cme
 PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2
 ``Officer, officer, arrest that man!  He's whistling a dirty song.''
     [Jean Ellison]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24068 for ietf-pkix-bks; Thu, 27 May 1999 09:23:51 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24064 for <[e-mail]>; Thu, 27 May 1999 09:23:50 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA19822; Thu, 27 May 1999 12:24:35 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a07b3731c29531b@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a04b3709e767a28@[128.89.0.110]> <[e-mail]>
Date: Thu, 27 May 1999 12:23:53 -0400
To: [e-mail] (Terry Hayes)
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Terry,

>I believe that this is the point.  The AC would be associated with the
>key, not
>with any specific certificate.  Yes, that means there is no published
>expiration
>time for the key, no way to check revocation (except perhaps with the
>keyholder),
>and no way to associate a global name with it.  The last time I checked,
>it was
>still possible to use key pairs without having a certificate associated
>with them!
>:)

In the X.509 AC model, the key is extracted from a validated identity cert,
and that cert does contain the management data about key lifetime, etc.
It's just that the AC is used as an important input for rule-based (maybe
role-based too) access control decisions, rather than just using the
identity in the certificate.  Putting a key hash in an AC does not make it
into a SPKI cert :-).

Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24040 for ietf-pkix-bks; Thu, 27 May 1999 09:21:45 -0700 (PDT)
Received: from ridge.spiritone.com (ridge.spiritone.com [205.139.108.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24036 for <[e-mail]>; Thu, 27 May 1999 09:21:44 -0700 (PDT)
Received: from acm.org ([e-mail] [208.130.240.217]) by ridge.spiritone.com (8.8.8/8.8.8) with ESMTP id JAA10955; Thu, 27 May 1999 09:22:23 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 09:21:40 -0700
From: Carl Ellison <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.30 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Terry Hayes <[e-mail]>
CC: Denis Pinkas <[e-mail]>, "Ellison, Carl M" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <v04020a04b3709e767a28@[128.89.0.110]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Terry Hayes wrote:
> 
> Denis Pinkas wrote:
[snip]
> > A user may have two public key certificates with two different names but with
> > the same public key. In that case it is not always possible to know with which
> > of the two certificates the AC is associated.
> 
> I believe that this is the point.  The AC would be associated with the key, not
> with any specific certificate.  Yes, that means there is no published expiration
> time for the key, no way to check revocation (except perhaps with the keyholder),
> and no way to associate a global name with it.  The last time I checked, it was
> still possible to use key pairs without having a certificate associated with them!
> :)
> 
> Validity time, and revocation services would only apply to the AC itself it this
> environment.

In SPKI, we distinguish between the terms "attribute cert" and "authorization
cert".

When I give talks on this subject, I draw a triangle whose vertices
are labeled Name, Permission and Key.  (I draw it with name on top and
key on the right.)

The goal for us application developers is to map a Permission to a Key,
but we can go from left to right in two different ways.

We can take an authorization cert directly from Permission to Key or
we can take a pair of certs:  attrubute cert from Permission to Name and
id cert from Name to Key.

To do that latter path, you have to identify the Name in a globally
unique way.  Since there are no globally unique (ie., distinguished)
textual names and there never will be (IMHO), we choose to make
names unique by using what we call a Fully Quanlified name:

	(name <key> n_1 n_2 ... n_k)

where <key> is the public key (or its hash) of a name issuer.  In the
X.509 world, this is the root key of a hierarchy.

n_i are the names from that (root) key to the particular name we
care about.  In X.509, this would be the names of the CAs enroute from
the root key to the leaf name.  In SPKI, it's a SDSI name chain.
The two are equivalent, from the point of view of the authorization
computation.

What I was trying to say about X.509 ACs was that a form that turns it
into an authorization certificate can be interpreted unambiguously, but
if you want to use it as an attribute certificate, it's missing the ability
to specify a Fully Qualified name.

 - Carl


-- 
 Carl M. Ellison   [e-mail]     http://www.pobox.com/~cme
 PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2
 ``Officer, officer, arrest that man!  He's whistling a dirty song.''
     [Jean Ellison]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23765 for ietf-pkix-bks; Thu, 27 May 1999 08:47:01 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23761 for <[e-mail]>; Thu, 27 May 1999 08:47:01 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA14446 for <[e-mail]>; Thu, 27 May 1999 08:47:18 -0700 (PDT)
Received: from netscape.com ([206.222.244.70]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FCEEIT00.3WB; Thu, 27 May 1999 08:47:17 -0700 
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 08:44:02 -0700
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Stephen Kent <[e-mail]>, "Ellison, Carl M" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <v04020a04b3709e767a28@[128.89.0.110]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:

> Steve,
>
> I have a comment on this E-mail.
>
> > Carl,
> >
> > I agree that the only safe way to bind an attribute cert to an identity
> > cert is via the public key hash. That's what I always recommend to my
> > clients.
>
> I wonder if it is a good recommendation. :-(  This may be appropriate in some
> contexts but not in general.
>
> A user may have two public key certificates with two different names but with
> the same public key. In that case it is not always possible to know with which
> of the two certificates the AC is associated.

I believe that this is the point.  The AC would be associated with the key, not
with any specific certificate.  Yes, that means there is no published expiration
time for the key, no way to check revocation (except perhaps with the keyholder),
and no way to associate a global name with it.  The last time I checked, it was
still possible to use key pairs without having a certificate associated with them!
:)

Validity time, and revocation services would only apply to the AC itself it this
environment.

Terry




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23677 for ietf-pkix-bks; Thu, 27 May 1999 08:34:09 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23672 for <[e-mail]>; Thu, 27 May 1999 08:34:07 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA09785; Thu, 27 May 1999 11:34:44 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a06b3731511a864@[128.89.0.110]>
In-Reply-To:  <[e-mail]>
Date: Thu, 27 May 1999 11:34:36 -0400
To: "Fillingham,  David W." <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

Good point.  One really needs to check the name from an identity cert in
context, e.g., after making sure that the whole cert chain is acceptable
for the context in question.  if we made more use of nameConstraints, this
would be easier to manage and less error/attack prone.  I suspect that part
of the alarm cited here arises from a concern that imeplementations of
access controllers will fail to impose the necessary constrain checks and
thus will open up new avenues of attack.  For example, say you receive an
attribute cert and identity cert from a user. The module for identity cert
validation is invoked and it returns OK, because the user in question is
authorized to do something in your system.  However, the attribute cert was
really bound to another user with the same subject name, due to inadeqaute
controls over name spaces, or due to malicious behavior on the part of a CA
in some other administrative domain.  The result might be a granting of
inappropriate access to the user.  While it is true that the same thing
could happen based solely upon subject name mismanagement, the
opportunities for these sorts of errors may be even greater when we add the
additional complexity of processing ACs.  I won't claim that this is an
airtight argument, but I think it captures the flavor of the concerns that
motivate soem fo the discussion you are seeing on the list.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23615 for ietf-pkix-bks; Thu, 27 May 1999 08:29:28 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23611 for <[e-mail]>; Thu, 27 May 1999 08:29:27 -0700 (PDT)
Received: 	id LAA16568; Thu, 27 May 1999 11:25:55 -0400
Received: by gateway id <LMML0FVQ>; Thu, 27 May 1999 11:28:21 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'gang cao'" <[e-mail]>
Subject: RE: how to determine tstTime in time-stamp?
Date: Thu, 27 May 1999 11:28:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm not sure if I really understand your question.  If I sign a document at
time T1 and have that signed document timestamped at time T2, then all you
can really say about the relationship of T1 and T2 is that T1 came before T2
(i.e. T1<T2).

> ----------
> From: 	gang cao[SMTP:[e-mail]]
> Sent: 	Thursday, May 27, 1999 5:48 AM
> To: 	[e-mail]
> Subject: 	how to determine tstTime in time-stamp?
> 
> when TSA return the TimeStampToken , how to
> determine the value of tstTime in TSTInfo?
> if one say  he signaures a datum on Time1 , and
> the tstTime is Time2,what is the relationship between
> Time1 and Time2?
>  Thanks for Any help!
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23438 for ietf-pkix-bks; Thu, 27 May 1999 08:08:04 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23434 for <[e-mail]>; Thu, 27 May 1999 08:08:01 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA19993 for <[e-mail]>; Thu, 27 May 1999 11:08:44 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA19989 for <[e-mail]>; Thu, 27 May 1999 11:08:43 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA18041 for <[e-mail]>; Thu, 27 May 1999 11:08:49 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (avenger53.missi.ncsc.mil) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 27 May 1999 11:08:21 -0400
Received: by avenger54.missi.ncsc.mil with Internet Mail Service (5.5.2232.9) id <LX8NSX1F>; Thu, 27 May 1999 11:08:54 -0400
Message-Id: <[e-mail]>
From: "Fillingham,  David W." <[e-mail]>
To: [e-mail]
Subject: RE: X.509 ACs vs. SPKI?
Date: Thu, 27 May 1999 11:08:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BEA852.D5528132"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01BEA852.D5528132
Content-Type: text/plain

All:

One question I've had along these lines is why is it that people are
generally perfectly willing to accept the binding of a name authenticated
via an X.509 certificate for authenticating access via access control lists,
but believe the same approach to be unsecure for authenticating access via
attribute certificates?

In other words, building access control lists that bind attributes to
Distinguished Names, then controlling access based on comparing the
Distinguished Name of the subscriber (based on an X.509 certificate-based
authentication) against the Distinguished Name in the list is, I think,
considered to be a pretty strong security mechanism.

But controlling access based on comparing the Distinguished Name of the
subscriber (based on an X.509 certificate-based authentication) against the
Distinguished Name in an Attribute Certificate is considered to be a pretty
weak security mechanism.

It just seems to me that in either case, the strength or the weakness of
using DNs to bind identities to attributes is determined by the strength of
the binding between names and identities provided by the X.509 certificate,
which is based on which CAs are being relied upon, their Certificate
Policies, and the mechanisms used to validate the certificates.

But I may be missing something important that someone else could point out
to me.

Dave

> ----------
> From: 	Stephen Kent[SMTP:[e-mail]]
> Sent: 	Thursday, May 27, 1999 10:12 AM
> To: 	Denis Pinkas
> Cc: 	[e-mail]; [e-mail]
> Subject: 	Re: X.509 ACs vs. SPKI?
> 
> Denis,
> 
> Yes, there is a problem with tying an AC so closely to a key, or even to a
> cert in its entity, as Russ pointed out to me in a private message.  One
> can imagine a spectrum of binding, from the subject name to the public key
> hash, to a hash of the whole cert.  The tighter the binding, the less
> opportunity for confusion or for malicious rebinding. Tighter bindings may
> require duplicate ACs, as in the examples you and Russ provided, and more
> frequent reissuance, based on identity cert reissuance.  However, I am
> very
> concerned about security lapses here, so we will need to carefully
> evaluate
> the benefits and costs of different approaches to effecting the binding.
> Issuing additional ACs because of a key hash or cert hash binding may not
> be so bad.  Still, I may have overstated the need to use these hashes in
> all cases in ourt profile.
> 
> Steve
> 

------_=_NextPart_001_01BEA852.D5528132
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: X.509 ACs vs. SPKI?</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">All:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">One question I've =
had along these lines is why is it that people are generally perfectly =
willing to accept the binding of a name authenticated via an X.509 =
certificate for authenticating access via access control lists, but =
believe the same approach to be unsecure for authenticating access via =
attribute certificates?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In other words, =
building access control lists that bind attributes to Distinguished =
Names, then controlling access based on comparing the Distinguished =
Name of the subscriber (based on an X.509 certificate-based =
authentication) against the Distinguished Name in the list is, I think, =
considered to be a pretty strong security mechanism.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But controlling =
access based on comparing the Distinguished Name of the subscriber =
(based on an X.509 certificate-based authentication) against the =
Distinguished Name in an Attribute Certificate is considered to be a =
pretty weak security mechanism.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It just seems to me =
that in either case, the strength or the weakness of using DNs to bind =
identities to attributes is determined by the strength of the binding =
between names and identities provided by the X.509 certificate, which =
is based on which CAs are being relied upon, their Certificate =
Policies, and the mechanisms used to validate the =
certificates.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">But I may be missing =
something important that someone else could point out to me.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Dave</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Stephen =
Kent[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D1 FACE=3D"MS Sans Serif">Thursday, May 27, 1999 10:12 =
AM</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans Serif">Denis =
Pinkas</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">[e-mail]; [e-mail]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 FACE=3D"MS Sans =
Serif">Re: X.509 ACs vs. SPKI?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Denis,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yes, there is a problem with tying an =
AC so closely to a key, or even to a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cert in its entity, as Russ pointed =
out to me in a private message.&nbsp; One</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">can imagine a spectrum of binding, =
from the subject name to the public key</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">hash, to a hash of the whole =
cert.&nbsp; The tighter the binding, the less</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">opportunity for confusion or for =
malicious rebinding. Tighter bindings may</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">require duplicate ACs, as in the =
examples you and Russ provided, and more</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">frequent reissuance, based on =
identity cert reissuance.&nbsp; However, I am very</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">concerned about security lapses here, =
so we will need to carefully evaluate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the benefits and costs of different =
approaches to effecting the binding.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Issuing additional ACs because of a =
key hash or cert hash binding may not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be so bad.&nbsp; Still, I may have =
overstated the need to use these hashes in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">all cases in ourt profile.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Steve</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BEA852.D5528132--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22998 for ietf-pkix-bks; Thu, 27 May 1999 07:17:49 -0700 (PDT)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22994 for <[e-mail]>; Thu, 27 May 1999 07:17:48 -0700 (PDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by fwma1.certco.com (Postfix) with ESMTP id 87E6C15533; Thu, 27 May 1999 10:17:55 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <LX0WTAQY>; Thu, 27 May 1999 10:17:55 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Trying again: Unsettled topics, Qualified Certificates.
Date: Thu, 27 May 1999 10:17:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>    currency  PrintableString,          -- e.g. "USD" for U.S. Dollar

ISO spec 4217 defines a standard for currency names; the
value should be constrained to that.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22954 for ietf-pkix-bks; Thu, 27 May 1999 07:14:19 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22950 for <[e-mail]>; Thu, 27 May 1999 07:14:17 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA22119; Thu, 27 May 1999 10:15:00 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b37301f52a6c@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a04b3709e767a28@[128.89.0.110]>
Date: Thu, 27 May 1999 10:12:01 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Yes, there is a problem with tying an AC so closely to a key, or even to a
cert in its entity, as Russ pointed out to me in a private message.  One
can imagine a spectrum of binding, from the subject name to the public key
hash, to a hash of the whole cert.  The tighter the binding, the less
opportunity for confusion or for malicious rebinding. Tighter bindings may
require duplicate ACs, as in the examples you and Russ provided, and more
frequent reissuance, based on identity cert reissuance.  However, I am very
concerned about security lapses here, so we will need to carefully evaluate
the benefits and costs of different approaches to effecting the binding.
Issuing additional ACs because of a key hash or cert hash binding may not
be so bad.  Still, I may have overstated the need to use these hashes in
all cases in ourt profile.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22712 for ietf-pkix-bks; Thu, 27 May 1999 06:48:17 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22708 for <[e-mail]>; Thu, 27 May 1999 06:48:15 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id PAA31933 for <[e-mail]>; Thu, 27 May 1999 15:48:58 +0200
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id PAA59824; Thu, 27 May 1999 15:48:35 +0200
Received: by HYDRA with Microsoft Mail id <01BEA858.387C9630@HYDRA>; Thu, 27 May 1999 15:47:27 +0200
Message-ID: <01BEA858.387C9630@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Russ Housley <[e-mail]>, "'Petra Gloeckner'" <[e-mail]>
Cc: Anders Rundgren </o=Jaybis.AB/ou=JAYBIS/cn=Recipients/cn=[e-mail]>, PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Unsettled topics, Qualified Certificates.
Date: Thu, 27 May 1999 15:47:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Petra,

>in general I like the idea of attribute certificates but they are 
>quite difficult to handle.
>How do you assure that the certificate holder will send the respective
>attribute certificate along which contains the maximum value per 
>transaction? He could only send his signature certificate or a totally
>different attribute certificate and the recipient won't know that
>there is another attribute certificate containing a maximum value per
>transaction.

I think the problem is because you talk about an unspecified transaction format.

In real life transaction formats are very specific (like PKC+AC with defined content) regardless if they
are purely local or global like SET.

So it is really a question what the potential users/deployers of such a solution would like to have.

As you may have noted [ :-) ] I am much in favor of the idea that TTPs make simple ID-only-certs while
information unrelated to the subject (transaction limits) or volatile (employment) should come from other places
through ACs or dynamic credentials.

Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA22236 for ietf-pkix-bks; Thu, 27 May 1999 05:47:33 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA22232 for <[e-mail]>; Thu, 27 May 1999 05:47:29 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-ravenna [141.12.33.61]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id OAA27431; Thu, 27 May 1999 14:46:49 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 14:45:05 +0200
From: Petra Gloeckner <[e-mail]>
X-Mailer: Mozilla 4.08 [en] (WinNT; I)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: Anders Rundgren <[e-mail]>, PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: Re: Unsettled topics, Qualified Certificates.
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB4D00833C374C14757DDA459"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------msB4D00833C374C14757DDA459
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Russ,

in general I like the idea of attribute certificates but they are 
quite difficult to handle.
How do you assure that the certificate holder will send the respective
attribute certificate along which contains the maximum value per 
transaction? He could only send his signature certificate or a totally
different attribute certificate and the recipient won't know that
there is another attribute certificate containing a maximum value per
transaction.

Petra

Russ Housley wrote:
> 
> In my view, maximum value per transaction is a good candidate for an
> attribute certificate.
> 
> Russ
> 
> At 05:35 PM 5/25/99 +0200, Anders Rundgren wrote:
> >Stefan,
> >
> ><snip>
> >>Issue 2) Storage of maximum value per transaction.
> >
> >>The directive requires that a certificate, if applicable, shall contain
> >>information about a maximum monetary amount per transaction that the
> >>certificate should support.
> >
> >My comment to this is that the EU directive seems to try to solve all
> >business problems with
> >certificates.  This is IMO a bad idea and will only delay things.
> >
> >Let's say that you open a door with a cert.  How can you possibly say how
> >much value you have behind the door?
> >
> >And what is the true value of a signed business contract?
> >
> >For monetary transactions it is up to the relying party (the bank, the
> >selling organization) to
> >set proper limits and to your organization as well.  To do this in a static
> >certificate
> >(probably issued by a TTP) is lunacy.
> >
> >>This could be done by defining a new extension (like the Germans already
> >>have done in their interoperability specifications), or alternatively just
> >>say that this shall be solved by a certificate policy, possibly in
> >>combination with a policy qualifier.
> >
> >Certificate policy could specify liability but that does not have anything
> >to do
> >with the sums you transact or protect.
> >
> >>Arguments has been raised that Policy qualifiers are not suitable for
> >>automatic interpretation but that is not confirmed.
> >
> >Of course you can have any number of optional items but if people start to
> >actually use them you will pretty soon run into severe problems.
> >
> >So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep some
> >people happy) but
> >just IGNORE them in real implementations.  This is the proper (only) way to
> >handle EU bureaucracy :-)  :-)
> >
> >Anders Rundgren
> >http://www.mobilephones-tng.com
> >
> >
--------------msB4D00833C374C14757DDA459
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIHdgYJKoZIhvcNAQcCoIIHZzCCB2MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BicwggLYMIICQaADAgECAgEjMA0GCSqGSIb3DQEBBAUAMC4xCzAJBgNVBAYTAkRFMQwwCgYD
VQQKEwNHTUQxETAPBgNVBAsTCFJlc2VhcmNoMB4XDTk5MDUxNzExNDQwOVoXDTk5MTIzMDAw
MDAwMFowOTELMAkGA1UEBhMCREUxEDAOBgNVBAsTB0lDRS1URUwxGDAWBgNVBAMTD1BldHJh
IEdsb2Vja25lcjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDF/y9O0V0d+UvnuVx7eEekJVio
Ou71225spnLn4UOz0fjH3ErtPYINSQyHaZYaU5Ap5gm5SVKKnIwXTpe/tJszAgMBAAGjggE9
MIIBOTAfBgNVHSMEGDAWgBSGd6DS+j1+rl1hezxHkwcTp1tPNzAdBgNVHQ4EFgQUqpiCaylX
DhKKERBVySN+c3VTFIMwDgYDVR0PAQH/BAQDAgTwMBUGA1UdIAQOMAwwCgYIKwYBBAGVGAow
JAYDVR0RBB0wG4EZZ2xvZWNrbmVAZGFybXN0YWR0LmdtZC5kZTBUBgNVHRIETTBLgRNDQUBk
YXJtc3RhZHQuZ21kLmRlhjRodHRwOi8vd3d3LmRhcm1zdGFkdC5nbWQuZGUvZ21kY2EvZG93
bmxvYWQvZ21kY2EuY2VyMAwGA1UdEwEB/wQCMAAwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDov
L3d3dy5kYXJtc3RhZHQuZ21kLmRlL2dtZGNhL2Rvd25sb2FkL2NybHNldC5kZXIwDQYJKoZI
hvcNAQEEBQADgYEAwNKDdR4g9uuNKkw6ELfQy9DPzsKFRV3y2A0JPsLP5LQbSWemnzAvau9f
OcoK7JuS3i635QjmoREBBxKUd3EV0TmvkkBUWtNTgu/ppIgFTgcSNBHs4HViPWCPedOEk86T
DbvL35as4MJgNOpy27kjZriuhY7xx6G45j6KPEV1haAwggNHMIICsKADAgECAgEOMA0GCSqG
SIb3DQEBBAUAME8xDzANBgNVBAcTBkV1cm9wZTEQMA4GA1UEChMHSUNFLVRFTDEqMCgGA1UE
CxMhVG9wIExldmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDUxNDA5NTkwN1oX
DTk5MTIzMTEyMDAwMFowLjELMAkGA1UEBhMCREUxDDAKBgNVBAoTA0dNRDERMA8GA1UECxMI
UmVzZWFyY2gwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANvisjL+mP2bYrtCrCpM675F
DN5aTeEuHDK+ZNN/RVxzsKhfPM/aHk4lw93QjxYe/HhxcD0h11pWBUJmqzW9SW1mOisD6S4j
9voogaMXZyHL3wLbj+J2waWF8gWWQe09y7O4SJigYiZogHLJ20ge0lKFLuxO08jZ7xo29RxF
YZclAgMBAAGjggFSMIIBTjAfBgNVHSMEGDAWgBS4G0Z5jHzrEtU/QaPh/egnL45SqjAdBgNV
HQ4EFgQUhneg0vo9fq5dYXs8R5MHE6dbTzcwDgYDVR0PAQH/BAQDAgH2MBUGA1UdIAQOMAww
CgYIKwYBBAGVGAowVAYDVR0RBE0wS4ETQ0FAZGFybXN0YWR0LmdtZC5kZYY0aHR0cDovL3d3
dy5kYXJtc3RhZHQuZ21kLmRlL2dtZGNhL2Rvd25sb2FkL2dtZGNhLmNlcjBFBgNVHRIEPjA8
gQ9pY2UtY2FAdW5pLWMuZGuGKWh0dHA6Ly9pY2UtdGVsLnVuaS1jLmRrL2ljZS1jYS9pY2Ut
Y2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2ljZS10
ZWwudW5pLWMuZGsvaWNlLWNhL2NybC5kZXIwDQYJKoZIhvcNAQEEBQADgYEAMMiWa8jCaiM/
Qc279xBqsZvCcaxOMyGKIx7vR2VgTZewPS65JgIbfhxyzdFKdM+WkhQB40BNS0/8lKIEcp2a
2BwZzc0/vI3kZ+I7vDCGxsXtGFXSrY90AeVyQ9f8XxHA0ZDHz9lZjO2adF0OH5JbXLzW4MpJ
GvTXRkMjAJUhnXUxggEXMIIBEwIBATAzMC4xCzAJBgNVBAYTAkRFMQwwCgYDVQQKEwNHTUQx
ETAPBgNVBAsTCFJlc2VhcmNoAgEjMAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw05OTA1MjcxMjQ1MDVaMB4GCSqGSIb3DQEJDzERMA8w
DQYIKoZIhvcNAwICASgwIwYJKoZIhvcNAQkEMRYEFJNfE+DPsFtzjpUIIYEFBiaC9dGVMA0G
CSqGSIb3DQEBAQUABECAxvciRa27i1wVRsGVlcyW0A99v+tTCXHmFQB0CKA47DNj5AweiBvP
N/CtENR22IJ8oTSNmx8CAjq2qikOupef
--------------msB4D00833C374C14757DDA459--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA22006 for ietf-pkix-bks; Thu, 27 May 1999 05:12:31 -0700 (PDT)
Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA22002 for <[e-mail]>; Thu, 27 May 1999 05:12:30 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp8.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id IAA40584 for <[e-mail]>; Thu, 27 May 1999 08:11:31 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id IAA44816 for <[e-mail]>; Thu, 27 May 1999 08:12:45 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525677E.00431393 ; Thu, 27 May 1999 08:12:39 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 08:12:33 -0400
Subject: RE: CRL retrieval
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The current problem is CRL location issues... I am not sure where to look.  I
just need LDAP locations through which I can look for CRLs.   The rest will
follow once this has been discovered.

Matthew DeRuyter
bldg 256-2  J006
ext:  x6927
tie-line: 855-6927




"Dave Sweigert" <[e-mail]> on 05/24/99 08:28:14 PM

Please respond to [e-mail]

To:   "'Alan Lloyd'" <[e-mail]>, Matthew
      Deruyter/Endicott/Contr/IBM@IBMUS, [e-mail]
cc:
Subject:  RE: CRL retrieval





Alan:

Not to mention applications timing out waiting for a response
[if using CRLS for access control].

dgs



-----Original Message-----
From: Alan Lloyd [mailto:[e-mail]]
Sent: Monday, May 24, 1999 6:55 PM
To: '[e-mail]'; [e-mail]
Subject: RE: CRL retrieval


>From a technical perspective - ie a User reading a CRL from a directory
service - with the appropriate authentication and access controls should
not be a problem.

What is the issue - is it a firewall problem, authentication failure,
access controls denial, an LDAP issue and CRL location issue, or a
product bug.
please advise.

regards alan

> -----Original Message-----
> From:   [e-mail]
> Sent:   Thursday, May 20, 1999 3:51 AM
> To:     [e-mail]
> Subject:     CRL retrieval
>
>
> I am currently writing some code that will be using CRLs to validate
> Certificates.  The Certificate portion without CRLs is complete.  I
> have been
> looking for a way to retrieve CRLs from any CA, but especially
> Verisign and have
> been unable to find a repository or any other means to retrive a CRL.
> I did
> find a page on the Verisign web site that allowed you to enter a
> certificate on
> the web site itself but I need an actual CRL to verify my certificate.
> Does
> anyone know how to retrieve CRLs or how to retrieve a CRL from
> Verisign in
> particular?
>
> Matthew DeRuyter
> bldg 256-2  J006
> ext:  x6927
> tie-line: 855-6927
>
>






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21921 for ietf-pkix-bks; Thu, 27 May 1999 04:57:53 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21917 for <[e-mail]>; Thu, 27 May 1999 04:57:50 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id NAA42238; Thu, 27 May 1999 13:57:18 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA29378; Thu, 27 May 1999 13:57:17 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 13:58:26 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "Ellison, Carl M" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <v04020a04b3709e767a28@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I have a comment on this E-mail.

> Carl,
>
> I agree that the only safe way to bind an attribute cert to an identity
> cert is via the public key hash. That's what I always recommend to my
> clients.

I wonder if it is a good recommendation. :-(  This may be appropriate in some
contexts but not in general.

A user may have two public key certificates with two different names but with
the same public key. In that case it is not always possible to know with which
of the two certificates the AC is associated.


> Look at the draft profile for attribute certs recently published by Stephen
> Farrell and it's easy to locate the key hash as pointer.  The real
> difference here is that X.509 believes that certs with public keys should
> contain a name that is not purely a local matter.
>
> The hash is the most secure way to bind an attribute (yes, "authorization"
> is a better name) cert to the identity cert, and I'll suggest that we
> mandate it in our profile as we progress.

I would not follow that suggestion but instead suggest in our profile the
support of the identification of the public key certificate the AC is
associated with.

Denis


> Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA21848 for ietf-pkix-bks; Thu, 27 May 1999 04:46:46 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA21844 for <[e-mail]>; Thu, 27 May 1999 04:46:41 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id NAA40004; Thu, 27 May 1999 13:46:13 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA29206; Thu, 27 May 1999 13:46:12 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 13:47:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on time-stamp-01: Identification of TSA
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

I have been away during (only) 6 days and the number of ER-mails about the TSP
draft is quite important. I will need to answer some other related E-mails but
let us start by this one where you explicitly mention my name.

> The tsa field within the token is present to allow end users to obtain the
> identity of the supposed TSA without requiring them to obtain the TSAs
> certificate.  Considering that the tokens created by a TSA will be used for
> non-repudiation in situations very removed (in time and space) from those in
> which they were created, it may be useful to be able to refer to the token
> with serial number XXXXX from TSA YYYYY, without the only method of
> identifying the TSA being their subjectKeyIdentifier (or
> issuerAndSerialNumber).
>
> The ESSCertiID Attribute was added, as an option, upon the specific request
> of Denis Pinkas.  I don't recall the arguments for it, so I will allow him
> to respond directly.

Hum! Since you raised the question, to tell the truth I was/am only advocating
the use of ESSCertiID and the current document is the reflect of a (good/bad ?)
compromise.

Robert, you said : "The tsa field within the token is present to allow end users
to obtain the identity of the supposed TSA without requiring them to obtain the
TSAs certificate." A TSP caller will have anyway to verify the signature of the
TSA, so it will always need the TSAs certificate (i.e. the issuerAndSerialNumber
field). The name in the token itself is both insecure and useless. It is
insecure because it does not handle TSA name collission properly, so it can only
be used as an hint. The hint is not very useful anyhow since it does not allow
to point to all the TSA homonyms (if any). It is useless because it does not
allow to point unambigoulsly to the right certificate. So supporting the
identification of the TSA in the signer info is not really an option but a need.
So I agree that there are too many ways to identify the TSA.

Denis


>
>         Robert.
>
> > ----------
> > From:         [e-mail][SMTP:[e-mail]]
> > Reply To:     [e-mail]
> > Sent:         Monday, May 24, 1999 4:53 PM
> > To:   [e-mail]
> > Subject:      Comments on time-stamp-01: Identification of TSA
> >
> > <<File: thayes.vcf>>
> > The current time-stamp draft contains several places that define fields
> > or recommend use of previously defined fields to identify the TSA
> > creating the token.  I believe that the draft provides too many ways to
> > do this, which will work against creation of interoperable
> > implementations.  In addition, I believe that some of the current
> > options are motivated by concerns that are better addressed in other
> > ways.
> >
> > First, the protocol uses a CMS SignedData object as the basic form of
> > the time-stamp token.  This object allows identification of the signer
> > in the SignerInfo section.  This data is sufficient to locate the
> > correct certificate, build the chain and validate TSA's identity.  This
> > should be the primary (and possibly only) method of identifying the TSA
> > that generated the token.  However, the current draft goes on to mention
> > several other identification fields.
> >
> > The draft contains the following text:
> >
> >      The purpose of the tsa field is to identify the name of the
> >      TSA.  If present, it MUST correspond to one of the subject
> >      names included in the certificate that is to be used to verify
> >      the token.  This field MAY be omitted if the Signing
> >      Certificate Attribute has been included as a signed
> >      attribute.  (See Section 5 of [ESS].) It MUST be present if
> >      the ESSCertID Attribute is not used to identify the TSA.
> >
> > 'tsa' is an optional GeneralName field defined within the TSTInfo
> > sequence.  Because it is optional, it cannot be relied upon to locate
> > the proper certificate needed to verify the token.  It may be useful to
> > locate the certificate if a verifier files certificates using values
> > other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
> > TSA would need to know what other types of GeneralName might be useful
> > to a client.  The 'tsa' field does have one difference from the
> > SignerInfo fields - it is signed with the message.  This has some
> > significance for some attacks on the protocol, which I'll discuss later.
> >
> > The 'substitution attack' ([ESS]) is prevented for TSA signatures in two
> > ways.  First, the key used for signing time-stamp tokens is required to
> > be used only for that purpose.  This means that existence of a second
> > certificate (with different capabilities) for the same key is already
> > prohibited by the draft.  Second, the token also contains a
> > PolicyIdentifier that is effect for the signature.  The verifier must
> > check that the certificate chain allows this policy to be used.  This
> > requirement prevents a second certificate (with different
> > PolicyIdentifier values) from being used to check the signature.  In
> > fact, the policy identifiers in the SigningCertificate sequence of [ESS]
> > duplicate the value already found in the token.
> >
> > Finally, the time-stamping draft expresses concern for attacks that may
> > occur when the CA does not perform proof-of-possession checks on the TSA
> > key.  To counter these, the draft encourages use of the fields mentioned
> > above (including the tsa field, and the SigningCertificate attribute)
> > which are included within the token signature.  This prevents a
> > substitution attack where the substitute certificate is for an entirely
> > different subject name.  However, since other drafts will address these
> > attacks during the certificate enrollment process (the CMC draft
> > contains proof-of-possession protocol), I think the time-stamp protocol
> > should not define its own mechanisms for dealing with the problem.
> >
> > In summary, there are too many ways to identify the TSA certificate.  We
> > should use the basic CMS SignerInfo for this data.  Attacks (as listed
> > in [ESS]) Concerns about proof-of-possession flaws should be addressed
> > elsewhere, specifically in the certificate request process.
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18849 for ietf-pkix-bks; Thu, 27 May 1999 02:48:26 -0700 (PDT)
Received: from www.eci.com.cn ([159.226.41.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18845 for <[e-mail]>; Thu, 27 May 1999 02:48:23 -0700 (PDT)
Received: from eci.com.cn ([10.226.41.80]) by www.eci.com.cn (Netscape Messaging Server 3.5)  with ESMTP id 324 for <[e-mail]>; Thu, 27 May 1999 17:47:31 +0100
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 17:48:52 +0800
From: "gang cao" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: how to determine tstTime in time-stamp?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

when TSA return the TimeStampToken , how to
determine the value of tstTime in TSTInfo?
if one say  he signaures a datum on Time1 , and
the tstTime is Time2,what is the relationship between
Time1 and Time2?
 Thanks for Any help!



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA18475 for ietf-pkix-bks; Thu, 27 May 1999 01:49:47 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA18471 for <[e-mail]>; Thu, 27 May 1999 01:49:45 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 0725677E.00348F0B ; Thu, 27 May 1999 01:47:45 -0700
X-Lotus-FromDomain: BULL
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 27 May 1999 01:51:46 -0700
Subject: Re: Trying again: Unsettled topics, Qualified Certificates.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello stefan

since i did nor participate in the development of 2459, i do not know the
rational for the restriction you mentioned and i will not presume to
propose amendments to it.

i do have an response to your question 1.

i don't believe that a policy qualifier needs to be marked critical. the
qualifier is in support of the policy. if one doesn't understand the
policy, then there is no need to understand the policy qualifier. if one
understands the policy then one understands the qualifier. if support of
the policy is critical, recognizing and supporting the policy is what
should be made critical.

i'm fond of criticality (having created the approach for x500 and
certificates) but i agree that marking something critical should be
considered carefully if one's goal is to issue a certificate that will
processable by the largest number of relying parties possible.

it is possible to have specialize relying party software that is performing
a task that critically needs specific information from the certificate. the
issuer could put that information in a special extension but not mark it
critical. the certificate would be usable in normal relying party software
which would ignore the unknown extension. the special relying party
software would not perform the special function unless the extension were
present, critical or not.

this approach carries over into policy. a certificate may indicate that it
can be used in policy x (as well as other policies). a relying party which
supports policy x knows that certain information must be in the
certificate, either in qualifiers or extensions, to properly process the
requested function under policy x. those extensions need not be marked
critical.

note that even though i can recommend where to place the structures you
have been proposing, i am still concerned that a common approach may not be
generally applicable to the specific needs of many different policies.

    hoyt




Stefan Santesson <[e-mail]> on 05/26/99 03:31:57 PM

To:   [e-mail], Hoyt Kesterson/US/BULL
cc:   [e-mail]
Subject:  Re: Trying again: Unsettled topics, Qualified Certificates.




Tom (and Hoyt),

I like the logic in using a policy qualifier.
There has however been raised a number of problems with that. This is
mainly:

1) A qualifier can't be marked critical (eventhough I fail to see the
problem with that)
2) RFC 2459 strongly recommends the use of qualifiers should be restricted
to use of 2 defined qualifier types and non of them seams to fit the
reliance limit case. The best one of them is aimed for textual messages and
does not suit automatic processing.

Viewed from issue 2 it doesn't seam that your proposal haromize with the
recommendation in RFC 2459. I.e. Your proposal doesn't fit into the
recommended types.

Do you have any comment to these problems.

/Stefan

At 16:11 1999-05-26 -0400, [e-mail] wrote:
>     At the risk of repeating myself, here is my proposed policy qualifier
>syntax for financial amounts, which could be used for purchase limit
whenever
>the specific policy qualifier OID indicates purchase limit:
>
>FinancialAmount     ::=  SEQUENCE
>{    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
>     currency  PrintableString,               -- e.g. "USD" for U.S.
Dollar
>     CHOICE    {
>          amount         NumericString,       -- usually including a
decimal
>point
>          value          INTEGER         -- no need for floating-point
>     }
>}
>
>     It would be perfectly reasonable to define "currency" as:
>     currency  CHOICE    {
>          currencyName        PrintableString,     -- e.g. "USD" for U.S.
>Dollar
>          currencyID          Currency   -- integer from ISO 4217
>     }
>
>     with Currency defined as in the Novell proposal, copied below:
>
>Currency ::= INTEGER (1..999) -- currency denomination from ISO 4217
>-- US Dollar (USD) is  840.
>-- Euro (EUR) is 978.
>
>          Tom Gindin







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA06106 for ietf-pkix-bks; Wed, 26 May 1999 16:24:49 -0700 (PDT)
Received: from smtp8.ny.us.ibm.com (smtp8.ny.us.ibm.com [198.133.22.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA06102 for <[e-mail]>; Wed, 26 May 1999 16:24:48 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp8.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id TAA69374; Wed, 26 May 1999 19:23:42 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id TAA207660; Wed, 26 May 1999 19:24:55 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525677D.00809A07 ; Wed, 26 May 1999 19:24:40 -0400
X-Lotus-FromDomain: IBMUS
To: Stefan Santesson <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 May 1999 19:28:51 -0400
Subject: Re: Trying again: Unsettled topics, Qualified Certificates.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan Santesson <[e-mail]> on 05/26/99 06:31:57 PM

To:   Tom Gindin/Watson/IBM@IBMUS, [e-mail]
cc:   [e-mail]
Subject:  Re: Trying again: Unsettled topics, Qualified Certificates.





Tom (and Hoyt),

I like the logic in using a policy qualifier.
There has however been raised a number of problems with that. This is mainly:

1) A qualifier can't be marked critical (eventhough I fail to see the
problem with that)

2) RFC 2459 strongly recommends the use of qualifiers should be restricted
to use of 2 defined qualifier types and none of them seems to fit the
reliance limit case. The best one of them is aimed for textual messages and
does not suit automatic processing.

Viewed from issue 2 it doesn't seam that your proposal haromize with the
recommendation in RFC 2459. I.e. Your proposal doesn't fit into the
recommended types.

[Tom Gindin]   Last week, this same topic came up, and several contributors
suggested that certificate policy qualifiers are a good place for fields
qualifying such things as signature authority amounts.  So, even though RFC 2459
section 4.2.1.5 "strongly recommends that use of qualifiers be limited to those
identified in this section", of which there are only two, I submitted some
proposed generic qualifier syntaxes for discussion, of which this was the
smallest and most specific.  Since I believe that the reason why qualifiers are
discouraged is because of interoperability difficulties in handling newly
defined qualifiers, I proposed some quite large and general qualifiers so that
they could be added to the standard definition of a qualifier and implementors
could ordinarily find any type they might need in the standard definition.  If
parameterized policies are being blocked mainly because of ASN.1 compiler
problems, perhaps it would be better to add to the list of standardized
qualifier types while continuing to deprecate non-standard ones.

Do you have any comment to these problems.

[Tom Gindin]   Unless RFC 2459 is amended to allow some new qualifier types, my
suggestion would not be permitted within PKIX.  RFC 2459 isn't very enthusiastic
about new critical extensions either, but it's less hostile to them ("caution
should be exercised") than to new policy qualifiers.

/Stefan

At 16:11 1999-05-26 -0400, [e-mail] wrote:
>     At the risk of repeating myself, here is my proposed policy qualifier
>syntax for financial amounts, which could be used for purchase limit whenever
>the specific policy qualifier OID indicates purchase limit:
>
>FinancialAmount     ::=  SEQUENCE
>{    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
>     currency  PrintableString,               -- e.g. "USD" for U.S. Dollar
>     CHOICE    {
>          amount         NumericString,       -- usually including a decimal
>point
>          value          INTEGER         -- no need for floating-point
>     }
>}
>
>     It would be perfectly reasonable to define "currency" as:
>     currency  CHOICE    {
>          currencyName        PrintableString,     -- e.g. "USD" for U.S.
>Dollar
>          currencyID          Currency   -- integer from ISO 4217
>     }
>
>     with Currency defined as in the Novell proposal, copied below:
>
>Currency ::= INTEGER (1..999) -- currency denomination from ISO 4217
>-- US Dollar (USD) is  840.
>-- Euro (EUR) is 978.
>
>          Tom Gindin






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA06078 for ietf-pkix-bks; Wed, 26 May 1999 16:22:18 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA06074 for <[e-mail]>; Wed, 26 May 1999 16:22:10 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <LT9K86FD>; Thu, 27 May 1999 09:22:42 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BEA21@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>
Cc: "'Tony Bartoletti'" <[e-mail]>, Bob Blakley <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
Subject: RE: Certificate life-cycle costs.
Date: Thu, 27 May 1999 09:22:41 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Ed - I happen to be working in this space a bit - and the theory
sometimes gets to me - simply because that is what it is - 509 validity,
attr certs, signatures and CRLs, etc.


Operationally though - lets look a a real situation. Company X does
major business with company Y - Company X's directors wife uses
Company's y ATM or certificate credit system on the day the theory
mandates the certficate has expired. Theory says the wife gets refused,
the husband gets angry and Company Y loses major business.

I certainly see that based on customer information, origination and
destination of the transaction, the transaction value and context - that
a whole lot of policy based processing needs to be performed before a
"theoretical 509 refusal" is provided ...

So what goes in a "certficate" is part of a system design - in terms of
trusting the bond between Issuer/Subject - and sufficient information to
represent the policy/credentials for WHAT it is being used in a service
framework.

I therefore believe that the theory of "certficate costs" and its
validation is just that. One has to get into operational requirements,
business practices and customer loyalty/service issues before one can
calculate "costs" of certficate loading or validation.

The above is based on the real customer requirements (who realise the
implications of the 509 theory in a service delivery/customer
environment.)


regards alan


> -----Original Message-----
> From:	Ed Gerck 
> Sent:	Wednesday, May 26, 1999 5:11 AM
> To:	Alan Lloyd
> Cc:	'Tony Bartoletti'; Bob Blakley; Bob Jueneman; [e-mail]
> Subject:	Re: Certificate life-cycle costs.
> 
> 
> 
> Alan Lloyd wrote:
> 
> > I am lost on this one.
> >
> > I am sure that those who provide products and services that apply
> > certificate  functionality will work out the deployment costs as
> part of
> > the risks, ILS/LCC analysis. As certs may be used for bus tickets,
> > vehical tags, licences, identity, information integrity, etc, etc..
> Its
> > hard to determine life cycle "costs" without knowing the application
> -
> > trust, risk, market share, customer distribution and revenues..
> Costs,
> > be they called high or low are normally determined as a percentage
> of
> > revenue...
> >
> > Whats the context of this?
> 
> ;-) Costs, in several contexts -- including the one you mention. For
> example,
> in answering the questions:
> 
> 1. In terms of  the costs of "overloading" a certificate with
> additional information,
> should you use M individual attribute certificates rather than one
> compound
> M-attribute identity certificate?
> 
> 2. If certificate retrieval costs X, the cost of incorrectly relying
> on an revoked
> certificate for some transaction is Y, the value at stake is S and the
> time t since
> the certificate was last validated by CRL or OCSP checking is T, then
> when
> you should/should not revalidate the certificate?
> 
> For answers to these two questions, please check the last messages in
> the thread
> on "Re: Example with sub-attributes, was Re: Attribute certificate
> lifetimes" --
> which provide the context for this thread. See also the first two
> messages in this
> thread, by Bob Jueneman and myself.
> 
> Cheers,
> 
> Ed Gerck
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05651 for ietf-pkix-bks; Wed, 26 May 1999 15:30:33 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA05647 for <[e-mail]>; Wed, 26 May 1999 15:30:31 -0700 (PDT)
Received: from foo.telia.se (t1o68p57.telia.com [62.20.138.57]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id AAA31381; Thu, 27 May 1999 00:32:34 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 27 May 1999 00:31:57 +0200
To: [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Trying again: Unsettled topics, Qualified Certificates.
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom (and Hoyt),

I like the logic in using a policy qualifier.
There has however been raised a number of problems with that. This is mainly:

1) A qualifier can't be marked critical (eventhough I fail to see the
problem with that)
2) RFC 2459 strongly recommends the use of qualifiers should be restricted
to use of 2 defined qualifier types and non of them seams to fit the
reliance limit case. The best one of them is aimed for textual messages and
does not suit automatic processing.

Viewed from issue 2 it doesn't seam that your proposal haromize with the
recommendation in RFC 2459. I.e. Your proposal doesn't fit into the
recommended types.

Do you have any comment to these problems.

/Stefan

At 16:11 1999-05-26 -0400, [e-mail] wrote:
>     At the risk of repeating myself, here is my proposed policy qualifier
>syntax for financial amounts, which could be used for purchase limit whenever
>the specific policy qualifier OID indicates purchase limit:
>
>FinancialAmount     ::=  SEQUENCE
>{    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
>     currency  PrintableString,               -- e.g. "USD" for U.S. Dollar
>     CHOICE    {
>          amount         NumericString,       -- usually including a decimal
>point
>          value          INTEGER         -- no need for floating-point
>     }
>}
>
>     It would be perfectly reasonable to define "currency" as:
>     currency  CHOICE    {
>          currencyName        PrintableString,     -- e.g. "USD" for U.S. 
>Dollar
>          currencyID          Currency   -- integer from ISO 4217
>     }
>
>     with Currency defined as in the Novell proposal, copied below:
>
>Currency ::= INTEGER (1..999) -- currency denomination from ISO 4217
>-- US Dollar (USD) is  840.
>-- Euro (EUR) is 978.
>
>          Tom Gindin



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05596 for ietf-pkix-bks; Wed, 26 May 1999 15:24:27 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA05592 for <[e-mail]>; Wed, 26 May 1999 15:24:24 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id KAA13265; Thu, 27 May 1999 10:22:14 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92775733402111>; Thu, 27 May 1999 10:22:14 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Trying again: Unsettled topics, Qualified Certificates.
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 27 May 1999 10:22:14 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

>At the risk of repeating myself, here is my proposed policy qualifier
>syntax for financial amounts, which could be used for purchase limit 
>whenever the specific policy qualifier OID indicates purchase limit:
>
>FinancialAmount     ::=  SEQUENCE
>{    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,

Is there any reason for having that field (both the field as a whole,
and the weird tagging)?

>    currency  PrintableString,          -- e.g. "USD" for U.S. Dollar
>    CHOICE    {
>         amount         NumericString,  -- usually including a decimal point
>         value          INTEGER         -- no need for floating-point
>     }

Although a particular "feature" of the ANSI/SET monetary amount encoding 
method rates a comment in the style guide (see the bit at the end of the 
message), it does represent a well-established way of doing this so I don't 
think it's a good idea to invent an incompatible new way when there's already 
an existing way to do it.

Peter.

Extract from the style guide:

>Although the
>ANSI/SET provision for handling currencies which may be present in amounts
>greater than 10e300 (requiring the amtExp10 field to extend the range of the
>ASN.1 INTEGER in the amount field) is laudable, it leads to nondeterministic
>encodings in which a single value can be represented in a multitude of ways,
>making it impossible to produce a guaranteed, repeatable encoding.

(Yes, I'm aware of the rationale for it, but it could have been done better).




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05423 for ietf-pkix-bks; Wed, 26 May 1999 15:03:17 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA05419 for <[e-mail]>; Wed, 26 May 1999 15:03:15 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA18759; Wed, 26 May 1999 18:02:59 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a13b372163bc212@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a04b3709e767a28@[128.89.0.110]>
Date: Wed, 26 May 1999 17:56:17 -0400
To: Ed Gerck <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed,

>Actually, if you want to bind X to an identity cert the only secure way is
>via that cert's hash as a whole, not the public-key hash.  In fact, the cert
>hash is not simply the only unique reference that you can rely on for that
>identity cert, but also one which (by extension from the cert) already
>includes a revocation mechanism (CRL or OCSP) and possibly also
>insurance or derived warranties (via CA CPS).

Interesting point.  If one wants to ensure that the whole context of the
identity cert is bound to the AC then you are right.  That is the most
conservative, and probably the most secure appraoch.  There might be
occasions where I don't want so tight a binding, and where just the key
would be OK, which does have a more SPKI-like flavor.  The other extreme is
linkage via the subjecvt name, which is more flexible, but also more
dangerous in some contexts, as other have pointed out.

>I note that the cert hash has been suggested as an intrinsic DN two years
>ago [Ger97a], which can be entirely locally defined and with a local
>decision tree that allows its local reconstruction at any time -- yet globally
>unambiguous.

Cert hashes are not, IMNSHO, a good ID form. For example, they don't admit
to easy searching over a distributed set of databases, unlike
tree-structured names, e.g., DNs or DNS names, or IP addresses. It's not
enough to make an ID globally unique.

>Of course, if you want to bind X to a public-key then you are justified to
>do what you mentioned. But,  the CRL-authority for that public-key
>cannot be securely defined neither by the keyholder nor by delegation
>to the identity cert issuer -- which is a serious security fault. Besides, you
>would lack insurance and other warranties which can be directly derived
>by extension from the cert -- since no cert is named.

A common model for use of ACs is that they are issued by an authority for
later presentation to an access controller for resources controlled within
the same domain as the issuing authority.  Under than model, it is unlikely
that the trace back to a specific cert (in case multiple certs hold the
same public key) is really a problem.  Also, since the authority that
issued the AC would have had access to the identity cert as part of the
issuance process, it can always keep a copy in an audit trail for later
matching to the specific cert against which the AC was issued, if a dispute
arises.

>> Look at the draft profile for attribute certs recently published by Stephen
>> Farrell and it's easy to locate the key hash as pointer.  The real
>> difference here is that X.509 believes that certs with public keys should
>> contain a name that is not purely a local matter.
>
>This is not correct, though a common misconception and unfortunately often
>so cited in some SPKI  documents. Let me divide the issue in three parts:
>
>1. Section 3.3.3 of X.509v3 defines a certificate as: "user certificate;
>public key certificate; certificate:  The public keys of a user, together
>with some other information, rendered unforgeable by encipherment
>with the private key of the certification authority which issued it.". But,
>what is "some other information"?
>
>2. Section 11.2 of X.509v3, "Management of certificates", states that
>the certificate allows an association between a name called "unique
>distinguished name" or DN for the user and the user's public-key:
>"A  certificate  associates  the public key and unique distinguished
>name of the user it describes.", while Section 7 explains that such
>DNs are essential to the security design of X.509: "Authentication
>relies on each user possessing a unique distinguished name." But,
>how are such DNs assigned? Where are they unique? Locally,
>globally?
>
>3. The DN is denoted by a NA (Naming Authority) and accepted by a
>CA (Certification Authority) as unique within the CA's domain, where
>the CA can double as a NA. It is interesting to note that the same user
>can have different DNs in different CAs, or can use the same DN in
>different CAs even if it is not the first one to use it in a CA -- so
>different
>DNs for different CAs do not necessarily mean different users and vice-
>versa.  Further, a DN does not have to contain the user's real-world
>name or location. Thus, semantically, the CA certificate refers to a name;
>however it does not denote it.
>
>Thus,  these three points deny the affirmation that a X.509 name is "not
>purely a local matter" -- yes it is since the CA is local, but it could
>nonetheless *also* have a global significance (for example, if that name
>correctly dials a fully-qualified phone number).
>
>However, there is one more point in X.509 which can be interesting here,
>regarding the validation of such DNs -- which is also *local* to the CA,
>not global at all and also not necessarily auditable:

Nice analysis, but it ignores the context in which X.509 exists, i.e., the
X.500 directory model.  People do issue X.509 certs with subject and issuer
names that may not be globally unique, but that was not the context in
which cert issuance was envisioned.  I don't worry too much about folks
issuing certs with names that are unique local to a CA context, as you
observe, so long as they understand the possible adverse implications of
such.  Given the lack of a global X.500 directory, I usually advise folks
to stick with name spaces that do have global uniqueness and some extant
authority for managing the name space, e.g., the DNS, or to construct a
purely local system.


>4. X.509 is moot on validation procedures for data included in a certificate
>such as the user's name, with the exception of validation procedures for the
>user's public-key which are suggested (not mandated) in Section 10 of
>X.509v3. For example, regarding validation procedures for the user's
>identity, Section 11.2.a states that: "a certification authority shall be
>satisfied of the identity of a user before creating a certificate for it",
>which
>means that identity validation procedures are to be satisfied in the CA's
>frame of reference by following the CA's own self-defined rules (called CPS),
>which are declared outside the scope of X.509 and can be entirely different
>for different CAs. Further, all public CA's CPSs accept indirect references
>of "trust" when issuing certificates, which is a security risk that could
>only be
>acessed by  auditing, to verify the procedures used to accept an ID for
>example
>-- but, auditing is not possible with today's CPS and X.509 is also moot
>on such
>requirement.
>
>Thus, X.509 focuses on defining a mechanism by which information can be made
>available in a secure way to a third-party. However, X.509 does not intend to
>address the level of effort which is needed to validate the information in
>a certificate
>neither define a *global* meaning to that information outside the CA's
>management
>acts.

Of course X.509 does not establish the criteria that a CA will employ for
authenticating the right of an EE to use the subject name.  That is a local
policy matter, even for globaly names.

>In legal reliance terms, one may trust the DN confirmation procedures of
>the CA
>during certificate reliance, but one cannot rely upon them for other than
>their value
>as a representation of the CA's authentication management act expressed in the
>CA's own terms and rules (CPS) -- therefore, a DN in a X.509 certificate
>is *by
>X.509 definition* a purely local matter (local to the CA and its CPS) even if
>X.500 global directories were used (X.509v3, Section 11.2). Of course, if
>the US
>INS accepts (rather, "uses") UK birth certificates in order to issue residence
>permits to the US, this does not mean that the INS is declaring that such
>birth
>certificates are valid in the UK. So, the eventual use by a CA of a DN
>supplied
>by a X.500 directory does not mean that the CA is declaring that such DN is
>global.

To expand on your example, when the US issues a passport, it states that
the named individual is a citizen of the US and that the name represented
in the passport is a legal name for the passport holder (the later binding
established via the photo).  If one were to issue an electronic passport,
the DN for the passport holder probably would include the passport number
as a component of the terminal RDN. to ensure uniqueness in the space for
which the US Dept of State is authoritative.

>Here, in PKIX, the main purpose of a CA is also to bind a public key to
>the name
>contained in the certificate and thus assure third parties that some
>measure of care
>was taken to ensure that this binding is valid for both -- i.e., name and
>key. However,
>the issue whether a user's DN actually corresponds to identity credentials
>that are
>*globally* linked to a person, or to a local alias or, simply to an e-mail
>address -- and
>how such association was verified --   is also outside the scope of PKIX
>and depends
>on each CA's CPS.

Yes, the means fo verification is a CPS issue, but also don't get too hung
up on DNs, per se.  PKIX encourages use of altName forms suitable to the
Internet environment, where global uniqueness is a reasonable presumption.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA05251 for ietf-pkix-bks; Wed, 26 May 1999 14:35:49 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05247 for <[e-mail]>; Wed, 26 May 1999 14:35:47 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id QAA16921; Wed, 26 May 1999 16:34:51 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id QAA19740; Wed, 26 May 1999 16:34:50 -0500 (CDT)
Message-ID: <028001bea7bf$eec606e0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Graham Klyne" <[e-mail]>
Cc: "PKIX" <[e-mail]>
Subject: Re: General formula, was Re: Attribute certificate lifetimes:way too much  math, but getting closer to correct
Date: Wed, 26 May 1999 16:37:19 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_027D_01BEA796.05ACDB60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_027D_01BEA796.05ACDB60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

Here's the other source of apparent disagreement: you're using the word
"lifetime" in a way
I consider unnatural, and it may strike others oddly also:

>> >I disagree. And, there are billions of counter-examples. For example,
>> >if men's biological lifetime is 70 years this does not mean that all men
>> >were born at the same time -- and yet they all have the same lifetime.


The word normally used in English to capture this concept is lifeSPAN, not
lifeTIME.
"The span of a man's years is threescore and ten", etc....

If I'm lucky, I will have the same lifespan (102 years) as my
great-grandmother, but
it's already too late for us to have the same lifetime.  In the course of her
lifetime,
Soviet communism rose and fell, there were two world wars, the United States
was
electrified, private automobiles came into use, refrigeration and then
air-conditioning
became common, homes got telephones, radio and then television became popular,
and so on.

These usages are completely natural, but using lifetime to designate the
length of
the interval but NOT (also) its origin is not common.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_027D_01BEA796.05ACDB60
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990526T213719Z
END:VCARD

------=_NextPart_000_027D_01BEA796.05ACDB60--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA05200 for ietf-pkix-bks; Wed, 26 May 1999 14:26:28 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05196 for <[e-mail]>; Wed, 26 May 1999 14:26:26 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id QAA16913; Wed, 26 May 1999 16:25:30 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id QAA19728; Wed, 26 May 1999 16:25:28 -0500 (CDT)
Message-ID: <026d01bea7be$a0166680$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Graham Klyne" <[e-mail]>
Cc: "PKIX" <[e-mail]>
Subject: Re: General formula
Date: Wed, 26 May 1999 16:27:58 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_026A_01BEA794.B6FD3B00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_026A_01BEA794.B6FD3B00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

>Wait -- this is NOT the issue here. Bob Blakley wrote that equal lifetimes
>would indicate a "property" -- that the corresponding attributes would
>actually be dependent or at least have a tendency to be dependent. I replied
>negatively -- such property or tendency does NOT exist. Lifetime distance
>does not correlate with attribute independency -- much in the same way that
>a pointer's value (lifetime) does not correlate with a pointer's address
(attribute).
>They are two entirely different concepts, not only different values. Thus,
the fact
>that the lifetimes are equal or even similar for two attributes does not
authorize
>me to say anything about the attributes' dependencies.

This may be the source of our apparent disagreement -- I say apparent because
it does not now and has not yet appeared to me that we actually disagree
on anything of substance.

I did NOT write that equal lifetimes indicate a property.  What I *did* write
is that
there are many real-world cases where there is *either* exact equivalence of
lifetimes because of dependence, or dependence without exact equivalence
of lifetimes.  I gave an example of the former.  I noted that your formula
does
not *and is not intended* to cover these cases if you treat the dependent
attributes as separate and plug their lifetimes into the formula as if they
were
independent.  I don't think you disagree with any of this, nor do I think any
of this
contradicts the claims you are making for the forumula in cases where its
premises are satisfied.

In this sense, the formula is not "general" in the sense that gravitation is
"universal".
It covers a wide variety of situations, but not every situation which has been
observed in the real world at the appropriate level of abstraction.
--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_000_026A_01BEA794.B6FD3B00
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990526T212757Z
END:VCARD

------=_NextPart_000_026A_01BEA794.B6FD3B00--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA04611 for ietf-pkix-bks; Wed, 26 May 1999 13:08:55 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA04607 for <[e-mail]>; Wed, 26 May 1999 13:08:54 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA16290; Wed, 26 May 1999 13:06:17 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 26 May 1999 15:55:48 -0400
To: Anders Rundgren <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Unsettled topics, Qualified Certificates.
Cc: PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
In-Reply-To: <01BEA6D5.0E476F40@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In my view, maximum value per transaction is a good candidate for an
attribute certificate.

Russ


At 05:35 PM 5/25/99 +0200, Anders Rundgren wrote:
>Stefan,
>
><snip>
>>Issue 2) Storage of maximum value per transaction.
>
>>The directive requires that a certificate, if applicable, shall contain
>>information about a maximum monetary amount per transaction that the
>>certificate should support. 
>
>My comment to this is that the EU directive seems to try to solve all 
>business problems with
>certificates.  This is IMO a bad idea and will only delay things.
>
>Let's say that you open a door with a cert.  How can you possibly say how 
>much value you have behind the door?
>
>And what is the true value of a signed business contract?
>
>For monetary transactions it is up to the relying party (the bank, the 
>selling organization) to
>set proper limits and to your organization as well.  To do this in a static 
>certificate
>(probably issued by a TTP) is lunacy.
>
>>This could be done by defining a new extension (like the Germans already
>>have done in their interoperability specifications), or alternatively just
>>say that this shall be solved by a certificate policy, possibly in
>>combination with a policy qualifier.
>
>Certificate policy could specify liability but that does not have anything 
>to do
>with the sums you transact or protect.
>
>>Arguments has been raised that Policy qualifiers are not suitable for
>>automatic interpretation but that is not confirmed.
>
>Of course you can have any number of optional items but if people start to
>actually use them you will pretty soon run into severe problems.
>
>So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep some 
>people happy) but 
>just IGNORE them in real implementations.  This is the proper (only) way to 
>handle EU bureaucracy :-)  :-)
>
>Anders Rundgren
>http://www.mobilephones-tng.com
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA04596 for ietf-pkix-bks; Wed, 26 May 1999 13:07:30 -0700 (PDT)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA04592 for <[e-mail]>; Wed, 26 May 1999 13:07:24 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp7.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id QAA25658; Wed, 26 May 1999 16:08:17 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id QAA244924; Wed, 26 May 1999 16:07:32 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525677D.006E857E ; Wed, 26 May 1999 16:07:11 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 May 1999 16:11:10 -0400
Subject: Re: Trying again: Unsettled topics, Qualified Certificates.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     At the risk of repeating myself, here is my proposed policy qualifier
syntax for financial amounts, which could be used for purchase limit whenever
the specific policy qualifier OID indicates purchase limit:

FinancialAmount     ::=  SEQUENCE
{    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
     currency  PrintableString,               -- e.g. "USD" for U.S. Dollar
     CHOICE    {
          amount         NumericString,       -- usually including a decimal
point
          value          INTEGER         -- no need for floating-point
     }
}

     It would be perfectly reasonable to define "currency" as:
     currency  CHOICE    {
          currencyName        PrintableString,     -- e.g. "USD" for U.S. Dollar
          currencyID          Currency   -- integer from ISO 4217
     }

     with Currency defined as in the Novell proposal, copied below:

Currency ::= INTEGER (1..999) -- currency denomination from ISO 4217
-- US Dollar (USD) is  840.
-- Euro (EUR) is 978.

          Tom Gindin




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA04133 for ietf-pkix-bks; Wed, 26 May 1999 12:17:46 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA04129 for <[e-mail]>; Wed, 26 May 1999 12:17:44 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 0725677D.0069CC3F ; Wed, 26 May 1999 12:15:35 -0700
X-Lotus-FromDomain: BULL
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 May 1999 12:08:00 -0700
Subject: Re: Trying again: Unsettled topics, Qualified Certificates.
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=g2VGFqLd44gVPSa2oEE9d18aYZJDIm2D1U7Unrwqw1mfhn9h3eUykTHH"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=g2VGFqLd44gVPSa2oEE9d18aYZJDIm2D1U7Unrwqw1mfhn9h3eUykTHH
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



i apologize for the breadth of my response. i just wanted to make clear
that policy qualifier is a possible candidate for your requirement but i
got carried away and addressed all the points in the email.

i don't care if you choose to do an extension as long as that does not
restrict a policy being defined where such constraints more tailored to
that policy could be defined in policy qualifier. of course the policy
could specify that the extension be present and be followed.

i do have one  concern. what if the limit is different for different types
of transactions, e.g. the liquidity of the asset being acquired may effect
the limit - i can agree to rent a $1000 a month apartment but i can't buy a
$1000 diamond?

i don't like the use of printable string in the german version. it seems
difficult to constrain the possibilities. the currency flag in the novell
proposal seems a better choice (although it should be ENUMERATED not
INTEGER)

   hoyt




Stefan Santesson <[e-mail]> on 05/26/99 12:44:08 AM

To:   PKIX <[e-mail]>
cc:    (bcc: Hoyt Kesterson/US/BULL)
Subject:  Trying again: Unsettled topics, Qualified Certificates.



--0__=g2VGFqLd44gVPSa2oEE9d18aYZJDIm2D1U7Unrwqw1mfhn9h3eUykTHH
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



Gentlemen,

Please stick to the subject. If you want to argue pro or against the
EU-directive, then I suggest you direct that to the EU-commission.

I want suggestions and comments on the discussed techniques and that is=
:

1) Should we add a recommendation to include explaining text in commonN=
ame
when storing a pseudonym name

2) Should we use policy qualifiers or a new extension to specify a maxi=
mum
reliance limit.

We have to solve these issues and now is the chance to influence the
outcome of this.
I would also like to present 2 different proposals on extensions for
reliance limits.


Proposal 1 from Germany PKI specifications:

monetaryLimit  EXTENSION ::=3D {
SYNTAX    MonetaryLimitSyntax
IDENTIFIED BY  id-sigi-at-monetaryLimit }
id-sigi-at-monetaryLimit OBJECT IDENTIFIER    ::=3D {1 3 36 8 3 4}
MonetaryLimitSyntax ::=3D  SEQUENCE {
  currency     PrintableString (SIZE(3)),
  amount  INTEGER,
  exponent     INTEGER }


Proposal 2 from Bob Juneman, Novell:

RelianceLimits ::=3D SEQUENCE   {
               perTransactionLimit       MonetaryValue,
               perCertificateLimit MonetaryValue }

          MonetaryValue ::=3D SEQUENCE {  -- from SET and draft ANSI X9=
.45
                    currency Currency,
                    amount INTEGER,
                    amtExp10 INTEGER}
                         -- value is amount * (10** amtExp1),
                         -- an exact representation

          Currency ::=3D INTEGER (1..999)
               -- currency denomination from ISO 4217
               -- US Dollar (USD) is  840.
               -- Euro (EUR) is 978.



My personal suggestion to issue 1 and 2 are:
Issue 1 - Do nothing (no explaining text in commonName)
Issue 2 - Define an optional extension according to the German proposal=
 (I
don't like two different values according to the Novell proposal. It ad=
ds
to much confusion).

But this can change.

/Stefan


At 10:52 AM 5/25/99 -0700, [e-mail] wrote:
>
>
>i disagree entirely with your statement that "Certificate policy could=

>specify liability but that does not have anything to do with the sums =
you
>transact or protect." certificates state how they are to be used. key
usage
>is a simplified statement of the constraint on a certificate's use. th=
e
>certificate's policy also describes how the certificate is to be used =
and
>allows that description to be more precise than key usage. (when this
stuff
>was being defined, i argued that we did not need key usage but a set o=
f
>standardized policies instead. the others agreed in concept but felt k=
ey
>usage would be more readily deployable in the start-up phase. )
>
>
>
>certificate policy is intended to control the use to which a certifica=
te
>can be put. liability issues are a strong factor in determining that
>constraint but liability need not be specified in the cp. i suspect th=
at
>you may be confused about the difference between cp and cps
>
>
>
>i don't understand your statement "Of course you can have any number o=
f
>optional items but if people start to actually use them you will prett=
y
>soon run into severe problems." qualifiers are associated with a speci=
fic
>policy. if an implementation (or a human user), understands the policy=
, it
>must understand the qualifiers that are associated with that policy. i=

>agree that a policy with a large number of qualifiers and complex
>interworking may be difficult to deploy, but not more difficult than
>supporting the large number of policies each of which embody the one o=
f
the
>combinations of qualifiers and qualifier values within the policy itse=
lf.
>
>
>
>on your recommendation to "ignore", i think such implementors would ha=
ve a
>difficult day in court when being questioned about the conformance of
their
>product to the accepted business practice. i believe that the courts w=
ould
>consider EU regulation as a strong guideline to the acceptable busines=
s
>practice.
>
>Where law and technology intersect, the engineers "yes/no" view must a=
dapt
>to the court's "maybe" view. the policies and guidelines may not be
perfect
>and they are sure to be refined by case law. but i would like to have =
as
>good a technological stake in the ground as possible rather than havin=
g
>some judge start with a blank page when determining the acceptablity o=
f a
>digital signature.
>
>     hoyt
>
>
>
>
>
>Anders Rundgren <[e-mail]> on 05/25/99 08:35:59 AM
>
>To:   PKIX <[e-mail]>, "'Stefan Santesson'" <stefan@accurata.=
se>
>cc:    (bcc: Hoyt Kesterson/US/BULL)
>Subject:  RE: Unsettled topics, Qualified Certificates.
>
>
>
>
>Stefan,
>
><snip>
>>Issue 2) Storage of maximum value per transaction.
>
>>The directive requires that a certificate, if applicable, shall conta=
in
>>information about a maximum monetary amount per transaction that the
>>certificate should support.
>
>My comment to this is that the EU directive seems to try to solve all
>business problems with
>certificates.  This is IMO a bad idea and will only delay things.
>
>Let's say that you open a door with a cert.  How can you possibly say =
how
>much value you have behind the door?
>
>And what is the true value of a signed business contract?
>
>For monetary transactions it is up to the relying party (the bank, the=

>selling organization) to
>set proper limits and to your organization as well.  To do this in a
static
>certificate
>(probably issued by a TTP) is lunacy.
>
>>This could be done by defining a new extension (like the Germans alre=
ady
>>have done in their interoperability specifications), or alternatively=

just
>>say that this shall be solved by a certificate policy, possibly in
>>combination with a policy qualifier.
>
>Certificate policy could specify liability but that does not have anyt=
hing
>to do
>with the sums you transact or protect.
>
>>Arguments has been raised that Policy qualifiers are not suitable for=

>>automatic interpretation but that is not confirmed.
>
>Of course you can have any number of optional items but if people star=
t to
>actually use them you will pretty soon run into severe problems.
>
>So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep so=
me
>people happy) but
>just IGNORE them in real implementations.  This is the proper (only) w=
ay
to
>handle EU bureaucracy :-)  :-)
>
>Anders Rundgren
>http://www.mobilephones-tng.com
>
>
>
>

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systems=E4kerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]
211 20  Malm=F6                   Fax. [phone]
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


=

--0__=g2VGFqLd44gVPSa2oEE9d18aYZJDIm2D1U7Unrwqw1mfhn9h3eUykTHH--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03926 for ietf-pkix-bks; Wed, 26 May 1999 11:53:09 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03922 for <[e-mail]>; Wed, 26 May 1999 11:53:08 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id NAA16509; Wed, 26 May 1999 13:51:59 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id NAA19317; Wed, 26 May 1999 13:51:57 -0500 (CDT)
Message-ID: <00b501bea7a9$2dc5c540$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, "Ed Gerck" <[e-mail]>, "Linn, John" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Certificate life-cycle costs.
Date: Wed, 26 May 1999 13:54:26 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B2_01BEA77F.44BD62A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00B2_01BEA77F.44BD62A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Bob,


>Before we propagate yet another urban myth, that certificate revocation
>is expensive, we ought to at least quantify that "fact".  Then we can
>decide the merits of alternative approaches.


Good advice...

>Seems to me that whatever the costs are (and I don't have ANY
>quantitative data) are made up of multiple factors:  (1) The R-P's cost
>of 
>status checking, especially status checking that returns an "all is
>well" message for the umpteenth time.  (2) The cost of running the 
>server CA or repository) that provides the status, whether CRLS or 
>OCSP, (3) the human cost of actually doing the revocation,
>(4) the human/system cost of deciding what to do about the
>revoked certificate and/or transaction, (5) the cost of reissuing 
>new certificates.


All clearly right.

>Clearly, if one of the larger components of "revocation" is really the
>cost of issuing replacement certs, then decreasing certificate
>lifetimes won't help.
>
>What would probably help more would be considerably finer 
>granularity in the response as to the reason for the revocation,
>especially of the more benign cases where the entity is still
>with the company, the key has not be compromised, and all 
>that changes is her name, or OU.


I think this is a really important point, since probably 90% of all
revocations will have the reason code "forgot password for private key".
However, be careful what you wish for.  If you have lots of reason codes,
you have really complicated policy at the relying party.  Which
means that you either have to present decisions to the user ("just say
yes"!) or you have really complicated code, which may be liable to 
bugs, subtle forms of fraud, etc...


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_00B2_01BEA77F.44BD62A0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990526T185426Z
END:VCARD

------=_NextPart_000_00B2_01BEA77F.44BD62A0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02682 for ietf-pkix-bks; Wed, 26 May 1999 10:04:25 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02678 for <[e-mail]>; Wed, 26 May 1999 10:04:24 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id KAA08044; Wed, 26 May 1999 10:03:43 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id KAA20828; Wed, 26 May 1999 10:04:38 -0700 (PDT)
From: "Peter Williams" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Date: Wed, 26 May 1999 10:11:38 -0500
Message-ID: <007501bea78a$0da3da00$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of David P. Kemp
> Sent: Tuesday, May 25, 1999 9:59 AM
> To: [e-mail]; [e-mail]
> Subject: RE: X.509 ACs vs. SPKI?
> 
> 
> > From: "Ellison, Carl M" <[e-mail]>
> > 
> > Perhaps I used the wrong word.  The fact remains that the code that
> > interprets a full X.509 certificate (including all extensions) needs
> > to be aware of (to embody) the definitions found in some paper
> > document.  This is by contrast with SPKI certificates that can be
> > processed through tuple-reduction without any special knowledge about
> > such paper documents.  That is why SPKI can have a single Trust Policy
> > engine while X.509 requires a different one for each application (in
> > the limit, for each root key).
> 
> There are only two places that the policy written in a paper document
> can be understood/interpreted/enforced - in applications and in the
> user's brain.  To the extent that application engines perform automated
> reduction, the user's workload (and ability to make mistakes) is
> reduced.

This is a not how commercial trust works - I do respect that
your model fits classical military centralized
key management thinking, however.

In the commercial world, auditors have primacy over
contractor folks like VeriSign. That KPMG gives a representation
to VeriSign clients' auditors, concerning VeriSign
policy and veriSign's adherence to its own rules, is
what matters.

Whether KPMG is qualified to make such representation
is of course for the client to judge. In general,
the simple financial responsibility of KPMG - when making
meta-statements about the policies of others - is what will
drive the client.

I see a world emerging fast where the likes of KPMG issue
the (indirect) CRLs/OCSP responses/X509 ACs, given VeriSign 
manufacturers and issues id-certs.  KPMG qualifies the certs 
status as above, and thereby continues to assert its 
representations about VeriSign policy compliance.

So, rather than issuing and revoking a cross-certificate, or 
a Root Registry certificate, etc,. KPMG's policy adherence group 
qualify the cert status msgs. The relying  party is better 
protected; and it works today!. KPMG can use the outsourcing 
services of branded PKI players like DST - Digital Signature Trust,  
perhaps...



Caveat: Use of KPMG and VeriSign as players in the denovo 
PKI world are example well-known names, merely. One could 
substitute using NSA and DoD, VISA and its members, or Bank 
of England and BCCI, similarly. Almost all service industries 
have these relationships already in place... with natural 
policy-regulators and suborned providers.


> 
> Claiming that SPKI "can have" a single engine while X.509 "requires" a
> different one for each root is one way of spinning it. But I would say
> SPKI permits only a single engine, whereas X.509, which defines no
> authorization mechanism itself, provides extensions identified by OIDs
> which can select the engine to be used.  Automated authorization is not
> a mature field; there are numerous candidates:  NIST's Role Based
> Access Control, SPKI tuples, Novell's Security Attributes, the DoD's
> SDN.801, and many others.  In 10 years, perhaps everyone will agree
> that SPKI tuple-reduction is a suitable mechanism for automated
> authorization decisions, and everyone's X.509 root cert will have an
> extension that specifies an SPKI tuple reduction engine in conjunction
> with some application-domain-specific parameters.
> 
> As for human-interpreted policy processing, one size will never fit
> all.  VeriSign has 4 public assurance classes, the U.S. DoD defines 5
> classes although only 2 are presently used, and other governments and
> organizations have multiple CPs.  Harmonization (and elimination of
> policy mapping) would be great, but it won't happen quickly, if ever.
> Policy Qualifiers can be used to advertise quantitative information
> such as Reliance Limits from the issuer to the RP, but if the intent is
> automated processing rather than simply displaying information to the
> user, I believe a different extension, specifying a "standard engine"
> should be used.  The fewer engines applications have to support, the
> better, but I don't think the market is yet convinced that SPKI tuples
> are capable of supplanting RBAC, DoD PRBAC/LRBAC, other chaining
> mechanisms, and plain old ACLs for all public-key-based authorization
> applications.
> 
> That is why X.509 allows a choice of engines, including "display this
> to the user", messy though the choice may be.
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02622 for ietf-pkix-bks; Wed, 26 May 1999 10:02:40 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA02617 for <[e-mail]>; Wed, 26 May 1999 10:02:39 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 26 May 1999 11:02:47 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 26 May 1999 11:02:28 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Certificate life-cycle costs.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA02618
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Before we propagate yet another urban myth, that certificate revocation 
is expensive, we ought to at least quantify that "fact".  Then we can
decide the merits of alternative approaches.

Seems to me that whatever the costs are (and I don't have ANY
quantitative data) are made up of multiple factors:  (1) The R-P's cost of 
status checking, especially status checking that returns an "all is
well" message for the umpteenth time.  (2) The cost of running the 
server CA or repository) that provides the status, whether CRLS or 
OCSP, (3) the human cost of actually doing the revocation,
(4) the human/system cost of deciding what to do about the
revoked certificate and/or transaction, (5) the cost of reissuing 
new certificates.

Clearly, if one of the larger components of "revocation" is really the
cost of issuing replacement certs, then decreasing certificate
lifetimes won't help.

What would probably help more would be considerably finer 
granularity in the response as to the reason for the revocation,
especially of the more benign cases where the entity is still
with the company, the key has not be compromised, and all 
that changes is her name, or OU.

Bob (Jueneman)



>>> "Bob Blakley" <[e-mail]> 05/21/99 02:00PM >>>
John Linn writes

>It strikes me that some consideration of high costs of revocation in PKI
>systems, with a strong attendant goal of minimizing the proportion of
>certificates revoked before their validity expires, has derived from the
>traditional premise of CRL-based revocation. OCSP-based revocation may
>motivate different analysis; if the backing store behind an OCSP responder
>is a non-CRL database describing the status of issued certificates,
>revocation doesn't incur the incremental costs of generating, propagating,
>and maintaining growing CRLs.

This is undoubtedly true, ...

>If CRL management costs are removed, it may
>become reasonable to accept more statistically frequent revocation in order
>to gain the information value of additional certified attributes.

but this really depends on the environment.  Everyone is familiar with the
usual explanation given for the popularity of smartcards in Europe, namely
that the telco infrastructure is so expensive to use that merchants can't
afford
to do online credit-card status verification, so there's value in assigning
this
function to a dialog between the merchant and the card itself.

I don't actually know how much truth there is in this explanation, but I *do*
know
that the economics of online verification are different in Europe and the USA.

I think the high costs of revocation come from several different sources:

(1) The cost to the issuer of actually KNOWING what the correct status of
        a certificate is, and

(2) The cost to the issuer of distributing status information

(3) The cost to the relying party of consulting status information

#2 is certainly different in OCSP vs. CRL configurations; Some constituent
of #3 is also different, but some of the processing is the same for OCSP as
for
CRLs.

#1 is the same in both configurations.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA02512 for ietf-pkix-bks; Wed, 26 May 1999 09:57:59 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA02508 for <[e-mail]>; Wed, 26 May 1999 09:57:57 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA17279; Wed, 26 May 1999 18:58:39 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 26 May 1999 18:58:38 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA23231; Wed, 26 May 1999 18:58:37 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA23721; Wed, 26 May 1999 18:58:37 +0200
Date: Wed, 26 May 1999 18:58:37 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Comments on time-stamp-01: Identification of TSA
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> First, the protocol uses a CMS SignedData object as the basic form of
> the time-stamp token.  This object allows identification of the signer
> in the SignerInfo section.  This data is sufficient to locate the
> correct certificate, build the chain and validate TSA's identity.  This
> should be the primary (and possibly only) method of identifying the TSA
> that generated the token.  However, the current draft goes on to mention
> several other identification fields.
No: The data are NOT sufficient to locate the correct certificate.

You just define a NEW protocol that requires POP to be done elsewhere
than during signature validation of the document.

The ESS signing cert is a possibility to avoid that 
thus to respond to the problem mentioned in rfc2510: 

   policy issue).  However, it is REQUIRED that CAs/RAs MUST enforce POP
   by some means because there are currently many non-PKIX operational
   protocols in use (various electronic mail protocols are one example)
   that do not explicitly check the binding between the end entity and
   the private key.  Until operational protocols that do verify the
   binding (for signature, encryption, and key agreement key pairs)
   exist, and are ubiquitous, this binding can only be assumed to have
   been verified by the CA/RA. Therefore, if the binding is not verified
   by the CA/RA, certificates in the Internet Public-Key Infrastructure
   end up being somewhat less meaningful.
> 
> The draft contains the following text:
> 
>      The purpose of the tsa field is to identify the name of the
>      TSA.  If present, it MUST correspond to one of the subject
>      names included in the certificate that is to be used to verify
>      the token.  This field MAY be omitted if the Signing
>      Certificate Attribute has been included as a signed
>      attribute.  (See Section 5 of [ESS].) It MUST be present if
>      the ESSCertID Attribute is not used to identify the TSA.
> 
> 'tsa' is an optional GeneralName field defined within the TSTInfo
> sequence.  Because it is optional, it cannot be relied upon to locate
> the proper certificate needed to verify the token.  It may be useful to
> locate the certificate if a verifier files certificates using values
> other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
> TSA would need to know what other types of GeneralName might be useful
> to a client.  The 'tsa' field does have one difference from the
> SignerInfo fields - it is signed with the message.  This has some
> significance for some attacks on the protocol, which I'll discuss later.
The text clearly indicates that ONE of the optional possibilities MUST
be used for identification. A tsa that does not fill in neither the 'tsa'
neither the signing cert attribute would not be conformant.  
Policy in the TSTInfo should also be optional, since it can also be
filled in using the signing cert attribute. 

Whether it would be required to fill in a policy in at least one of
the fields, I don't care. 

> 
> The 'substitution attack' ([ESS]) is prevented for TSA signatures in two
> ways.  First, the key used for signing time-stamp tokens is required to
> be used only for that purpose.  This means that existence of a second
> certificate (with different capabilities) for the same key is already
> prohibited by the draft.  Second, the token also contains a
> PolicyIdentifier that is effect for the signature.  The verifier must
> check that the certificate chain allows this policy to be used.  This
> requirement prevents a second certificate (with different
> PolicyIdentifier values) from being used to check the signature.  In
> fact, the policy identifiers in the SigningCertificate sequence of [ESS]
> duplicate the value already found in the token.
> 
> Finally, the time-stamping draft expresses concern for attacks that may
> occur when the CA does not perform proof-of-possession checks on the TSA
> key.  To counter these, the draft encourages use of the fields mentioned
> above (including the tsa field, and the SigningCertificate attribute)
> which are included within the token signature.  This prevents a
> substitution attack where the substitute certificate is for an entirely
> different subject name.  However, since other drafts will address these
> attacks during the certificate enrollment process (the CMC draft
> contains proof-of-possession protocol), I think the time-stamp protocol
> should not define its own mechanisms for dealing with the problem.
If you can avoid the requirement for proof of possession in
an operational protocol, then you don't have to address that problem. 

> 
> In summary, there are too many ways to identify the TSA certificate.  We
> should use the basic CMS SignerInfo for this data.  Attacks (as listed
> in [ESS]) Concerns about proof-of-possession flaws should be addressed
> elsewhere, specifically in the certificate request process.

Refering to use the ESS signing cert, concerns about 
proof of possession ARE refered elsewhere. 

The TSA and policy indicator in the text seem to me leftovers from
the time where the ESS signing cert attribute wasn't known. 

The only point that the tsa name inside the TSTinfo can handle is that
you immediately have a name of the TSA. But this seems a rather
weak argument, since in order to verify the integrity of the cert
you probably have access to the cert anyway. 

if one does not want to create another new special way for identification
etc. one might suggest to completely remove the tsa and policy from
the TSTinfo. The current text is a compromise so far.

Peter


 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA02267 for ietf-pkix-bks; Wed, 26 May 1999 09:29:15 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA02263 for <[e-mail]>; Wed, 26 May 1999 09:29:13 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA15656; Wed, 26 May 1999 18:29:51 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 26 May 1999 18:29:51 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA22857; Wed, 26 May 1999 18:29:50 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA23710; Wed, 26 May 1999 18:29:49 +0200
Date: Wed, 26 May 1999 18:29:49 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> My response may have been less-than-clear on two points.  First, the modified
> protocol does NOT contain an error value in the TimestampToken.  Errors are
> limited to the second type of response.  This is very different from the current
> draft, which produces data that "looks" like a token, but is not valid since an
> error value is set within it.
> 
> Second, I intended to describe the changes to the current draft in two phases -
> a protocol that returns tokens or UNauthenticated errors, and then a better
> protocol that provides authentication for the error values (to prevent
> spoofing).  The bullet you refer to is meant to describe the first phase, and is
> what I intended.
> 
> To expand:  this first phase of changes to the current draft protocol could also
> allow the server to quietly discard requests that generate an error.  This might
> be an appropriate response when the service is provided over email, or UDP
> channels.  This possibility also falls in to the realm of unauthenticated
> responses, since there is no verifiable response from the server to indicate the
> request was denied.
Why does the first phase allow to QUIETLY DISCARD a request? It seems to me
that the contrary is the case:

The actual text requires that all responses need to be signed, thus in order
to signal an error condition where no signing is possible, the TSA just does
NOTHING, i.e., quietly discard the request.

The proposed unauthenticated answer provides a mecanism to signal this condition
to the requestor, thus the requesting client MAY stop immediately and call the
support center of the TSA or whatever.

The question is: Is this a desirable service? 

> 
> Also, when the second phase of changes is applied (to add authenticity to the
> errors), you can choose to allow (or require) a different certificate to be used
> to sign the error values.  This is also different than the current proposal.
> I'm not convinced it is necessary since the content-type OID in the SignedData
> will clearly indicate the response is not a real time-stamp token, but some
> people may feel more comfortable signing with a different key (and certificate)
> in this case.
Signing with a different certificate has nothing to do with the format of
the signed message. 

It is a matter of taste how to encode the data. Whether this is done using
a separate content OID (TSTInfo and TSTError), or using a choice inside
the data, is really not that important. 

But there is ONE error situation cannnot be handled nicely with the current
text: If the request is incorrectly encoded, the TSTInfo cannot be created
at all. Since the data of the request are the only way to idenify the
request in an error message (sent via mail for example), it seems to
make sense to have a different structure for signaling errors, something
like a sequence of a pkistatus and an octet string that encapsulates the
request or part of it. 

The question here is what kind of service must be provided by the TSA? 

Summary: The proposed changes seem worth to be discussed, but not 
from a pure standpoint of asn1 encoding. This is a service definition
question (IMHO).


Peter


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00916 for ietf-pkix-bks; Wed, 26 May 1999 07:00:05 -0700 (PDT)
Received: from relay.gw.tislabs.com ([e-mail] [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA00912 for <[e-mail]>; Wed, 26 May 1999 07:00:04 -0700 (PDT)
Received: by relay.gw.tislabs.com; id KAA22736; Wed, 26 May 1999 10:14:41 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1) id xma022720; Wed, 26 May 99 10:14:08 -0400
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.1/8.9.1) id JAA18156 for [e-mail]; Wed, 26 May 1999 09:56:30 -0400 (EDT)
Date: Wed, 26 May 1999 09:56:30 -0400 (EDT)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: REMINDER: CFP: ISOC Year 2000 Netw. & Distr. Sys. Security Symp. (NDSS 2000)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

            C  A  L  L       F  O  R       P  A  P  E  R  S


                          The Internet Society
           Year 2000 Network and Distributed System Security 
                         Symposium (NDSS 2000)

             Catamaran Resort Hotel, San Diego, California
                           February 2-4, 2000


IMPORTANT DATES:

  Paper and panel submissions due: June 16, 1999
  Author notification: August 17, 1999
  Final versions of papers and panels due: October 15, 1999

GOAL: 

  This symposium aims to foster information exchange among researchers
  and practitioners of network and distributed system security
  services.  The intended audience includes those who are interested
  in practical aspects of network and distributed system security,
  with the focus on actual system design and implementation, rather
  than theory. A major goal of the symposium is to encourage and
  enable the Internet community to apply, deploy, and advance the
  state of available security technology.  The proceedings of the
  symposium will be published by the Internet Society.

  Submissions are solicited for, but are not limited to, the
  following topics:

  * Secure Electronic Commerce, e.g., payment, barter, EDI,
    notarization/timestamping, endorsement and licensing.
  * Intellectual Property Protection: protocols, schemas,
    implementations, metering, watermarking, other forms of rights
    management.
  * Implementation, deployment and management of network security
    policies.
  * Integrating Security in Internet protocols: routing, naming,
    TCP/IP, multicast, network management, and, of course, the Web.
  * Attack-resistant protocols and services.
  * Special problems and case studies: e.g. interplay and tradeoffs
    between security and efficiency, usability, reliability and cost.
  * Security for collaborative applications and services: tele- and
    video-conferencing, groupwork, etc.
  * Fundamental services: authentication, data integrity,
    confidentiality, authorization, non-repudiation, and availability.
  * Supporting mechanisms and APIs: key management and certification,
    revocation, audit trails and accountability.
  * Integrating security services with system and application security
    facilities and protocols, e.g., message handling, file
    transport/access, directories, time synchronization, data base
    management, boot services, mobile computing.
  * Security for emerging technologies -- sensor networks, specialized
    testbeds, wireless/mobile (and ad hoc) networks, personal
    communication systems, and large heterogeneous distributed systems.
  * Intrusion Avoidance, Detection, and Response: systems, experiences
    and architectures
  * Network Perimeter Controls: firewalls, packet filters, application
    gateways.

BEST PAPER AWARD:

  A best paper award will be introduced at NDSS 2000. This award will
  be presented at the symposium to the authors of the best paper to
  be selected by the program committee.

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Gene Tsudik, USC / Information Sciences Institute
  Avi Rubin, AT&T Labs - Research

TUTORIAL CHAIR:
  Doug Maughan, NSA / DARPA

PROGRAM COMMITTEE:
  Bill Cheswick, Lucent Bell Labs  
  Marc Dacier, IBM Research Zurich 
  Jim Ellis, CMU / CERT
  Carl Ellison, Intel   
  Ed Felten, Princeton  
  Virgil Gligor, UMD College Park 
  Thomas Hardjono, Bay Networks/Nortel
  Cynthia Irvine, Naval Postgraduate School
  Charlie Kaufman,  Iris Associates
  Dave Kormann, AT&T Labs - Research 
  Hugo Krawczyk, Technion and IBM
  Carl Landwehr, Naval Research Lab
  Doug Maughan, NSA / DARPA   
  Gary McGraw, Reliable Software Technologies  
  Sandra Murphy, TIS Labs at Network Associates   
  Clifford Neuman, USC / Information Sciences Institute
  Paul Van Oorschot, Entrust
  Sami Saydjari, DARPA ISO 
  David Wagner, UC Berkeley   
  Bennet Yee, UC San Diego

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates   

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: 

  The committee invites both technical papers and panel proposals.
  Technical papers should be at most 20 pages long. Panel proposals
  should be at most 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 the panelists.

  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, e-mail addresses, and must specify
  the contact author in case of multi-author submissions. The names
  of authors, affiliations, and other identifying information should
  appear only on the separate title page.

  Submissions must be received by June 16, 1999, and must be made
  via electronic mail in either PostScript or ASCII format.  If
  the committee is unable to print a PostScript submission, a
  hardcopy will be requested. Therefore, PostScript submissions
  must arrive well before the deadline.

  All submissions and program related correspondence (only) should
  be directed to the program chair:

        Gene Tsudik     
        USC Information Sciences Institute      
        4676 Admiralty Way      
        Marina Del Rey, CA 90292        
        Email: [e-mail]
        TEL: [phone] ext 329
        FAX: [phone] 

  Dates, final call for papers, advance program, and registration
  information will be available soon at the URL: httl//www.isoc.org/ndss2000.

  Each submission will be acknowledged by e-mail.  If acknowledgment
  is not received within seven days, please contact the program
  chair as indicated above.  Authors and panelists will be notified
  of acceptance by August 17, 1999.  Instructions for preparing
  camera-ready copy for the proceedings will be sent at that time.
  The camera-ready copy must be received by October 15, 1999.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00828 for ietf-pkix-bks; Wed, 26 May 1999 06:50:22 -0700 (PDT)
Received: from harrier.prod.itd.earthlink.net (harrier.prod.itd.earthlink.net [207.217.120.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA00824 for <[e-mail]>; Wed, 26 May 1999 06:50:21 -0700 (PDT)
Received: from brick (sdn-ar-016casfraP209.dialsprint.net [158.252.220.211]) by harrier.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id GAA24468; Wed, 26 May 1999 06:50:57 -0700 (PDT)
Message-ID: <004b01bea77e$c225d610$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "PKIX" <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]>
Subject: Re: Trying again: Unsettled topics, Qualified Certificates.
Date: Wed, 26 May 1999 06:50:41 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I concur with Stefan's observations...
----- Original Message -----
From: Stefan Santesson <[e-mail]>
To: PKIX <[e-mail]>
Sent: Wednesday, May 26, 1999 12:44 AM
Subject: Trying again: Unsettled topics, Qualified Certificates.


> Gentlemen,
>
> Please stick to the subject. If you want to argue pro or against the
> EU-directive, then I suggest you direct that to the EU-commission.
>
> I want suggestions and comments on the discussed techniques and that is:
>
> 1) Should we add a recommendation to include explaining text in commonName
> when storing a pseudonym name
>
> 2) Should we use policy qualifiers or a new extension to specify a maximum
> reliance limit.
>
> We have to solve these issues and now is the chance to influence the
> outcome of this.
> I would also like to present 2 different proposals on extensions for
> reliance limits.
>
>
> Proposal 1 from Germany PKI specifications:
>
> monetaryLimit EXTENSION ::= {
> SYNTAX MonetaryLimitSyntax
> IDENTIFIED BY id-sigi-at-monetaryLimit }
> id-sigi-at-monetaryLimit OBJECT IDENTIFIER ::= {1 3 36 8 3 4}
> MonetaryLimitSyntax ::= SEQUENCE {
>   currency PrintableString (SIZE(3)),
>   amount INTEGER,
>   exponent INTEGER }
>
>
> Proposal 2 from Bob Juneman, Novell:
>
> RelianceLimits ::= SEQUENCE {
> perTransactionLimit MonetaryValue,
> perCertificateLimit MonetaryValue }
>
> MonetaryValue ::= SEQUENCE {  -- from SET and draft ANSI X9.45
> currency Currency,
> amount INTEGER,
> amtExp10 INTEGER}
> -- value is amount * (10** amtExp1),
> -- an exact representation
>
> Currency ::= INTEGER (1..999)
> -- currency denomination from ISO 4217
> -- US Dollar (USD) is  840.
> -- Euro (EUR) is 978.
>
>
>
> My personal suggestion to issue 1 and 2 are:
> Issue 1 - Do nothing (no explaining text in commonName)
> Issue 2 - Define an optional extension according to the German proposal (I
> don't like two different values according to the Novell proposal. It adds
> to much confusion).
>
> But this can change.
>
> /Stefan
>
>
> At 10:52 AM 5/25/99 -0700, [e-mail] wrote:
> >
> >
> >i disagree entirely with your statement that "Certificate policy could
> >specify liability but that does not have anything to do with the sums you
> >transact or protect." certificates state how they are to be used. key
usage
> >is a simplified statement of the constraint on a certificate's use. the
> >certificate's policy also describes how the certificate is to be used and
> >allows that description to be more precise than key usage. (when this
stuff
> >was being defined, i argued that we did not need key usage but a set of
> >standardized policies instead. the others agreed in concept but felt key
> >usage would be more readily deployable in the start-up phase. )
> >
> >
> >
> >certificate policy is intended to control the use to which a certificate
> >can be put. liability issues are a strong factor in determining that
> >constraint but liability need not be specified in the cp. i suspect that
> >you may be confused about the difference between cp and cps
> >
> >
> >
> >i don't understand your statement "Of course you can have any number of
> >optional items but if people start to actually use them you will pretty
> >soon run into severe problems." qualifiers are associated with a specific
> >policy. if an implementation (or a human user), understands the policy,
it
> >must understand the qualifiers that are associated with that policy. i
> >agree that a policy with a large number of qualifiers and complex
> >interworking may be difficult to deploy, but not more difficult than
> >supporting the large number of policies each of which embody the one of
the
> >combinations of qualifiers and qualifier values within the policy itself.
> >
> >
> >
> >on your recommendation to "ignore", i think such implementors would have
a
> >difficult day in court when being questioned about the conformance of
their
> >product to the accepted business practice. i believe that the courts
would
> >consider EU regulation as a strong guideline to the acceptable business
> >practice.
> >
> >Where law and technology intersect, the engineers "yes/no" view must
adapt
> >to the court's "maybe" view. the policies and guidelines may not be
perfect
> >and they are sure to be refined by case law. but i would like to have as
> >good a technological stake in the ground as possible rather than having
> >some judge start with a blank page when determining the acceptablity of a
> >digital signature.
> >
> >     hoyt
> >
> >
> >
> >
> >
> >Anders Rundgren <[e-mail]> on 05/25/99 08:35:59 AM
> >
> >To:   PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
> >cc:    (bcc: Hoyt Kesterson/US/BULL)
> >Subject:  RE: Unsettled topics, Qualified Certificates.
> >
> >
> >
> >
> >Stefan,
> >
> ><snip>
> >>Issue 2) Storage of maximum value per transaction.
> >
> >>The directive requires that a certificate, if applicable, shall contain
> >>information about a maximum monetary amount per transaction that the
> >>certificate should support.
> >
> >My comment to this is that the EU directive seems to try to solve all
> >business problems with
> >certificates.  This is IMO a bad idea and will only delay things.
> >
> >Let's say that you open a door with a cert.  How can you possibly say how
> >much value you have behind the door?
> >
> >And what is the true value of a signed business contract?
> >
> >For monetary transactions it is up to the relying party (the bank, the
> >selling organization) to
> >set proper limits and to your organization as well.  To do this in a
static
> >certificate
> >(probably issued by a TTP) is lunacy.
> >
> >>This could be done by defining a new extension (like the Germans already
> >>have done in their interoperability specifications), or alternatively
just
> >>say that this shall be solved by a certificate policy, possibly in
> >>combination with a policy qualifier.
> >
> >Certificate policy could specify liability but that does not have
anything
> >to do
> >with the sums you transact or protect.
> >
> >>Arguments has been raised that Policy qualifiers are not suitable for
> >>automatic interpretation but that is not confirmed.
> >
> >Of course you can have any number of optional items but if people start
to
> >actually use them you will pretty soon run into severe problems.
> >
> >So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep some
> >people happy) but
> >just IGNORE them in real implementations.  This is the proper (only) way
to
> >handle EU bureaucracy :-)  :-)
> >
> >Anders Rundgren
> >http://www.mobilephones-tng.com
> >
> >
> >
> >
>
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB      http://www.accurata.se
> Slagthuset                      Tel. [phone]
> 211 20  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA00664 for ietf-pkix-bks; Wed, 26 May 1999 06:26:06 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA00660 for <[e-mail]>; Wed, 26 May 1999 06:26:04 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24182; Wed, 26 May 1999 09:26:13 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-bert1-01.txt
Date: Wed, 26 May 1999 09:26:13 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New 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		: Basic Event Representation Token v1
	Author(s)	: M. McNeil, T. Glassey
	Filename	: draft-ietf-pkix-bert1-01.txt
	Pages		: 39
	Date		: 25-May-99
	
More and more, standards agencies that use PKI technologies 
developed and promulgated through the efforts of the IETF have come 
to ask for a finite method of representing a discrete instant in 
time as a referable event. The present document establishes defined 
data structures for requesting a Basic Event Representation Token 
(BERT), after it has been issued by a Trusted Timebase provider.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-bert1-01.txt

Internet-Drafts are also 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-bert1-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-bert1-01.txt".
	
NOTE:	The mail server at ietf.org 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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-bert1-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-bert1-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21808 for ietf-pkix-bks; Wed, 26 May 1999 00:43:33 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21799 for <[e-mail]>; Wed, 26 May 1999 00:43:30 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id JAA22142 for <[e-mail]>; Wed, 26 May 1999 09:45:26 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 26 May 1999 09:44:08 +0200
To: PKIX <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Trying again: Unsettled topics, Qualified Certificates.
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA21803
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Gentlemen,

Please stick to the subject. If you want to argue pro or against the
EU-directive, then I suggest you direct that to the EU-commission.

I want suggestions and comments on the discussed techniques and that is:

1) Should we add a recommendation to include explaining text in commonName
when storing a pseudonym name

2) Should we use policy qualifiers or a new extension to specify a maximum
reliance limit.

We have to solve these issues and now is the chance to influence the
outcome of this.
I would also like to present 2 different proposals on extensions for
reliance limits.


Proposal 1 from Germany PKI specifications:

monetaryLimit	EXTENSION	::= {
SYNTAX	MonetaryLimitSyntax
IDENTIFIED BY	id-sigi-at-monetaryLimit }
id-sigi-at-monetaryLimit OBJECT IDENTIFIER	::= {1 3 36 8 3 4}
MonetaryLimitSyntax	::=	SEQUENCE {
  currency	PrintableString (SIZE(3)),
  amount	INTEGER,
  exponent	INTEGER }


Proposal 2 from Bob Juneman, Novell:

RelianceLimits ::= SEQUENCE	{
			perTransactionLimit 	MonetaryValue,
			perCertificateLimit	MonetaryValue }

		MonetaryValue ::= SEQUENCE {  -- from SET and draft ANSI X9.45
				currency Currency,
				amount INTEGER,
				amtExp10 INTEGER}
					-- value is amount * (10** amtExp1),
					-- an exact representation

		Currency ::= INTEGER (1..999)
			-- currency denomination from ISO 4217
			-- US Dollar (USD) is  840.
			-- Euro (EUR) is 978.



My personal suggestion to issue 1 and 2 are:
Issue 1 - Do nothing (no explaining text in commonName)
Issue 2 - Define an optional extension according to the German proposal (I
don't like two different values according to the Novell proposal. It adds
to much confusion).

But this can change.

/Stefan


At 10:52 AM 5/25/99 -0700, [e-mail] wrote:
>
>
>i disagree entirely with your statement that "Certificate policy could
>specify liability but that does not have anything to do with the sums you
>transact or protect." certificates state how they are to be used. key usage
>is a simplified statement of the constraint on a certificate's use. the
>certificate's policy also describes how the certificate is to be used and
>allows that description to be more precise than key usage. (when this stuff
>was being defined, i argued that we did not need key usage but a set of
>standardized policies instead. the others agreed in concept but felt key
>usage would be more readily deployable in the start-up phase. )
>
>
>
>certificate policy is intended to control the use to which a certificate
>can be put. liability issues are a strong factor in determining that
>constraint but liability need not be specified in the cp. i suspect that
>you may be confused about the difference between cp and cps
>
>
>
>i don't understand your statement "Of course you can have any number of
>optional items but if people start to actually use them you will pretty
>soon run into severe problems." qualifiers are associated with a specific
>policy. if an implementation (or a human user), understands the policy, it
>must understand the qualifiers that are associated with that policy. i
>agree that a policy with a large number of qualifiers and complex
>interworking may be difficult to deploy, but not more difficult than
>supporting the large number of policies each of which embody the one of the
>combinations of qualifiers and qualifier values within the policy itself.
>
>
>
>on your recommendation to "ignore", i think such implementors would have a
>difficult day in court when being questioned about the conformance of their
>product to the accepted business practice. i believe that the courts would
>consider EU regulation as a strong guideline to the acceptable business
>practice.
>
>Where law and technology intersect, the engineers "yes/no" view must adapt
>to the court's "maybe" view. the policies and guidelines may not be perfect
>and they are sure to be refined by case law. but i would like to have as
>good a technological stake in the ground as possible rather than having
>some judge start with a blank page when determining the acceptablity of a
>digital signature.
>
>     hoyt
>
>
>
>
>
>Anders Rundgren <[e-mail]> on 05/25/99 08:35:59 AM
>
>To:   PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
>cc:    (bcc: Hoyt Kesterson/US/BULL)
>Subject:  RE: Unsettled topics, Qualified Certificates.
>
>
>
>
>Stefan,
>
><snip>
>>Issue 2) Storage of maximum value per transaction.
>
>>The directive requires that a certificate, if applicable, shall contain
>>information about a maximum monetary amount per transaction that the
>>certificate should support.
>
>My comment to this is that the EU directive seems to try to solve all
>business problems with
>certificates.  This is IMO a bad idea and will only delay things.
>
>Let's say that you open a door with a cert.  How can you possibly say how
>much value you have behind the door?
>
>And what is the true value of a signed business contract?
>
>For monetary transactions it is up to the relying party (the bank, the
>selling organization) to
>set proper limits and to your organization as well.  To do this in a static
>certificate
>(probably issued by a TTP) is lunacy.
>
>>This could be done by defining a new extension (like the Germans already
>>have done in their interoperability specifications), or alternatively just
>>say that this shall be solved by a certificate policy, possibly in
>>combination with a policy qualifier.
>
>Certificate policy could specify liability but that does not have anything
>to do
>with the sums you transact or protect.
>
>>Arguments has been raised that Policy qualifiers are not suitable for
>>automatic interpretation but that is not confirmed.
>
>Of course you can have any number of optional items but if people start to
>actually use them you will pretty soon run into severe problems.
>
>So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep some
>people happy) but
>just IGNORE them in real implementations.  This is the proper (only) way to
>handle EU bureaucracy :-)  :-)
>
>Anders Rundgren
>http://www.mobilephones-tng.com
>
>
>
>

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA13656 for ietf-pkix-bks; Tue, 25 May 1999 23:04:15 -0700 (PDT)
Received: from mystic.trustcenter.de (mystic.trustcenter.de [194.64.226.89]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA13647 for <[e-mail]>; Tue, 25 May 1999 23:04:13 -0700 (PDT)
Message-Id: <3.0.5.32.19990526080336.00be82c0@ganymed>
X-Sender: jbr@ganymed
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 26 May 1999 08:03:36 +0200
To: [e-mail]
From: Juergen Brauckmann <[e-mail]>
Subject: Re: Unsettled topics, Qualified Certificates.
In-Reply-To: <[e-mail]>
References: <01BEA695.FA647CA0@DHARTER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi.

>Issue 1) Identification of pseudonym names stored in commonName
>The question is if a pseudonym stored in a commonName attribute in the
>subject field should include some information that the attribute contains a
>pseudonym. e.g. CN="<pseudonym>Bill Clinton" in order to alert the relying
>party that the name is not a real name but a pseudonym.
>
>The alternative is to allow pseudonym name in the commoName with no other
>identification of the name semantics than what is implicitly defined by an
>indicated certificate policy and/or it's qualifier(s).

The underlying question seems to be whether qualified certificates are
handled in a known environment where the software knows all about things
like certain policy OIDs or if we think that it might be necessary that a
human sees parts of a certificate and tries to interpret it.

If we assume that we live in a known environment, we can use policy oids.
If we assume that qualified certificates might go to some other place, it
might be a good idea to use a modifier in the DN, because such information
can always be interpreted by the user.

>Issue 2) Storage of maximum value per transaction.
>This could be done by defining a new extension (like the Germans already
>have done in their interoperability specifications), or alternatively just
>say that this shall be solved by a certificate policy, possibly in
>combination with a policy qualifier.
>
>Arguments has been raised that Policy qualifiers are not suitable for
>automatic interpretation but that is not confirmed.

I don't think that an extension "monetaryLimit=100,-DM" is suitable for
automatic interpretation, too, because the extension does not express the
policy of the CA: Is the CA liable for the 100,-DM or not? Did the CA check
that the certificate owner in fact has 100,-DM? This are enough questions
that inhibit a decision by the software if the certificate is to be
accepted or not, and thus the software needs to check the policy.

Regards,
   Juergen
-- 
Juergen Brauckmann             Tel.:  040 / 766 29 2708
TC Trust Center for Security   Fax.:  040 / 766 29 577
in Data Networks GmbH 	    mailto:[e-mail]
Am Werder 1    		    http://www.trustcenter.de	
21073 Hamburg


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA28715 for ietf-pkix-bks; Tue, 25 May 1999 20:40:03 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA28710 for <[e-mail]>; Tue, 25 May 1999 20:40:02 -0700 (PDT)
Received: from mcg.org.br (pm06-26.sac.verio.net [209.162.64.233]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id UAA28747; Tue, 25 May 1999 20:40:33 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 20:30:47 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Graham Klyne <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: General formula, was Re: Attribute certificate lifetimes:way too  much  math, but getting closer to correct
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graham Klyne wrote:

> I have been reviewing this discussion with interest, but am deeply
> uncomfortable with  some of the claims made...  I gather my responses to
> three of your postings into this one message...

Graham:

Thanks. I am all for the "doubt till you have proof" approach.
I am leaving in one hour for a cross-country red-eye two day hop
to Washington DC, so I will try to answer you now since I do not
expect to be on e-mail before Friday.

First, let me note that an extensive paper where my "claims" are discussed
has circulated for some months now in a reviewer circuit so, based on those
reviews, I do not expect any major mistake. Second, I could not resist to
present some of my results, even if partially, to this list since I saw the subject
was very timely to the discussions. And, yes, the paper has greatly profited
from the discussions, examples and counter-examples here. I expect to have
it ready for public presentation next week, when I will post here the relevant
URL.

> At 12:25 18/05/99 -0700, Ed Gerck wrote:
> [A derivation of a formula for certificate lifetime;  interesting stuff!]

Yes, and it applies also to *any* database record -- not only certificates.
In fact, it applies also to common text -- such as this one.

> I have some reservations about the statistical validity of "can be
> well-approximated by a linear first-degree differential equation" (in
> reference [1] of the initial posting), but it sounds plausible.

It is proved in the paper -- but, since you don''t contest it, I will let
the matter rest until the paper is presented.

> [...]
> >As a practical rule, key-lifetime Tk should be at most 1/3 the shortest
> >attribute lifetime Ta, since for Tk = Ta/3 one has:
> >
> >1/T = 1/Tk + 1/Ta + ...+ 1/TN =~ 1/Tk + 1/Ta => T =~ 0.75 * Tk
>
> I find this practical rule over-simple:  suppose there are K attributes
> with the same minimum key-lifetime Tk, then the result T given by your
> formula must be less than or equal to Tk/K.  If K>3 the practical rule
> given is somewhat optimistic.

Of course -- the practical rule is simplified, perhaps even over-simplified.
But, it is NOT optimistic and is NOT wrong -- note that I wrote "at most"
and surely Tk/3 > Tk/K for K>3. Agreed?

So, the practical rule "Key-lifetime Tk should be at most 1/3 the shortest
attribute lifetime Ta" will always provide you a correct upper bound -- which
is exactly what I intended to when I wrote "at most".

> [and later]
> At 19:01 18/05/99 -0700, Ed Gerck wrote:
> >My assumption is very unassuming ;-)  -- it is simply that any attribute
> validity
> >in a X.509/PKIX cert is an non-increasing function of time. If you find a
> >X.509/PKIX attribute that increases its validity with time then you have
> found
> >an exception where my formula (and Blackley's, buy extension) is not valid.
>
> What is this "validity" quantity you are describing?

The "attribute validity"  I mention above is described where the equation's
assumptions are described -- reference [1] of the original posting, it is
An -- to wit:

---------------------------------------
 dAn/dt = - An/Tn , for n =1, ...N              (2)

 where d/dt is time derivative (in continuous or discrete form), Tn is the
 effective attribute's a priori lifetime, and An is the attribute validity
                                                                           ^^^^^^^^^^^^
 function at time t:

 An = fraction of valid attributes n at time t, normalized to the ensemble.
------------------------------------------------


> [...]
> >As you say -- but this simply means that you need two lifetimes (as I called
> >them, two sub-attributes). One lifetime is very long and just leads to that
> >slight decay you mention for three years. Then, another lifetime is triggered
> >by a delayed sub-attribute, but this lifetime is very short. But, you may
> ask, how
> >can I take delayed sub-attributes into account? Simple, by considering the
> >certitficate lifetime to be given by a piecewise function.
>
> Now I am truly sceptical.  The derivation of your formula was based on
> assumption of a differential equation description of the process:  such
> descriptions depend upon assumptions of continuity and continuous
> differentiability, which I think are broken by the piecewise construction
> you advocate.

No -- the assumption order is reversed from what you thought. The equation is
piecewise valid, *thus* the piecewise solution that obeys it is valid -- not the other
way around.

To exemplify, define the time axis [0,oo) into K intervals, one for each different
K-delayed lifetime needed for *one* attribute -- so that to each K interval there is
*only one* exponential decay lifetime assigned to *that*  attribute. Note that the K
intervals to do not have to be uniform. Each one of these K intervals defines a possible
sub-attribute to that *one* original attribute and for each one of these intervals the
equation:

dA/dt = - A/T

is valid with the following boundary conditions and lifetime:

  CONDITION            INTERVAL      LIFETIME
   A(0) = Ao                    0<= t < t1                 T1
  A(t1-) = A(t1)              t1<= t < t2                 T2
.....
  A(tK-1-) = A(tK-1)    tK-1<= t < oo             TK

which defines a continuous piecewise function A(t) valid in the relevant total
interval [0,oo), with K delayed sub-attributes. Note also that the Tn do not have to
be all different -- in fact, they can be all equal.


> >... It does NOT include
> >the short-lifetime delayed attribute until its maturation period (that you
> say is
> >3 years), and then adds it as 1/Ts. But, since Ts is small, 1/Ts is large
> and its
> >effect on the certificate lifetime T is large. So, a small Ts strongly
> >*decreases*  certificate lifetime T, since 1/T = (1/T1 + ..1/Tm) + 1/Ts and
> >(1/T1 + ...+ 1/Tm) is constant. Clear?
>
> My intuition here is that smaller values for 'Ts' (the second segment of
> the piecewise function) are *less* relevant to the overall
> period-of-validity, not more so.

There is a simple confusion here -- the piecewise solution I mention is NOT
in each interval but for staggered intervals. So, in each interval the equation
1/T = (1/T1 + ..1/Tm) + 1/Ts  is NOT piecewise at all. So, you can directly
compare its terms and when Ts is small one must have 1/Ts large -- which
then dominates the sum  (1/T1 + ..1/Tm):

 (1/T1 + ..1/Tm) << 1/Ts

to the extent that

1/T = (1/T1 + ..1/Tm) + 1/Ts  ~ 1/Ts ==> T ~ Ts. In other words, as I am quoted
above, "a small Ts strongly *decreases*  certificate lifetime T".


>  (This reinforces my scepticism about the
> formula offered:  for it to stand any chance of holding, I think it must
> deal with statistical properties that can be stated in a time-invariant
> fashion;  e.g. probability of becoming invalid in a given time interval.)

Reading the above I suspect that you imagined a piecewise sum for each
interval. This is NOT the case. The piecewise solution is built by considering the
least interval that is needed for all attributes and then using this interval for *all*
attributes -- where any one attribute may be divided into more time slices than
it needs by itself, but such will not hurt ;-)

> [and yet later]
> At 15:37 21/05/99 -0700, Ed Gerck wrote:
>
> >> They certainly don't have to, but in many cases they actually DO.  The
> >> example I gave above is one case; the same information encoded
> >> on a driver's license for me is a derivative which exemplifies
> >> a broad class of certification scenarios from the real world which
> >> also have this property.
> >
> >I disagree. And, there are billions of counter-examples. For example,
> >if men's biological lifetime is 70 years this does not mean that all men
> >were born at the same time -- and yet they all have the same lifetime.
>
> I think this entirely misses the point that was being made:  a single case
> is sufficient for an existence proof, and such was provided by Bob B.

Wait -- this is NOT the issue here. Bob Blakley wrote that equal lifetimes
would indicate a "property" -- that the corresponding attributes would
actually be dependent or at least have a tendency to be dependent. I replied
negatively -- such property or tendency does NOT exist. Lifetime distance
does not correlate with attribute independency -- much in the same way that
a pointer's value (lifetime) does not correlate with a pointer's address (attribute).
They are two entirely different concepts, not only different values. Thus, the fact
that the lifetimes are equal or even similar for two attributes does not authorize
me to say anything about the attributes' dependencies.

> Despite your claims otherwise, I belive you are making an assumption of
> independence of attributes:  specifically, independence of time-of-birth.

No, not all -- and, where is this needed?  Nowhere. Please read the first
paragraph of [1]:

[1] Consider an ensemble of certificates, each with a given number M of
attributes, with each attribute defined by a lifetime -- including
the key. This ensemble can include certificates that are issued at the
same time for different keyholders and certificates that are issued at
different times for the same keyholder. The ensemble is an analysis tool,
to be used in order to allow the calculation of average statistics based
on time averages, but note that the M attributes are not supposed to be
independent from one another.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA12161 for ietf-pkix-bks; Tue, 25 May 1999 19:02:38 -0700 (PDT)
Received: from ridge.spiritone.com (ridge.spiritone.com [205.139.108.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA12150 for <[e-mail]>; Tue, 25 May 1999 19:02:36 -0700 (PDT)
Received: from acm.org ([e-mail] [208.130.240.240]) by ridge.spiritone.com (8.8.8/8.8.8) with ESMTP id TAA14705; Tue, 25 May 1999 19:03:12 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 19:02:35 -0700
From: Carl Ellison <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.30 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail], [e-mail], Carl Ellison <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" wrote:
[snip]
> which can select the engine to be used.  Automated authorization is not
> a mature field; there are numerous candidates:  NIST's Role Based
> Access Control, SPKI tuples, Novell's Security Attributes, the DoD's
> SDN.801, and many others.  In 10 years, perhaps everyone will agree

[...]

> should be used.  The fewer engines applications have to support, the
> better, but I don't think the market is yet convinced that SPKI tuples
> are capable of supplanting RBAC, DoD PRBAC/LRBAC, other chaining
> mechanisms, and plain old ACLs for all public-key-based authorization
> applications.

Hi David.

You're right.  We haven't demonstrated all that yet.  We haven't
tried, yet.  However, I'm confident we will be able to and I look
forward to the resulting interaction either way the demo turns out.

 - Carl

-- 
 Carl M. Ellison   [e-mail]     http://www.pobox.com/~cme
 PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2
 ``Officer, officer, arrest that man!  He's whistling a dirty song.''
     [Jean Ellison]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA05943 for ietf-pkix-bks; Tue, 25 May 1999 17:10:19 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA05938 for <[e-mail]>; Tue, 25 May 1999 17:10:17 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 0725677D.0000BB56 ; Tue, 25 May 1999 17:07:59 -0700
X-Lotus-FromDomain: BULL
To: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 17:10:09 -0700
Subject: RE: X.509 ACs vs. SPKI?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

sorry i sent this to carl when i meant to copy the whole list

      hoyt
---------------------- Forwarded by Hoyt Kesterson/US/BULL on 05/25/99
05:09 PM ---------------------------


Hoyt Kesterson
05/25/99 03:33 PM

To:   "Ellison, Carl M" <[e-mail]>
cc:
Subject:  RE: X.509 ACs vs. SPKI?  (Document link not converted)

at the risk of disrupting such violent argreement - where is it written,
other than in spki land, that the same pubic key cannot be in more than one
certificate. if a key appears in two certificates of owner x, you cannot
link an attribute certificate to a specific one of those certificates via
the public key

    hoyt



"Ellison, Carl M" <[e-mail]> on 05/25/99 01:03:41 PM

To:   "'Stephen Kent'" <[e-mail]>, "Ellison, Carl M"
      <[e-mail]>
cc:   [e-mail], [e-mail] (bcc: Hoyt Kesterson/US/BULL)
Subject:  RE: X.509 ACs vs. SPKI?




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve,

as I've said before, we tend to be in violent agreement :)

Sometime (not on this thread) we can resume our debate about
the meaning of names, but I'm glad we agree that for secure binding,
the hash of the public key is a fine globally unique identifier and an
unanchored text name is wide open to abuse.

If that can be made clear in the spec -- and if the issuer can also be
identified by hash of the public key -- then the AC begins to look
like a certificate I can readily use in an authorization computation.
[Sometime, I should show you the mechanism we've planned for CDSA that
does authorization computations for all certificate types, not just
SPKI.....]

 - Carl


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, May 25, 1999 11:42 AM
> To: Ellison, Carl M
> Cc: [e-mail]; [e-mail]
> Subject: RE: X.509 ACs vs. SPKI?
>
>
> Carl,
>
> I agree that the only safe way to bind an attribute cert to
> an identity
> cert is via the public key hash. That's what I always recommend to
my
> clients.
>
> Look at the draft profile for attribute certs recently
> published by Stephen
> Farrell and it's easy to locate the key hash as pointer.  The real
> difference here is that X.509 believes that certs with public
> keys should
> contain a name that is not purely a local matter.
>
> The hash is the most secure way to bind an attribute (yes,
> "authorization"
> is a better name) cert to the identity cert, and I'll suggest that
we
> mandate it in our profile as we progress.
>
> Steve
>

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQA/AwUBN0sCMcxqBGb+WvJAEQIUqQCZATBGoOGwYgp3B+xIpG1pAdnZpZUAoMXn
8cxPRJS4r6g3OQk2+ubEk5Us
=hjuA
-----END PGP SIGNATURE-----








Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05384 for ietf-pkix-bks; Tue, 25 May 1999 16:56:28 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05380 for <[e-mail]>; Tue, 25 May 1999 16:56:27 -0700 (PDT)
Received: from mcg.org.br (pm05-07.sac.verio.net [209.162.64.167]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA15331; Tue, 25 May 1999 16:57:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 16:48:02 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ellison, Carl M" <[e-mail]>
CC: "'Stephen Kent'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ellison, Carl M" wrote:

> ... for secure binding,
> the hash of the public key is a fine globally unique identifier and an
> unanchored text name is wide open to abuse.

I disagree. The hash of the public-key is also open to abuse since it
does not securely include that key's validity date, does not include an
originally secure reference to a valid revocation mechanism linked to
the identity certificate from whence that public-key came and cannot
contain other warranties or insurance by extension from the identity
certificate itself.  Please see  my former e-mail.

However, I agree if  one uses the whole identity certificate hash -- not
the public-key hash. This was also discussed in my former e-mail.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04248 for ietf-pkix-bks; Tue, 25 May 1999 16:29:59 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04244 for <[e-mail]>; Tue, 25 May 1999 16:29:58 -0700 (PDT)
Received: from mcg.org.br (pm05-07.sac.verio.net [209.162.64.167]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id QAA09029; Tue, 25 May 1999 16:30:29 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 16:21:30 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: "Ellison, Carl M" <[e-mail]>, [e-mail]
Subject: Re: X.509 ACs vs. SPKI?
References: <v04020a04b3709e767a28@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> Carl,
>
> I agree that the only safe way to bind an attribute cert to an identity
> cert is via the public key hash. That's what I always recommend to my
> clients.

Actually, if you want to bind X to an identity cert the only secure way is
via that cert's hash as a whole, not the public-key hash.  In fact, the cert
hash is not simply the only unique reference that you can rely on for that
identity cert, but also one which (by extension from the cert) already
includes a revocation mechanism (CRL or OCSP) and possibly also
insurance or derived warranties (via CA CPS).

I note that the cert hash has been suggested as an intrinsic DN two years
ago [Ger97a], which can be entirely locally defined and with a local
decision tree that allows its local reconstruction at any time -- yet globally
unambiguous.

Of course, if you want to bind X to a public-key then you are justified to
do what you mentioned. But,  the CRL-authority for that public-key
cannot be securely defined neither by the keyholder nor by delegation
to the identity cert issuer -- which is a serious security fault. Besides, you
would lack insurance and other warranties which can be directly derived
by extension from the cert -- since no cert is named.

> Look at the draft profile for attribute certs recently published by Stephen
> Farrell and it's easy to locate the key hash as pointer.  The real
> difference here is that X.509 believes that certs with public keys should
> contain a name that is not purely a local matter.

This is not correct, though a common misconception and unfortunately often
so cited in some SPKI  documents. Let me divide the issue in three parts:

1. Section 3.3.3 of X.509v3 defines a certificate as: "user certificate;
public key certificate; certificate:  The public keys of a user, together
with some other information, rendered unforgeable by encipherment
with the private key of the certification authority which issued it.". But,
what is "some other information"?

2. Section 11.2 of X.509v3, "Management of certificates", states that
the certificate allows an association between a name called "unique
distinguished name" or DN for the user and the user's public-key:
"A  certificate  associates  the public key and unique distinguished
name of the user it describes.", while Section 7 explains that such
DNs are essential to the security design of X.509: "Authentication
relies on each user possessing a unique distinguished name." But,
how are such DNs assigned? Where are they unique? Locally,
globally?

3. The DN is denoted by a NA (Naming Authority) and accepted by a
CA (Certification Authority) as unique within the CA's domain, where
the CA can double as a NA. It is interesting to note that the same user
can have different DNs in different CAs, or can use the same DN in
different CAs even if it is not the first one to use it in a CA -- so different
DNs for different CAs do not necessarily mean different users and vice-
versa.  Further, a DN does not have to contain the user's real-world
name or location. Thus, semantically, the CA certificate refers to a name;
however it does not denote it.

Thus,  these three points deny the affirmation that a X.509 name is "not
purely a local matter" -- yes it is since the CA is local, but it could
nonetheless *also* have a global significance (for example, if that name
correctly dials a fully-qualified phone number).

However, there is one more point in X.509 which can be interesting here,
regarding the validation of such DNs -- which is also *local* to the CA,
not global at all and also not necessarily auditable:

4. X.509 is moot on validation procedures for data included in a certificate
such as the user's name, with the exception of validation procedures for the
user's public-key which are suggested (not mandated) in Section 10 of
X.509v3. For example, regarding validation procedures for the user's
identity, Section 11.2.a states that: "a certification authority shall be
satisfied of the identity of a user before creating a certificate for it", which
means that identity validation procedures are to be satisfied in the CA's
frame of reference by following the CA's own self-defined rules (called CPS),
which are declared outside the scope of X.509 and can be entirely different
for different CAs. Further, all public CA's CPSs accept indirect references
of "trust" when issuing certificates, which is a security risk that could only be
acessed by  auditing, to verify the procedures used to accept an ID for example
-- but, auditing is not possible with today's CPS and X.509 is also moot on such
requirement.

Thus, X.509 focuses on defining a mechanism by which information can be made
available in a secure way to a third-party. However, X.509 does not intend to
address the level of effort which is needed to validate the information in a certificate
neither define a *global* meaning to that information outside the CA's management
acts.

In legal reliance terms, one may trust the DN confirmation procedures of the CA
during certificate reliance, but one cannot rely upon them for other than their value
as a representation of the CA's authentication management act expressed in the
CA's own terms and rules (CPS) -- therefore, a DN in a X.509 certificate is *by
X.509 definition* a purely local matter (local to the CA and its CPS) even if
X.500 global directories were used (X.509v3, Section 11.2). Of course, if the US
INS accepts (rather, "uses") UK birth certificates in order to issue residence
permits to the US, this does not mean that the INS is declaring that such birth
certificates are valid in the UK. So, the eventual use by a CA of a DN supplied
by a X.500 directory does not mean that the CA is declaring that such DN is
global.

Here, in PKIX, the main purpose of a CA is also to bind a public key to the name
contained in the certificate and thus assure third parties that some measure of care
was taken to ensure that this binding is valid for both -- i.e., name and key. However,
the issue whether a user's DN actually corresponds to identity credentials that are
*globally* linked to a person, or to a local alias or, simply to an e-mail address -- and
how such association was verified --   is also outside the scope of PKIX and depends
on each CA's CPS.

See [Ger97b] for further comments.

> The hash is the most secure way to bind an attribute (yes, "authorization"
> is a better name) cert to the identity cert, and I'll suggest that we
> mandate it in our profile as we progress.

As above, I agree if by "hash" one means the whole identity certificate hash -- not the
public-key hash.


Cheers,

Ed Gerck

REFERENCES:

[Ger97a] http://www.mcg.org.br/cie.htm

[Ger97b] http://www.mcg.org.br/certover.pdf
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01549 for ietf-pkix-bks; Tue, 25 May 1999 15:15:39 -0700 (PDT)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01545 for <[e-mail]>; Tue, 25 May 1999 15:15:37 -0700 (PDT)
Received: from GK-Portable (unverified [62.188.146.133]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id <[e-mail]>; Tue, 25 May 1999 23:07:06 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 25 May 1999 23:15:55 +0100
To: Ed Gerck <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: General formula, was Re: Attribute certificate lifetimes: way too much  math, but getting closer to correct
Cc: PKIX <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have been reviewing this discussion with interest, but am deeply
uncomfortable with  some of the claims made...  I gather my responses to
three of your postings into this one message...


At 12:25 18/05/99 -0700, Ed Gerck wrote:
[A derivation of a formula for certificate lifetime;  interesting stuff!]

I have some reservations about the statistical validity of "can be
well-approximated by a linear first-degree differential equation" (in
reference [1] of the initial posting), but it sounds plausible.

[...]
>As a practical rule, key-lifetime Tk should be at most 1/3 the shortest 
>attribute lifetime Ta, since for Tk = Ta/3 one has:
>
>1/T = 1/Tk + 1/Ta + ...+ 1/TN =~ 1/Tk + 1/Ta => T =~ 0.75 * Tk

I find this practical rule over-simple:  suppose there are K attributes
with the same minimum key-lifetime Tk, then the result T given by your
formula must be less than or equal to Tk/K.  If K>3 the practical rule
given is somewhat optimistic.


[and later]
At 19:01 18/05/99 -0700, Ed Gerck wrote:
>My assumption is very unassuming ;-)  -- it is simply that any attribute
validity
>in a X.509/PKIX cert is an non-increasing function of time. If you find a
>X.509/PKIX attribute that increases its validity with time then you have
found
>an exception where my formula (and Blackley's, buy extension) is not valid.

What is this "validity" quantity you are describing?

[...]
>As you say -- but this simply means that you need two lifetimes (as I called
>them, two sub-attributes). One lifetime is very long and just leads to that
>slight decay you mention for three years. Then, another lifetime is triggered
>by a delayed sub-attribute, but this lifetime is very short. But, you may
ask, how
>can I take delayed sub-attributes into account? Simple, by considering the
>certitficate lifetime to be given by a piecewise function.

Now I am truly sceptical.  The derivation of your formula was based on
assumption of a differential equation description of the process:  such
descriptions depend upon assumptions of continuity and continuous
differentiability, which I think are broken by the piecewise construction
you advocate.

>... It does NOT include
>the short-lifetime delayed attribute until its maturation period (that you
say is
>3 years), and then adds it as 1/Ts. But, since Ts is small, 1/Ts is large
and its
>effect on the certificate lifetime T is large. So, a small Ts strongly
>*decreases*  certificate lifetime T, since 1/T = (1/T1 + ..1/Tm) + 1/Ts and
>(1/T1 + ...+ 1/Tm) is constant. Clear?

My intuition here is that smaller values for 'Ts' (the second segment of
the piecewise function) are *less* relevant to the overall
period-of-validity, not more so.  (This reinforces my scepticism about the
formula offered:  for it to stand any chance of holding, I think it must
deal with statistical properties that can be stated in a time-invariant
fashion;  e.g. probability of becoming invalid in a given time interval.)


[and yet later]
At 15:37 21/05/99 -0700, Ed Gerck wrote:

>> They certainly don't have to, but in many cases they actually DO.  The
>> example I gave above is one case; the same information encoded
>> on a driver's license for me is a derivative which exemplifies
>> a broad class of certification scenarios from the real world which
>> also have this property.
>
>I disagree. And, there are billions of counter-examples. For example,
>if men's biological lifetime is 70 years this does not mean that all men
>were born at the same time -- and yet they all have the same lifetime.

I think this entirely misses the point that was being made:  a single case
is sufficient for an existence proof, and such was provided by Bob B.

Despite your claims otherwise, I belive you are making an assumption of
independence of attributes:  specifically, independence of time-of-birth.

#g

------------
Graham Klyne
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26678 for ietf-pkix-bks; Tue, 25 May 1999 13:03:22 -0700 (PDT)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26674 for <[e-mail]>; Tue, 25 May 1999 13:03:20 -0700 (PDT)
Received: from fmsmsx28.FM.INTEL.COM (fmsmsx28.fm.intel.com [132.233.42.28]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id NAA26742; Tue, 25 May 1999 13:03:42 -0700 (PDT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0) id <LFVVDBAB>; Tue, 25 May 1999 13:03:42 -0700
Message-ID: <[e-mail]>
From: "Ellison, Carl M" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "Ellison, Carl M" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: X.509 ACs vs. SPKI?
Date: Tue, 25 May 1999 13:03:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve,

as I've said before, we tend to be in violent agreement :)

Sometime (not on this thread) we can resume our debate about
the meaning of names, but I'm glad we agree that for secure binding,
the hash of the public key is a fine globally unique identifier and an
unanchored text name is wide open to abuse.

If that can be made clear in the spec -- and if the issuer can also be
identified by hash of the public key -- then the AC begins to look
like a certificate I can readily use in an authorization computation. 
[Sometime, I should show you the mechanism we've planned for CDSA that
does authorization computations for all certificate types, not just
SPKI.....]

 - Carl


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Tuesday, May 25, 1999 11:42 AM
> To: Ellison, Carl M
> Cc: [e-mail]; [e-mail]
> Subject: RE: X.509 ACs vs. SPKI?
> 
> 
> Carl,
> 
> I agree that the only safe way to bind an attribute cert to 
> an identity
> cert is via the public key hash. That's what I always recommend to
my
> clients.
> 
> Look at the draft profile for attribute certs recently 
> published by Stephen
> Farrell and it's easy to locate the key hash as pointer.  The real
> difference here is that X.509 believes that certs with public 
> keys should
> contain a name that is not purely a local matter.
> 
> The hash is the most secure way to bind an attribute (yes, 
> "authorization"
> is a better name) cert to the identity cert, and I'll suggest that
we
> mandate it in our profile as we progress.
> 
> Steve
> 

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQA/AwUBN0sCMcxqBGb+WvJAEQIUqQCZATBGoOGwYgp3B+xIpG1pAdnZpZUAoMXn
8cxPRJS4r6g3OQk2+ubEk5Us
=hjuA
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA26138 for ietf-pkix-bks; Tue, 25 May 1999 12:47:11 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA26134 for <[e-mail]>; Tue, 25 May 1999 12:47:10 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA23992; Tue, 25 May 1999 12:40:00 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 25 May 1999 14:00:08 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: Carl Ellison <[e-mail]>, Ari Huttunen <[e-mail]>, [e-mail], [e-mail], Carl Ellison <[e-mail]>, Carl Ellison <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hoyt:

Thanks for the clarification.

Russ

At 11:55 PM 5/24/99 -0700, [e-mail] wrote:
>
>
>i beleive that russ's comments are overly restricting the third of the
>three binding methods. the hash does not have to be of a public key. it
>could be the object digest of any object, e.g. as an applet.  for example,
>object x which hashes to y has been assigned z priviliges.
>
>this is stated in 13.7 of the FPDAM after the asn.1
>
>   hoyt
>
>
>
>
>Russ Housley <[e-mail]> on 05/24/99 01:57:30 PM
>
>To:   Carl Ellison <[e-mail]>
>cc:   Ari Huttunen <[e-mail]>, [e-mail],
>      [e-mail], Carl Ellison <[e-mail]>, Carl Ellison
>      <[e-mail]> (bcc: Hoyt Kesterson/US/BULL)
>Subject:  Re: X.509 ACs vs. SPKI?
>
>
>
>
>At 09:22 AM 5/12/99 -0700, Carl Ellison wrote:
>>[snip]
>>
>>I see three problems doing the equivalent of SPKI within X.509 and in
>>particular with ACs.
>>
>>1.  The identification of issuer and subject is convoluted at best.
>Missing
>>is the option that is needed for maximum security (not to mention
>>anonymity): a public key or the hash of the key.  The IssuerSerial option
>is
>>subject to constraints not expressed in the certificate.  GeneralNames
>isn't
>>constrained or defined, AFAIK, in this spec, so that too depends on
>>constraints not evident in the certificate.  The ObjectDigestInfo might be
>>used to refer to some public key, but that use isn't spelled out -- and
>even
>>then, it is only the subject ID that has this option so identification of
>>the Issuer is left troubled.
>
>X.509 ACs offer three methods of binding the attributes to an owner.  They
>each offer different advantages and disadvantages.
>
>     (1) Issuer Distinguished Name and Serial Number.  This binds the
>attributes to a particular X.509 public key certificate.
>
>     (2) Subject Distinguished Name.  This binds the attributes to a
>collestion
>of certificates that were issued to the same subject, perhaps by different
>CAs.
>
>     (3) Hash of the Public Key.  This binds the attributes to any
>certificate
>that contains the correct public key.
>
>It is clear how (1) and (2) can be used.  And, (3) seems to provide what
>Carl is looking for.  Right?  If so, maybe you can help flesh out that part
>of the Internet-Draft.
>
>>2.  X.509 does not define the semantics of a certificate, only the syntax.
>I
>>find this especially when mapping out the CDSA extensions that extract
>SPKI
>>authorization information from existing X.509 certificates (so that our
>>implementation will accept and use a mixture of certificate types: X.509,
>>PGP, SPKI, ....).  Interpreting an X.509v3 certificate requires a
>different
>>trust policy module (in CDSA terms -- the code module that understands the
>>semantics of each field) for each different CPS -- or, to an
>approximation,
>>for each different root key.  For example, SET cardholder certificates
>>define an authorization (permission to use a given PAN/EXP) but plant that
>>authorization in the CommonName field of the SubjectName.  Meanwhile, some
>>extensions of the SET certificate carry authorization information while
>>others are to be used for chain validation only.
>
>There should be common syntax and semantics for base certificate fields.
>Certainly any private extension could be an issue.
>
>I think that the semantics should be the same for any certificate issued
>under the same Certificate Policy (CP), regardless of the Certification
>Practice Statement (CPS) used by a particular CA.
>
>>3.  X.509 may be able to define SDSI names, but there is no mechanism for
>>referring to a fully qualified SDSI name.  That means that the only
>>mechanisms for making an SPKI attribute certificate (one that gives an
>>authorization to a named entity or group) have to rely on assumptions
>about
>>naming conventions.  In particular, I see no way to express:
>>
>>    (name <key> N_1 N_2 ... N_k)
>>
>>in X.509.
>
>The  X.509 public key certificate provides (name <key>).
>
>The X.509 ACs could provide (name N_1), (name N_2 N_3), ... (name N_k).
>Where a collection of ACs each contain one or more attributes.
>
>Russ
>
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25750 for ietf-pkix-bks; Tue, 25 May 1999 12:32:50 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA25746 for <[e-mail]>; Tue, 25 May 1999 12:32:48 -0700 (PDT)
Received: 	id PAA14788; Tue, 25 May 1999 15:29:22 -0400
Received: by gateway id <LMML95FF>; Tue, 25 May 1999 15:31:47 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on time-stamp-01: Use of PolicyInformation
Date: Tue, 25 May 1999 15:31:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Terry;

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Tuesday, May 25, 1999 2:54 PM
> To: 	Robert Zuccherato
> Cc: 	[e-mail]
> Subject: 	Re: Comments on time-stamp-01: Use of PolicyInformation
> 
> I think the field should be marked optional.  An alternative would be to
> allow
> the client to ignore the value in the policy field.  If this is already
> intended
> (I can't find text that says the client needs to process the policy
> value), then
> text needs to be added to make that clear.
> 
Yes, this should have been made more clear.  How about if I add text similar
to the following:

The client application SHOULD check the policy field to determine whether or
not the policy under which the token was issued is acceptable for the
application.  The client MAY ignore this field if that is acceptable for the
intended application.

> A short list of issues that should be covered by policy would be good.  I
> think
> it would help people understand why the policy field is present, and what
> kinds
> of things are not covered by the protocol definition itself.  (Is my list
> at all
> close?)
> 
Yes, I will use your short list as a minimal set of issues that should be
covered by policy.

	Robert.

> Robert Zuccherato wrote:
> 
> > I would agree that the issue of time stamping policy and time stamping
> > practice statements are important ones that will need to be solved for
> > interoperability.  However, I really don't think that including
> descriptions
> > of policies and practice statements within this draft is a good idea.
> For
> > this issue to be addressed properly, a document similar to RFC 2527
> should
> > be produced for TSAs.  I could include a short list suggesting some of
> the
> > issues that should be covered by a TSAs policy.
> >
> > Regarding the definition of a standard policy OID in this document.  I
> think
> > that coming to agreement on the meaning of such an OID would be a
> challenge
> > and that in the end it would be an OID that basically meant nothing.  I
> > don't think that we even define a default certificate policy OID in
> PKIX.
> >
> > > ----------
> > > From:         [e-mail][SMTP:[e-mail]]
> > > Reply To:     [e-mail]
> > > Sent:         Monday, May 24, 1999 2:56 PM
> > > To:   [e-mail]
> > > Subject:      Comments on time-stamp-01: Use of PolicyInformation
> > >
> > > <<File: thayes.vcf>>
> > > I have some questions/comments on the use of PolicyInformation in the
> > > proposed time-stamping protocol.
> > >
> > > First, a PolicyInformation field is required in the TSTInfo (response)
> > > data structure, but no standard policy OID is defined by this draft.
> To
> > > allow interoperability, there should be at least one standard OID
> > > defined (with appropriate definition, see following).  An alternative
> to
> > > this is to make the policy field in the response optional.  This would
> > > indicate that the response is delivered under some standard (minimum)
> > > policy, or that the policy is as agreed between the client (or CA) and
> > > the TSA.
> > >
> > > Second, the draft needs to indicate (or suggest) what types of
> > > information (guarantees?) are carried by the policy.  I can think of
> > > several:
> > >
> > >    * indicate method used to define valid message imprint digests.
> The
> > >      TSA would be guaranteeing that the digest was considered usable
> at
> > >      the time of the time-stamp.
> > >    * indicate the availability of a time-stamp log, to allow later
> > >      verification that a time-stamp token is authentic.
> > >    * indicate certification of the timestamp accuracy (by some third
> > >      party?)
> > >
> > > Since there is no discussion in the draft on what the "policy" field
> > > might represent, it will be difficult to build interoperable clients
> and
> > > servers.  I suggest that a standard OID should indicate:
> > >
> > >    * The TSA checks digests against a current list of acceptable
> digests
> > >      defined by RFC/standard - either the time-stamp document itself,
> or
> > >      a separate document that is updated to follow the latest
> > >      technology.
> > >    * A qualifier indicates whether the TSA logs time-stamps and can
> > >      provide access to logs if needed for arbitration purposes.
> > >
> > > Third, I believe that the authors assume that clients perform
> validation
> > > of the TSA certificate chain using the appropriate policy value.  This
> > > is standard X.509 processing.  However, it would be better to state
> the
> > > requirement (briefly) in the time-stamp draft.
> > >
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25430 for ietf-pkix-bks; Tue, 25 May 1999 12:19:35 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25426 for <[e-mail]>; Tue, 25 May 1999 12:19:34 -0700 (PDT)
Received: from mcg.org.br (pm08-47.sac.verio.net [209.162.65.113]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA07414; Tue, 25 May 1999 12:19:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 12:10:54 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <[e-mail]>
CC: "'Tony Bartoletti'" <[e-mail]>, Bob Blakley <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: Certificate life-cycle costs.
References: <D1A949D4508DD1119C8100400533BEDC0BEA1D@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan Lloyd wrote:

> I am lost on this one.
>
> I am sure that those who provide products and services that apply
> certificate  functionality will work out the deployment costs as part of
> the risks, ILS/LCC analysis. As certs may be used for bus tickets,
> vehical tags, licences, identity, information integrity, etc, etc.. Its
> hard to determine life cycle "costs" without knowing the application -
> trust, risk, market share, customer distribution and revenues.. Costs,
> be they called high or low are normally determined as a percentage of
> revenue...
>
> Whats the context of this?

;-) Costs, in several contexts -- including the one you mention. For example,
in answering the questions:

1. In terms of  the costs of "overloading" a certificate with additional information,
should you use M individual attribute certificates rather than one compound
M-attribute identity certificate?

2. If certificate retrieval costs X, the cost of incorrectly relying on an revoked
certificate for some transaction is Y, the value at stake is S and the time t since
the certificate was last validated by CRL or OCSP checking is T, then when
you should/should not revalidate the certificate?

For answers to these two questions, please check the last messages in the thread
on "Re: Example with sub-attributes, was Re: Attribute certificate lifetimes" --
which provide the context for this thread. See also the first two messages in this
thread, by Bob Jueneman and myself.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA24920 for ietf-pkix-bks; Tue, 25 May 1999 12:00:56 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA24915 for <[e-mail]>; Tue, 25 May 1999 12:00:53 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA11764; Tue, 25 May 1999 15:01:27 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a06b370a2626653@[128.89.0.110]>
In-Reply-To: <[e-mail]>
Date: Tue, 25 May 1999 14:55:58 -0400
To: Robert Zuccherato <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Comments on time-stamp-01: Use of PolicyInformation
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

I agree that we do not need to have at least one policy defined before we
can move forward.  The imnportant part, for the synatx that we are defining
here, is that we have a placeholder defined for a policy OID, and a brief
discussion of the need for a relying party to be able to examine the OID to
determine if it is acceptable for the time stamp application in question.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24670 for ietf-pkix-bks; Tue, 25 May 1999 11:53:57 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24663 for <[e-mail]>; Tue, 25 May 1999 11:53:56 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA04470 for <[e-mail]>; Tue, 25 May 1999 11:54:12 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FCAXUC00.9CZ; Tue, 25 May 1999 11:54:12 -0700 
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 11:54:04 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on time-stamp-01: Use of PolicyInformation
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------99A34F553A827CBE84FD02B6"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------99A34F553A827CBE84FD02B6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert,

It is true that PKIX doesn't define a default certificate policy OID.  However
it also does not REQUIRE that an OID is used in certificates.  Yes, many
deployments of PKIX will use them, but it is not required to generate valid
certificates.  The draft timestamping protocol REQUIRES a policy OID in the
TSTInfo sequence.  Since you don't provide one, every implementation will define
their own, and basic interoperability will be nonexistent.

I think the field should be marked optional.  An alternative would be to allow
the client to ignore the value in the policy field.  If this is already intended
(I can't find text that says the client needs to process the policy value), then
text needs to be added to make that clear.

A short list of issues that should be covered by policy would be good.  I think
it would help people understand why the policy field is present, and what kinds
of things are not covered by the protocol definition itself.  (Is my list at all
close?)

Terry

Robert Zuccherato wrote:

> I would agree that the issue of time stamping policy and time stamping
> practice statements are important ones that will need to be solved for
> interoperability.  However, I really don't think that including descriptions
> of policies and practice statements within this draft is a good idea.  For
> this issue to be addressed properly, a document similar to RFC 2527 should
> be produced for TSAs.  I could include a short list suggesting some of the
> issues that should be covered by a TSAs policy.
>
> Regarding the definition of a standard policy OID in this document.  I think
> that coming to agreement on the meaning of such an OID would be a challenge
> and that in the end it would be an OID that basically meant nothing.  I
> don't think that we even define a default certificate policy OID in PKIX.
>
> > ----------
> > From:         [e-mail][SMTP:[e-mail]]
> > Reply To:     [e-mail]
> > Sent:         Monday, May 24, 1999 2:56 PM
> > To:   [e-mail]
> > Subject:      Comments on time-stamp-01: Use of PolicyInformation
> >
> > <<File: thayes.vcf>>
> > I have some questions/comments on the use of PolicyInformation in the
> > proposed time-stamping protocol.
> >
> > First, a PolicyInformation field is required in the TSTInfo (response)
> > data structure, but no standard policy OID is defined by this draft.  To
> > allow interoperability, there should be at least one standard OID
> > defined (with appropriate definition, see following).  An alternative to
> > this is to make the policy field in the response optional.  This would
> > indicate that the response is delivered under some standard (minimum)
> > policy, or that the policy is as agreed between the client (or CA) and
> > the TSA.
> >
> > Second, the draft needs to indicate (or suggest) what types of
> > information (guarantees?) are carried by the policy.  I can think of
> > several:
> >
> >    * indicate method used to define valid message imprint digests.  The
> >      TSA would be guaranteeing that the digest was considered usable at
> >      the time of the time-stamp.
> >    * indicate the availability of a time-stamp log, to allow later
> >      verification that a time-stamp token is authentic.
> >    * indicate certification of the timestamp accuracy (by some third
> >      party?)
> >
> > Since there is no discussion in the draft on what the "policy" field
> > might represent, it will be difficult to build interoperable clients and
> > servers.  I suggest that a standard OID should indicate:
> >
> >    * The TSA checks digests against a current list of acceptable digests
> >      defined by RFC/standard - either the time-stamp document itself, or
> >      a separate document that is updated to follow the latest
> >      technology.
> >    * A qualifier indicates whether the TSA logs time-stamps and can
> >      provide access to logs if needed for arbitration purposes.
> >
> > Third, I believe that the authors assume that clients perform validation
> > of the TSA certificate chain using the appropriate policy value.  This
> > is standard X.509 processing.  However, it would be better to state the
> > requirement (briefly) in the time-stamp draft.
> >

--------------99A34F553A827CBE84FD02B6
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------99A34F553A827CBE84FD02B6--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24429 for ietf-pkix-bks; Tue, 25 May 1999 11:40:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24425 for <[e-mail]>; Tue, 25 May 1999 11:40:57 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA07800; Tue, 25 May 1999 14:41:28 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a04b3709e767a28@[128.89.0.110]>
In-Reply-To:  <[e-mail]>
Date: Tue, 25 May 1999 14:41:32 -0400
To: "Ellison, Carl M" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl,

I agree that the only safe way to bind an attribute cert to an identity
cert is via the public key hash. That's what I always recommend to my
clients.

Look at the draft profile for attribute certs recently published by Stephen
Farrell and it's easy to locate the key hash as pointer.  The real
difference here is that X.509 believes that certs with public keys should
contain a name that is not purely a local matter.

The hash is the most secure way to bind an attribute (yes, "authorization"
is a better name) cert to the identity cert, and I'll suggest that we
mandate it in our profile as we progress.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24408 for ietf-pkix-bks; Tue, 25 May 1999 11:37:54 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA24404 for <[e-mail]>; Tue, 25 May 1999 11:37:53 -0700 (PDT)
Received: 	id OAA20781; Tue, 25 May 1999 14:33:05 -0400
Received: by gateway id <LMML9ZNZ>; Tue, 25 May 1999 14:35:29 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Subject: RE: Comments on time-stamp-01: Identification of TSA
Date: Tue, 25 May 1999 14:35:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The tsa field within the token is present to allow end users to obtain the
identity of the supposed TSA without requiring them to obtain the TSAs
certificate.  Considering that the tokens created by a TSA will be used for
non-repudiation in situations very removed (in time and space) from those in
which they were created, it may be useful to be able to refer to the token
with serial number XXXXX from TSA YYYYY, without the only method of
identifying the TSA being their subjectKeyIdentifier (or
issuerAndSerialNumber).

The ESSCertiID Attribute was added, as an option, upon the specific request
of Denis Pinkas.  I don't recall the arguments for it, so I will allow him
to respond directly.

	Robert.

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, May 24, 1999 4:53 PM
> To: 	[e-mail]
> Subject: 	Comments on time-stamp-01: Identification of TSA
> 
> <<File: thayes.vcf>>
> The current time-stamp draft contains several places that define fields
> or recommend use of previously defined fields to identify the TSA
> creating the token.  I believe that the draft provides too many ways to
> do this, which will work against creation of interoperable
> implementations.  In addition, I believe that some of the current
> options are motivated by concerns that are better addressed in other
> ways.
> 
> First, the protocol uses a CMS SignedData object as the basic form of
> the time-stamp token.  This object allows identification of the signer
> in the SignerInfo section.  This data is sufficient to locate the
> correct certificate, build the chain and validate TSA's identity.  This
> should be the primary (and possibly only) method of identifying the TSA
> that generated the token.  However, the current draft goes on to mention
> several other identification fields.
> 
> The draft contains the following text:
> 
>      The purpose of the tsa field is to identify the name of the
>      TSA.  If present, it MUST correspond to one of the subject
>      names included in the certificate that is to be used to verify
>      the token.  This field MAY be omitted if the Signing
>      Certificate Attribute has been included as a signed
>      attribute.  (See Section 5 of [ESS].) It MUST be present if
>      the ESSCertID Attribute is not used to identify the TSA.
> 
> 'tsa' is an optional GeneralName field defined within the TSTInfo
> sequence.  Because it is optional, it cannot be relied upon to locate
> the proper certificate needed to verify the token.  It may be useful to
> locate the certificate if a verifier files certificates using values
> other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
> TSA would need to know what other types of GeneralName might be useful
> to a client.  The 'tsa' field does have one difference from the
> SignerInfo fields - it is signed with the message.  This has some
> significance for some attacks on the protocol, which I'll discuss later.
> 
> The 'substitution attack' ([ESS]) is prevented for TSA signatures in two
> ways.  First, the key used for signing time-stamp tokens is required to
> be used only for that purpose.  This means that existence of a second
> certificate (with different capabilities) for the same key is already
> prohibited by the draft.  Second, the token also contains a
> PolicyIdentifier that is effect for the signature.  The verifier must
> check that the certificate chain allows this policy to be used.  This
> requirement prevents a second certificate (with different
> PolicyIdentifier values) from being used to check the signature.  In
> fact, the policy identifiers in the SigningCertificate sequence of [ESS]
> duplicate the value already found in the token.
> 
> Finally, the time-stamping draft expresses concern for attacks that may
> occur when the CA does not perform proof-of-possession checks on the TSA
> key.  To counter these, the draft encourages use of the fields mentioned
> above (including the tsa field, and the SigningCertificate attribute)
> which are included within the token signature.  This prevents a
> substitution attack where the substitute certificate is for an entirely
> different subject name.  However, since other drafts will address these
> attacks during the certificate enrollment process (the CMC draft
> contains proof-of-possession protocol), I think the time-stamp protocol
> should not define its own mechanisms for dealing with the problem.
> 
> In summary, there are too many ways to identify the TSA certificate.  We
> should use the basic CMS SignerInfo for this data.  Attacks (as listed
> in [ESS]) Concerns about proof-of-possession flaws should be addressed
> elsewhere, specifically in the certificate request process.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24156 for ietf-pkix-bks; Tue, 25 May 1999 11:29:33 -0700 (PDT)
Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24152 for <[e-mail]>; Tue, 25 May 1999 11:29:32 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA12523 for <[e-mail]>; Tue, 25 May 1999 11:29:39 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FCAWPF00.UCX; Tue, 25 May 1999 11:29:39 -0700 
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 11:29:31 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: "'Jose A. Manas'" <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------799A85F8981DC9FB001101AC"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------799A85F8981DC9FB001101AC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert,

My response may have been less-than-clear on two points.  First, the modified
protocol does NOT contain an error value in the TimestampToken.  Errors are
limited to the second type of response.  This is very different from the current
draft, which produces data that "looks" like a token, but is not valid since an
error value is set within it.

Second, I intended to describe the changes to the current draft in two phases -
a protocol that returns tokens or UNauthenticated errors, and then a better
protocol that provides authentication for the error values (to prevent
spoofing).  The bullet you refer to is meant to describe the first phase, and is
what I intended.

To expand:  this first phase of changes to the current draft protocol could also
allow the server to quietly discard requests that generate an error.  This might
be an appropriate response when the service is provided over email, or UDP
channels.  This possibility also falls in to the realm of unauthenticated
responses, since there is no verifiable response from the server to indicate the
request was denied.

Also, when the second phase of changes is applied (to add authenticity to the
errors), you can choose to allow (or require) a different certificate to be used
to sign the error values.  This is also different than the current proposal.
I'm not convinced it is necessary since the content-type OID in the SignedData
will clearly indicate the response is not a real time-stamp token, but some
people may feel more comfortable signing with a different key (and certificate)
in this case.

Terry

Robert Zuccherato wrote:

> Perhaps I am missing something, but besides a new syntax for the error
> message, how is this substantially different than what we have in the
> present draft?  (I assume that your second bullet should read "an
> authenticated error message", based on your description below.)
>
> > ----------
> > From:         [e-mail][SMTP:[e-mail]]
> > Reply To:     [e-mail]
> > Sent:         Friday, May 21, 1999 10:12 PM
> > To:   Robert Zuccherato
> > Cc:   'Jose A. Manas'; [e-mail]
> > Subject:      Re: Comments on draft-ietf-pkix-time-stamp-01.txt
> >
> > <<File: thayes.vcf>>
> > Robert Zuccherato wrote:
> >
> > > How can we do this (separate transient data from long-lived data) and
> > still
> > > maintain simplicity and security?
> >
> > I don't think this is too hard to do.  First, define the basic (low-level)
> > operation of the protocol as a request, followed by one of two responses:
> >
> >    * a TimestampToken
> >    * an unauthenticated error message
> >
> > The error message will need the nonce and/or imprint fields to tie it to
> > the
> > original request. (I won't define that type here)
> >
> > You can run the protocol like this (or just not respond for errors).  As
> > you
> > have pointed out, this is subject to denial-of-service attacks.
> >
> > So now add another level of protocol that packages sends either the token,
> > or a
> > signed version of the error message.
> >
> >      BetterTSAResponse ::= CHOICE {
> >        [0] tsatoken TimestampToken,
> >        [1] authenticatedError SignedData
> >      }
> >
> > The SignedData will contain a TSAErrorResponse type and you'll need an OID
> > to
> > indicate that (id-ct-TSTError).  You can adopt the same rules for
> > validating
> > the signer of this data as you did for TimestampToken (allowing the TSA to
> > sign
> > its error messages), or you can define different requirements altogether.
> >
> >
> >

--------------799A85F8981DC9FB001101AC
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------799A85F8981DC9FB001101AC--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23852 for ietf-pkix-bks; Tue, 25 May 1999 11:17:34 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA23848 for <[e-mail]>; Tue, 25 May 1999 11:17:33 -0700 (PDT)
Received: 	id OAA11677; Tue, 25 May 1999 14:09:54 -0400
Received: by gateway id <LMML9ZH8>; Tue, 25 May 1999 14:12:18 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: Comments on time-stamp-01: Use of PolicyInformation
Date: Tue, 25 May 1999 14:12:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would agree that the issue of time stamping policy and time stamping
practice statements are important ones that will need to be solved for
interoperability.  However, I really don't think that including descriptions
of policies and practice statements within this draft is a good idea.  For
this issue to be addressed properly, a document similar to RFC 2527 should
be produced for TSAs.  I could include a short list suggesting some of the
issues that should be covered by a TSAs policy.

Regarding the definition of a standard policy OID in this document.  I think
that coming to agreement on the meaning of such an OID would be a challenge
and that in the end it would be an OID that basically meant nothing.  I
don't think that we even define a default certificate policy OID in PKIX.

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Monday, May 24, 1999 2:56 PM
> To: 	[e-mail]
> Subject: 	Comments on time-stamp-01: Use of PolicyInformation
> 
> <<File: thayes.vcf>>
> I have some questions/comments on the use of PolicyInformation in the
> proposed time-stamping protocol.
> 
> First, a PolicyInformation field is required in the TSTInfo (response)
> data structure, but no standard policy OID is defined by this draft.  To
> allow interoperability, there should be at least one standard OID
> defined (with appropriate definition, see following).  An alternative to
> this is to make the policy field in the response optional.  This would
> indicate that the response is delivered under some standard (minimum)
> policy, or that the policy is as agreed between the client (or CA) and
> the TSA.
> 
> Second, the draft needs to indicate (or suggest) what types of
> information (guarantees?) are carried by the policy.  I can think of
> several:
> 
>    * indicate method used to define valid message imprint digests.  The
>      TSA would be guaranteeing that the digest was considered usable at
>      the time of the time-stamp.
>    * indicate the availability of a time-stamp log, to allow later
>      verification that a time-stamp token is authentic.
>    * indicate certification of the timestamp accuracy (by some third
>      party?)
> 
> Since there is no discussion in the draft on what the "policy" field
> might represent, it will be difficult to build interoperable clients and
> servers.  I suggest that a standard OID should indicate:
> 
>    * The TSA checks digests against a current list of acceptable digests
>      defined by RFC/standard - either the time-stamp document itself, or
>      a separate document that is updated to follow the latest
>      technology.
>    * A qualifier indicates whether the TSA logs time-stamps and can
>      provide access to logs if needed for arbitration purposes.
> 
> Third, I believe that the authors assume that clients perform validation
> of the TSA certificate chain using the appropriate policy value.  This
> is standard X.509 processing.  However, it would be better to state the
> requirement (briefly) in the time-stamp draft.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23057 for ietf-pkix-bks; Tue, 25 May 1999 10:55:07 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23053 for <[e-mail]>; Tue, 25 May 1999 10:55:06 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA21090; Tue, 25 May 1999 10:51:37 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 25 May 1999 13:52:36 -0400
To: "Ellison, Carl M" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Cc: Carl Ellison <[e-mail]>, Ari Huttunen <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Carl.

[snip]

>> >3.	X.509 may be able to define SDSI names, but there is no 
>> mechanism for 
>> >referring to a fully qualified SDSI name.  That means that the only
>
>> >mechanisms for making an SPKI attribute certificate (one 
>> that gives an 
>> >authorization to a named entity or group) have to rely on 
>> assumptions about 
>> >naming conventions.  In particular, I see no way to express:
>> >
>> >	(name <key> N_1 N_2 ... N_k)
>> >
>> >in X.509.
>> 
>> The  X.509 public key certificate provides (name <key>).
>> 
>> The X.509 ACs could provide (name N_1), (name N_2 N_3), ... 
>> (name N_k).
>> Where a collection of ACs each contain one or more attributes.
>
>I don't believe you're talking about the same thing I am, Russ.
>
>Unless something has been added very recently to X.509 to accommodate
>this, the spec does not permit me to use a list of the root key plus
>all names in the certificate chain down to the leaf name and use that
>list as the subject of an AC.  Have I missed something?

Maybe we did miscommunicate.  I assumed that N_1 .. N_k were attributes
that you wanted to bind to name.

Russ




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23046 for ietf-pkix-bks; Tue, 25 May 1999 10:54:01 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA23027 for <[e-mail]>; Tue, 25 May 1999 10:53:57 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 0725677C.006227C6 ; Tue, 25 May 1999 10:52:07 -0700
X-Lotus-FromDomain: BULL
To: Anders Rundgren <[e-mail]>
cc: PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 10:52:44 -0700
Subject: RE: Unsettled topics, Qualified Certificates.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

i disagree entirely with your statement that "Certificate policy could
specify liability but that does not have anything to do with the sums you
transact or protect." certificates state how they are to be used. key usage
is a simplified statement of the constraint on a certificate's use. the
certificate's policy also describes how the certificate is to be used and
allows that description to be more precise than key usage. (when this stuff
was being defined, i argued that we did not need key usage but a set of
standardized policies instead. the others agreed in concept but felt key
usage would be more readily deployable in the start-up phase. )



certificate policy is intended to control the use to which a certificate
can be put. liability issues are a strong factor in determining that
constraint but liability need not be specified in the cp. i suspect that
you may be confused about the difference between cp and cps



i don't understand your statement "Of course you can have any number of
optional items but if people start to actually use them you will pretty
soon run into severe problems." qualifiers are associated with a specific
policy. if an implementation (or a human user), understands the policy, it
must understand the qualifiers that are associated with that policy. i
agree that a policy with a large number of qualifiers and complex
interworking may be difficult to deploy, but not more difficult than
supporting the large number of policies each of which embody the one of the
combinations of qualifiers and qualifier values within the policy itself.



on your recommendation to "ignore", i think such implementors would have a
difficult day in court when being questioned about the conformance of their
product to the accepted business practice. i believe that the courts would
consider EU regulation as a strong guideline to the acceptable business
practice.

Where law and technology intersect, the engineers "yes/no" view must adapt
to the court's "maybe" view. the policies and guidelines may not be perfect
and they are sure to be refined by case law. but i would like to have as
good a technological stake in the ground as possible rather than having
some judge start with a blank page when determining the acceptablity of a
digital signature.

     hoyt





Anders Rundgren <[e-mail]> on 05/25/99 08:35:59 AM

To:   PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
cc:    (bcc: Hoyt Kesterson/US/BULL)
Subject:  RE: Unsettled topics, Qualified Certificates.




Stefan,

<snip>
>Issue 2) Storage of maximum value per transaction.

>The directive requires that a certificate, if applicable, shall contain
>information about a maximum monetary amount per transaction that the
>certificate should support.

My comment to this is that the EU directive seems to try to solve all
business problems with
certificates.  This is IMO a bad idea and will only delay things.

Let's say that you open a door with a cert.  How can you possibly say how
much value you have behind the door?

And what is the true value of a signed business contract?

For monetary transactions it is up to the relying party (the bank, the
selling organization) to
set proper limits and to your organization as well.  To do this in a static
certificate
(probably issued by a TTP) is lunacy.

>This could be done by defining a new extension (like the Germans already
>have done in their interoperability specifications), or alternatively just
>say that this shall be solved by a certificate policy, possibly in
>combination with a policy qualifier.

Certificate policy could specify liability but that does not have anything
to do
with the sums you transact or protect.

>Arguments has been raised that Policy qualifiers are not suitable for
>automatic interpretation but that is not confirmed.

Of course you can have any number of optional items but if people start to
actually use them you will pretty soon run into severe problems.

So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep some
people happy) but
just IGNORE them in real implementations.  This is the proper (only) way to
handle EU bureaucracy :-)  :-)

Anders Rundgren
http://www.mobilephones-tng.com








Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22743 for ietf-pkix-bks; Tue, 25 May 1999 10:43:46 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA22731 for <[e-mail]>; Tue, 25 May 1999 10:43:37 -0700 (PDT)
Received: 	id NAA00493; Tue, 25 May 1999 13:38:41 -0400
Received: by gateway id <LMML9ZA6>; Tue, 25 May 1999 13:41:06 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'Jose A. Manas'" <[e-mail]>, [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Tue, 25 May 1999 13:41:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Perhaps I am missing something, but besides a new syntax for the error
message, how is this substantially different than what we have in the
present draft?  (I assume that your second bullet should read "an
authenticated error message", based on your description below.)

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Friday, May 21, 1999 10:12 PM
> To: 	Robert Zuccherato
> Cc: 	'Jose A. Manas'; [e-mail]
> Subject: 	Re: Comments on draft-ietf-pkix-time-stamp-01.txt
> 
> <<File: thayes.vcf>>
> Robert Zuccherato wrote:
> 
> > How can we do this (separate transient data from long-lived data) and
> still
> > maintain simplicity and security?
> 
> I don't think this is too hard to do.  First, define the basic (low-level)
> operation of the protocol as a request, followed by one of two responses:
> 
>    * a TimestampToken
>    * an unauthenticated error message
> 
> The error message will need the nonce and/or imprint fields to tie it to
> the
> original request. (I won't define that type here)
> 
> You can run the protocol like this (or just not respond for errors).  As
> you
> have pointed out, this is subject to denial-of-service attacks.
> 
> So now add another level of protocol that packages sends either the token,
> or a
> signed version of the error message.
> 
>      BetterTSAResponse ::= CHOICE {
>        [0] tsatoken TimestampToken,
>        [1] authenticatedError SignedData
>      }
> 
> The SignedData will contain a TSAErrorResponse type and you'll need an OID
> to
> indicate that (id-ct-TSTError).  You can adopt the same rules for
> validating
> the signer of this data as you did for TimestampToken (allowing the TSA to
> sign
> its error messages), or you can define different requirements altogether.
> 
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22465 for ietf-pkix-bks; Tue, 25 May 1999 10:29:54 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA22461 for <[e-mail]>; Tue, 25 May 1999 10:29:53 -0700 (PDT)
Received: from mcg.org.br (pm07-14.sac.verio.net [209.162.65.33]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id KAA09473; Tue, 25 May 1999 10:30:22 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 10:21:08 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Bob Blakley <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: Certificate life-cycle costs.
References: <015f01bea3c7$a3518280$[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:

> Ed,
>
> Not to disagree with your most general findings, but in the case
> of "purely dependent" attributes (purely redundant, perhaps) I
> cannot see how the formula is to work.

Tony:

It might seem like you have answered your question yourself. "Purely
dependent" or "purely redundant" attributes are, as you say, purely
dependent. In other words, 100% redundant terms carry no
additional information. Thus, there is no sense in distinguishing among
them if they are indeed 100% redundant. So, they should NOT be
included in the equation  -- this is the simple answer.

Why? Because the equation 1/T = 1/T1 + .. +1/TN was derived *for
each* attribute that can be *recognized*. In other words, if there is no
information (surprise) for an attribute, it must not be counted -- since it
was already counted.

However, and here lies a subtle point, the measurement of information
(hence, redundancy) depends on the observer -- as I will show using
your own example below.

> To abstract/simplify Bob Blakeley's example further, I consider
> the possible lifetime of my own first name (Anthony).  Let it's
> lifetime be given by L, in some formulation.
>
> Consider certifying my following attributes:
>
> 1.  First Name = "Anthony"
>
> 2.  First Name Writ Backward = "ynohtnA"
>
> 3.  First Name all in caps = "ANTHONY"
>
> etc.  I suppose I could go on for several hundred such "attributes"
> if I had to.  And yet I cannot see how the lifetime of the collection
> could be different from the lifetime of the first.  Indeed, they are
> really one attribute presented as many.

Fine,  if you say they are only one attribute to you, then do count
them just as one -- since you trust them to be only one. As you may
note, you have already provided the correct answer according to
your reference frame.

Now,  let me see this from a different reference frame -- a different
observer. After all, a certificate from you to yourself is not very much
useful -- you *want* it to be interpreted by others.

First, let me note that you have constructed 3 examples that are
syntactically different but which you, in your own trust basis, connected
to the same sense (meaning the common name "ANTHONY") and to
the same entity (you).

But you may agree that another observer, in another trust basis, may
connect those 3 examples to completely *different* meanings and even
completely *different* entities. In fact, a different observer may connect
all hundreds of different syntactic variations that *you* associate with
"your name" and with "yourself", to completely different meanings
and entities.

For example, if those 3 attributes were to be interpreted as three different
things as viewed from your computer (as the observer):

1. "Anthony" is your login
2. "ynohtnA" is your initial password
3. "ANTHONY" is your email address at the maihost.

Now, of course, each one of them has a different meaning and denotes
a different entity to the observer (the computer) -- and each one is also
quite independent in their lifetimes. For example, a hacker can easily
change your password at your computer but may not be able to easily
change your e-mail address at the mailhost (which, suppose, has a
higher security). Knowing this, you would also be entirely justified to
assign a longer lifetime to the third attribute when compared to the first.
And, as usual, you will want to assign a much shorter lifetime to the
second attribute, your password.

Thus, this somewhat contrived example is simply based on the often
neglected fact that redundancy (as well as information) depends on the
observer. As I commented to you once, in another thread, and exemplified
that randomness also depends on the observer.

Therefore, since a certificate's attributes must be relied upon by different
observers, you must take this aspect into account when you design
a certificate and calculate its a priori lifetime -- in other words, its expected
validity period as you (the issuer) define it. Which is one of the things that
the equation I derived allows you to do, when you are taking into account all
attributes that you can *recognize* as significant to that certificate's validity.

Which could (possibly, must) include sub-attributes as I commented in my
replies to Bob J. and Peter -- though they may NOT be visible at all in the
certificate itself.

> Easy to see that in this
> particular case, but how to recognize such in general?

Clearly, if I am only basing my certificate validity choices on syntax then
I would be only talking about attribute *equality* and comparing strings
-- for example, if the strings match byte by byte, then they are equal and
should NOT be included in the lifetime equation more than once.

And, this is the case for PKIX standard usage -- which is to be supported
by the RFCs themselves, and the issuer's policies. But, as above, there
is more to "equality" than meets the eye of one observer.  It depends, for
example, whether "a PKIX application SHOULD interpret the DN field
as case-sensitive" or if "a PKIX application MUST interpret the DN field
as case-sensitive". Two different "equality" metrics, of many possible.

What makes your question non-trivial *in general terms* is thus that syntax
cannot be self-measured. As we both have discussed elsewhere in trust
theory terms, one needs a trust basis in order to define and recognize
even pure syntax (not to mention semantics and entity denotation). But,
again, *in PKIX terms* one should have a reasonable and coherent answer
to your question by reading the relevant RFCs and issuer's policies.

In summary of all the above, a general answer is possible to your question.
Include in the lifetime equation 1/T = 1/T1+ ...+ 1/TN the lifetimes Tn of
all those attributes which are *different* (whichever way you and all the
relying-parties define by that) regardless whether the lifetimes themselves
are different or not, numerically.

Again, as in my reply to Blakley,  lifetime distance is NOT a measure of
attribute independence.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18174 for ietf-pkix-bks; Tue, 25 May 1999 08:36:36 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18170 for <[e-mail]>; Tue, 25 May 1999 08:36:34 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id RAA05269 for <[e-mail]>; Tue, 25 May 1999 17:37:09 +0200
Received: from HYDRA ([195.198.186.74]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id RAA18115; Tue, 25 May 1999 17:37:08 +0200
Received: by HYDRA with Microsoft Mail id <01BEA6D5.0E476F40@HYDRA>; Tue, 25 May 1999 17:36:01 +0200
Message-ID: <01BEA6D5.0E476F40@HYDRA>
From: Anders Rundgren <[e-mail]>
To: PKIX <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Subject: RE: Unsettled topics, Qualified Certificates.
Date: Tue, 25 May 1999 17:35:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

<snip>
>Issue 2) Storage of maximum value per transaction.

>The directive requires that a certificate, if applicable, shall contain
>information about a maximum monetary amount per transaction that the
>certificate should support. 

My comment to this is that the EU directive seems to try to solve all business problems with
certificates.  This is IMO a bad idea and will only delay things.

Let's say that you open a door with a cert.  How can you possibly say how much value you have behind the door?

And what is the true value of a signed business contract?

For monetary transactions it is up to the relying party (the bank, the selling organization) to
set proper limits and to your organization as well.  To do this in a static certificate
(probably issued by a TTP) is lunacy.

>This could be done by defining a new extension (like the Germans already
>have done in their interoperability specifications), or alternatively just
>say that this shall be solved by a certificate policy, possibly in
>combination with a policy qualifier.

Certificate policy could specify liability but that does not have anything to do
with the sums you transact or protect.

>Arguments has been raised that Policy qualifiers are not suitable for
>automatic interpretation but that is not confirmed.

Of course you can have any number of optional items but if people start to
actually use them you will pretty soon run into severe problems.

So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep some people happy) but 
just IGNORE them in real implementations.  This is the proper (only) way to handle EU bureaucracy :-)  :-)

Anders Rundgren
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA16904 for ietf-pkix-bks; Tue, 25 May 1999 08:00:40 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16898 for <[e-mail]>; Tue, 25 May 1999 08:00:36 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA01442; Tue, 25 May 1999 11:00:51 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA01438; Tue, 25 May 1999 11:00:50 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA13959; Tue, 25 May 1999 11:00:55 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA09190; Tue, 25 May 1999 10:58:47 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 25 May 1999 10:58:47 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
To: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: DpwyXPcYSamHb8iYReGFhw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Ellison, Carl M" <[e-mail]>
> 
> Perhaps I used the wrong word.  The fact remains that the code that
> interprets a full X.509 certificate (including all extensions) needs
> to be aware of (to embody) the definitions found in some paper
> document.  This is by contrast with SPKI certificates that can be
> processed through tuple-reduction without any special knowledge about
> such paper documents.  That is why SPKI can have a single Trust Policy
> engine while X.509 requires a different one for each application (in
> the limit, for each root key).

There are only two places that the policy written in a paper document
can be understood/interpreted/enforced - in applications and in the
user's brain.  To the extent that application engines perform automated
reduction, the user's workload (and ability to make mistakes) is
reduced.

Claiming that SPKI "can have" a single engine while X.509 "requires" a
different one for each root is one way of spinning it. But I would say
SPKI permits only a single engine, whereas X.509, which defines no
authorization mechanism itself, provides extensions identified by OIDs
which can select the engine to be used.  Automated authorization is not
a mature field; there are numerous candidates:  NIST's Role Based
Access Control, SPKI tuples, Novell's Security Attributes, the DoD's
SDN.801, and many others.  In 10 years, perhaps everyone will agree
that SPKI tuple-reduction is a suitable mechanism for automated
authorization decisions, and everyone's X.509 root cert will have an
extension that specifies an SPKI tuple reduction engine in conjunction
with some application-domain-specific parameters.

As for human-interpreted policy processing, one size will never fit
all.  VeriSign has 4 public assurance classes, the U.S. DoD defines 5
classes although only 2 are presently used, and other governments and
organizations have multiple CPs.  Harmonization (and elimination of
policy mapping) would be great, but it won't happen quickly, if ever.
Policy Qualifiers can be used to advertise quantitative information
such as Reliance Limits from the issuer to the RP, but if the intent is
automated processing rather than simply displaying information to the
user, I believe a different extension, specifying a "standard engine"
should be used.  The fewer engines applications have to support, the
better, but I don't think the market is yet convinced that SPKI tuples
are capable of supplanting RBAC, DoD PRBAC/LRBAC, other chaining
mechanisms, and plain old ACLs for all public-key-based authorization
applications.

That is why X.509 allows a choice of engines, including "display this
to the user", messy though the choice may be.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA15226 for ietf-pkix-bks; Tue, 25 May 1999 07:17:40 -0700 (PDT)
Received: from hq.capu.net (hq.capu.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA15222 for <[e-mail]>; Tue, 25 May 1999 07:17:39 -0700 (PDT)
Received: from ieca.com (mva-aa-061.capu.net [207.226.159.61]) by hq.capu.net (8.8.8/8.8.5) with ESMTP id KAA21752; Tue, 25 May 1999 10:18:09 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 25 May 1999 10:15:41 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.6 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Darren Harter <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: RFC2459 - CRL signature verification?
References: <01BEA695.FA647CA0@DHARTER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Darren,

Thanks for the response.  I guess I was looking for an explicit statement of the need to verify the signature on the CRL (assuming of course you implement them, etc.).

Cheers,

spt

Darren Harter wrote:

> Sean,
>
> The closest I can find is:
>
> "10  Security Considerations
>
>    ....  Since certificates and CRLs are
>    digitally signed, no additional integrity service is necessary.
>    ...".
>
> But that's only an implicit 'check the signature'.
>
> Also, 7.2.2 says the following is id-dsa-with-sha1 appears in an AlgorithmIdentifier:
>
>  "The DSA parameters in the subjectPublicKeyInfo field of the
>    certificate of the issuer shall apply to the verification of the
>    signature".
>
> But again you could argue that that means IF you bother to check the signature then you SHALL use the key in the issuer's cert.
>
> All that said, would you ever use untrusted information when making a security relevant decision?  IMHO, you'd be safer to not check for revocation at all than to use a CRL that you've not checked the signature on.  Otherwise, your application will be wide open for denial of service attacks.
>
> I think the authors have probably taken the common sense assumption that applications will check the signatures of signed objects UNLESS they have received them from a trusted source.
>
> Hope this helps,
>
> Regards,
>
> Darren
>
> ------------------------------------------------------------------------
> Darren Harter BSc (Hons) CEng MBCS
> Entegrity Solutions Corp
> http://www.entegrity.co.uk
> http://www.entegrity.com
> Tel:  [phone]
> Fax: [phone]
> Cell: [phone]
> Email: mailto:[e-mail]
>
> -----Original Message-----
> From:   Sean Turner [SMTP:[e-mail]]
> Sent:   Tuesday, May 25, 1999 4:32 AM
> To:     PKIX
> Subject:        RFC2459 - CRL signature verification?
>
> All,
>
> I've been searching through RFC2459 looking for text that says something
> about verifying the signature on the CRL.
>
> Clause 3.3 (2nd paragraph) says:
>
> When a certificate-using system uses a certificate (e.g., for verifying
> a remote user's digital signature), that system not only checks the
> certificate signature and validity but also acquires a suitably-recent
> CRL and checks that the certificate serial number is not on that CRL.
>
> But it stops short of saying 'check the signature on the CRL.' Can
> somebody tell me where the requirement to verify the signature on the
> CRL before using it is stated? (and to check to see that the right CA
> signed it, etc.)
>
> Thanks,
>
> spt



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA13311 for ietf-pkix-bks; Tue, 25 May 1999 05:41:05 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA13306 for <[e-mail]>; Tue, 25 May 1999 05:41:02 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id OAA14861 for <[e-mail]>; Tue, 25 May 1999 14:42:55 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 25 May 1999 14:41:41 +0200
To: PKIX <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Unsettled topics, Qualified Certificates.
In-Reply-To: <01BEA695.FA647CA0@DHARTER>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA13307
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We have had an internal debate regarding what has to be done in order to
allow us to use the Qualified Certificates profile to construct a
certificate that fulfills the European directive on electronic signatures.

We have two issues that we can't agree on and would like to have help from
the list.

Issue 1) Identification of pseudonym names stored in commonName

The directive requires that a pseudonym "identified as such" can be used as
part of the subjects name in a certificate.

The question is if a pseudonym stored in a commonName attribute in the
subject field should include some information that the attribute contains a
pseudonym. e.g. CN="<pseudonym>Bill Clinton" in order to alert the relying
party that the name is not a real name but a pseudonym.

The alternative is to allow pseudonym name in the commoName with no other
identification of the name semantics than what is implicitly defined by an
indicated certificate policy and/or it's qualifier(s).




Issue 2) Storage of maximum value per transaction.

The directive requires that a certificate, if applicable, shall contain
information about a maximum monetary amount per transaction that the
certificate should support. 

This could be done by defining a new extension (like the Germans already
have done in their interoperability specifications), or alternatively just
say that this shall be solved by a certificate policy, possibly in
combination with a policy qualifier.

Arguments has been raised that Policy qualifiers are not suitable for
automatic interpretation but that is not confirmed.



We need reactions from mainly potential implementors. What possibilities,
problems do you see with the alternatives outlined in this mail??

Please let us know. 


/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA04957 for ietf-pkix-bks; Tue, 25 May 1999 02:04:19 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA04953 for <[e-mail]>; Tue, 25 May 1999 02:04:17 -0700 (PDT)
Received: from DHARTER (d3-s37-197-telehouse.mistral.co.uk [195.184.228.197]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id JAA21833; Tue, 25 May 1999 09:03:57 +0100
Received: by DHARTER with Microsoft Mail id <01BEA695.FA647CA0@DHARTER>; Tue, 25 May 1999 10:04:29 +0100
Message-ID: <01BEA695.FA647CA0@DHARTER>
From: Darren Harter <[e-mail]>
To: "'Sean Turner'" <[e-mail]>, PKIX <[e-mail]>
Subject: RE: RFC2459 - CRL signature verification?
Date: Tue, 25 May 1999 09:55:29 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA04954
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sean,

The closest I can find is:

"10  Security Considerations

   ....  Since certificates and CRLs are
   digitally signed, no additional integrity service is necessary.
   ...".

But that's only an implicit 'check the signature'.

Also, 7.2.2 says the following is id-dsa-with-sha1 appears in an AlgorithmIdentifier:

 "The DSA parameters in the subjectPublicKeyInfo field of the
   certificate of the issuer shall apply to the verification of the
   signature".

But again you could argue that that means IF you bother to check the signature then you SHALL use the key in the issuer's cert. 

All that said, would you ever use untrusted information when making a security relevant decision?  IMHO, you'd be safer to not check for revocation at all than to use a CRL that you've not checked the signature on.  Otherwise, your application will be wide open for denial of service attacks.

I think the authors have probably taken the common sense assumption that applications will check the signatures of signed objects UNLESS they have received them from a trusted source.

Hope this helps,

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
http://www.entegrity.com
Tel:  [phone]
Fax: [phone]
Cell: [phone]
Email: mailto:[e-mail]


-----Original Message-----
From:	Sean Turner [SMTP:[e-mail]]
Sent:	Tuesday, May 25, 1999 4:32 AM
To:	PKIX
Subject:	RFC2459 - CRL signature verification?

All,

I've been searching through RFC2459 looking for text that says something
about verifying the signature on the CRL.

Clause 3.3 (2nd paragraph) says:

When a certificate-using system uses a certificate (e.g., for verifying
a remote user's digital signature), that system not only checks the
certificate signature and validity but also acquires a suitably-recent
CRL and checks that the certificate serial number is not on that CRL.

But it stops short of saying 'check the signature on the CRL.' Can
somebody tell me where the requirement to verify the signature on the
CRL before using it is stated? (and to check to see that the right CA
signed it, etc.)

Thanks,

spt



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA01902 for ietf-pkix-bks; Tue, 25 May 1999 00:11:12 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA01898 for <[e-mail]>; Tue, 25 May 1999 00:11:10 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 0725677C.0027464E ; Tue, 25 May 1999 00:08:59 -0700
X-Lotus-FromDomain: BULL
To: Russ Housley <[e-mail]>
cc: Carl Ellison <[e-mail]>, Ari Huttunen <[e-mail]>, [e-mail], [e-mail], Carl Ellison <[e-mail]>, Carl Ellison <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 24 May 1999 23:55:10 -0700
Subject: Re: X.509 ACs vs. SPKI?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

i beleive that russ's comments are overly restricting the third of the
three binding methods. the hash does not have to be of a public key. it
could be the object digest of any object, e.g. as an applet.  for example,
object x which hashes to y has been assigned z priviliges.

this is stated in 13.7 of the FPDAM after the asn.1

   hoyt




Russ Housley <[e-mail]> on 05/24/99 01:57:30 PM

To:   Carl Ellison <[e-mail]>
cc:   Ari Huttunen <[e-mail]>, [e-mail],
      [e-mail], Carl Ellison <[e-mail]>, Carl Ellison
      <[e-mail]> (bcc: Hoyt Kesterson/US/BULL)
Subject:  Re: X.509 ACs vs. SPKI?




At 09:22 AM 5/12/99 -0700, Carl Ellison wrote:
>[snip]
>
>I see three problems doing the equivalent of SPKI within X.509 and in
>particular with ACs.
>
>1.  The identification of issuer and subject is convoluted at best.
Missing
>is the option that is needed for maximum security (not to mention
>anonymity): a public key or the hash of the key.  The IssuerSerial option
is
>subject to constraints not expressed in the certificate.  GeneralNames
isn't
>constrained or defined, AFAIK, in this spec, so that too depends on
>constraints not evident in the certificate.  The ObjectDigestInfo might be
>used to refer to some public key, but that use isn't spelled out -- and
even
>then, it is only the subject ID that has this option so identification of
>the Issuer is left troubled.

X.509 ACs offer three methods of binding the attributes to an owner.  They
each offer different advantages and disadvantages.

     (1) Issuer Distinguished Name and Serial Number.  This binds the
attributes to a particular X.509 public key certificate.

     (2) Subject Distinguished Name.  This binds the attributes to a
collestion
of certificates that were issued to the same subject, perhaps by different
CAs.

     (3) Hash of the Public Key.  This binds the attributes to any
certificate
that contains the correct public key.

It is clear how (1) and (2) can be used.  And, (3) seems to provide what
Carl is looking for.  Right?  If so, maybe you can help flesh out that part
of the Internet-Draft.

>2.  X.509 does not define the semantics of a certificate, only the syntax.
I
>find this especially when mapping out the CDSA extensions that extract
SPKI
>authorization information from existing X.509 certificates (so that our
>implementation will accept and use a mixture of certificate types: X.509,
>PGP, SPKI, ....).  Interpreting an X.509v3 certificate requires a
different
>trust policy module (in CDSA terms -- the code module that understands the
>semantics of each field) for each different CPS -- or, to an
approximation,
>for each different root key.  For example, SET cardholder certificates
>define an authorization (permission to use a given PAN/EXP) but plant that
>authorization in the CommonName field of the SubjectName.  Meanwhile, some
>extensions of the SET certificate carry authorization information while
>others are to be used for chain validation only.

There should be common syntax and semantics for base certificate fields.
Certainly any private extension could be an issue.

I think that the semantics should be the same for any certificate issued
under the same Certificate Policy (CP), regardless of the Certification
Practice Statement (CPS) used by a particular CA.

>3.  X.509 may be able to define SDSI names, but there is no mechanism for
>referring to a fully qualified SDSI name.  That means that the only
>mechanisms for making an SPKI attribute certificate (one that gives an
>authorization to a named entity or group) have to rely on assumptions
about
>naming conventions.  In particular, I see no way to express:
>
>    (name <key> N_1 N_2 ... N_k)
>
>in X.509.

The  X.509 public key certificate provides (name <key>).

The X.509 ACs could provide (name N_1), (name N_2 N_3), ... (name N_k).
Where a collection of ACs each contain one or more attributes.

Russ






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA25288 for ietf-pkix-bks; Mon, 24 May 1999 20:33:35 -0700 (PDT)
Received: from hq.capu.net (hq.capu.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA25284 for <[e-mail]>; Mon, 24 May 1999 20:33:33 -0700 (PDT)
Received: from ieca.com (mva-aa-076.capu.net [207.226.159.76]) by hq.capu.net (8.8.8/8.8.5) with ESMTP id XAA11886 for <[e-mail]>; Mon, 24 May 1999 23:34:03 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 24 May 1999 23:31:35 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.6 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: RFC2459 - CRL signature verification?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I've been searching through RFC2459 looking for text that says something
about verifying the signature on the CRL.

Clause 3.3 (2nd paragraph) says:

When a certificate-using system uses a certificate (e.g., for verifying
a remote user's digital signature), that system not only checks the
certificate signature and validity but also acquires a suitably-recent
CRL and checks that the certificate serial number is not on that CRL.

But it stops short of saying 'check the signature on the CRL.' Can
somebody tell me where the requirement to verify the signature on the
CRL before using it is stated? (and to check to see that the right CA
signed it, etc.)

Thanks,

spt



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA22536 for ietf-pkix-bks; Mon, 24 May 1999 19:55:28 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA22448 for <[e-mail]>; Mon, 24 May 1999 19:54:00 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <LPZKDW20>; Tue, 25 May 1999 12:54:22 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BEA1D@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, Ed Gerck <[e-mail]>, Bob Blakley <[e-mail]>
Cc: Bob Jueneman <[e-mail]>, [e-mail]
Subject: RE: Certificate life-cycle costs.
Date: Tue, 25 May 1999 12:54:20 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id TAA22457
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am lost on this one.

I am sure that those who provide products and services that apply
certificate  functionality will work out the deployment costs as part of
the risks, ILS/LCC analysis. As certs may be used for bus tickets,
vehical tags, licences, identity, information integrity, etc, etc.. Its
hard to determine life cycle "costs" without knowing the application -
trust, risk, market share, customer distribution and revenues.. Costs,
be they called high or low are normally determined as a percentage of
revenue...


Whats the context of this?

regards alan
> -----Original Message-----
> From:	Tony Bartoletti 
> Sent:	Tuesday, May 25, 1999 11:04 AM
> To:	Ed Gerck; Bob Blakley
> Cc:	Bob Jueneman; [e-mail]
> Subject:	Re: Certificate life-cycle costs.
> 
> Ed,
> 
> Not to disagree with your most general findings, but in the case
> of "purely dependent" attributes (purely redundant, perhaps) I
> cannot see how the formula is to work.
> 
> To abstract/simplify Bob Blakeley's example further, I consider
> the possible lifetime of my own first name (Anthony).  Let it's
> lifetime be given by L, in some formulation.
> 
> Consider certifying my following attributes:
> 
> 1.  First Name = "Anthony"
> 
> 2.  First Name Writ Backward = "ynohtnA"
> 
> 3.  First Name all in caps = "ANTHONY"
> 
> etc.  I suppose I could go on for several hundred such "attributes"
> if I had to.  And yet I cannot see how the lifetime of the collection
> could be different from the lifetime of the first.  Indeed, they are
> really one attribute presented as many.  Easy to see that in this
> particular case, but how to recognize such in general?
> 
> Comments?
> 
> ___tony___ 
> 
> 
> At 03:37 PM 5/21/99 -0700, Ed Gerck wrote:
> >
> >
> >Bob Blakley wrote:
> >
> >> Ed,
> >>
> >> >> I think this is not quite correct because of imprecise phrasing.
> What I
> >> >> would have said here is
> >> >
> >> >Bob:
> >> >
> >> >This is a simple confusion, as that quote of mine was written to
> Bob
> >> >Jueneman, in regard to Bob Jueneman's comments -- not to Bob
> Blakley
> >> >nor in regard to Bob Blakley's comments ;-) Please check the
> message.
> >>
> >> Actually, it's a more complicated confusion than you imagine!
> >> I did realize that you were answering Bob J.; I was just
> interposing myself
> >> into the discussion!  Name capture creates ambiguities of all sorts
> (type 1
> >> *and* type 2 errors!)
> >
> >Bob and, perhaps, Bob ;-)
> >
> >> >Thus, it will of course NOT apply to what you would have said.
> Hovewer,
> >> >what I wrote is correct -- independently of where it is applied.
> Let me
> >> >prove it:
> >> >
> >> >Suppose, as I said, that each attribute and the key have the same
> lifetime
> >> >"L" -- thus, for N attributes + 1 key, we have:
> >> >
> >> >1/T = 1/L + 1/L + ...+ 1/L +   1/L
> >> >          ^^^^^^^^^^^^^^^       ^^
> >> >             N attributes               1 key
> >> >
> >> >so that:
> >> >
> >> >1/T = N/L + 1/L  => T = L/(1 + N)
> >>
> >> All obviously correct but not on the point I was making, which is
> that there
> >> are situations where, because of a lack of independence, N
> attributes do NOT
> >> give rise to N/L, but instead to only 1/L.
> >
> >I understood your point and I disagreed with it. That is why I
> included
> >two examples which showed that lack of independence is NOT the
> deciding
> >issue to change the result  L/(1+N) to L, but lack of exponential
> decay.
> >And, I also wrote:
> >
> > "... I did not include the word "independent" since the attributes
> do
> >  not have to be independent for the phrase to apply."
> >
> >> An example of this is the following attribute certificate:
> >>
> >>             Attribute 1:    eye-color = gray
> >>             Attribute 2:    blood-type = O positive
> >>             Attribute 3:    name = George Robert Blakley III
> >>
> >> Here all attributes have the same lifetime in the sense in which I
> use the
> >> term - which happens also to correspond to the naive notion of
> "lifetime" you'd see
> >> in the dictionary.  I don't know what L is, but I do know that L1 =
> L2 = L3.
> >
> >The dictionary definition of lifetime is fine, I have no quibbles
> about it.  But
> >because you believe those three attributes *will* have the same
> lifetime, this
> >does NOT mean:
> >
> >1. that they were all created (ie, defined) at the same time
> >2. that they will all end their validity at the same time
> >3. that they are all dependent
> >4. that they will all obey the same validity time-decay law
> >5. that they will all actually have the same lifetime.
> >
> >I hope my previous comment is now clearer.
> >
> >> Now if I add some other attributes:
> >>
> >>             Attribute 4:    hair-color = brown
> >>             Attribute 5:    weight = 150 (well, approximately :)
> >>             Attribute 6:    height = 5'9"
> >>
> >> These all have different L's; Attribute 4 is going to have to be
> changed to
> >> "hair-color = gray" based on some kind of majority-rule algorithm
> pretty
> >> soon now - hopefully before L1 expires!
> >
> >;-) I hope so -- but my 5 comments above apply in reverse to these
> other 3
> >attributes as well, since what you wrote does NOT mean:
> >
> >1. that they were all created (ie, defined) at different times
> >2. that they will all end their validity at different times
> >3. that they are all independent.
> >4. that they will all obey different validity time-decay laws
> >5. that they will all actually have different lifetimes.
> >
> >
> >> > Bob Blakley wrote:
> >> >>
> >> >> Normally when I think of "lifetime" I think of a validity
> interval, and if
> >> >> two things have the same lifetime, they come into existence at
> exactly
> >> > > the same time and cease to exist at exactly the same time.  In
> this case
> >> >> there is no independence whatsoever, and the two things should
> be
> >> >> thought of as essentially one attribute (hence my caveats about
> >> >> independence in earlier notes).
> >> >
> >> >This logic is unfounded. Lifetime is a statistical concept by
> nature -- since
> >> >it pertains to the future and no future is deterministic (it is
> easy to prove
> >> >...
> >>
> >> But I don't think this is really relevant; you can simply re-cast
> the problem
> >> in terms of open intervals to take care of minor nondeterminism
> surrounding
> >> the exact moment of expiry.
> >
> >Still, this does NOT mean that "if two things have the same lifetime,
> they come
> >into existence at exactly [with some minor nondeterminism] the same
> time and
> >cease to exist at exactly [with some minor nondeterminism] the same
> time."
> >
> >As I argued, there is no relationship at all between these events
> that could
> >be inferred from equal lifetimes -- thus, assuming it is unfounded.
> And,
> >this needed generality is at the base of my previous derivation of
> the lifetime
> >equation, as I commented in reference [1] of that posting.
> >
> >Also, recasting the problem in terms of open intervals where "minor
> >nondeterminism" could play a role to define neighborhoods for
> >similar lifetimes does NOT mean that "In this case there is no
> >independence whatsoever, and the two things should be thought of
> >as essentially one attribute (hence my caveats about  independence
> >in earlier notes)."
> >
> >Further, I note that exactly this point of assuming that attributes
> that
> >have the same lifetime are essentially one attribute, and otherwise
> that
> >attributes that have different lifetimes are independent, is at the
> root of
> >David's remarks that questioned the validity of your intuitive
> derivation:
> >
> >DOUBT 3: There is no conventional wisdom about the distribution of
> >attribute lifetimes, but one would venture that it is a discrete, not
> a
> >continuous distribution.  Therefore, one cannot say that  "with
> >probability 1, attribute 2 doesn't expire at t1".
> >
> >DOUBT 4: Possibly, attributes within a single certificate will not
> have
> >pairwise mutually independent lifetimes, so their lifetimes are more
> than
> >likely correlated.
> >
> >DOUBT 5: The question whether pairwise mutual independence is
> sufficient
> >for Bob's formula to hold, or whether the stronger joint independence
> is
> >required.
> >
> >DOUBT 6: The preconditions for Bob's formula to be correct cannot be
> >demonstrated.
> >
> >which I showed were irrelevant because the formula you derived was a
> special
> >case of an equation that did not include any such assumption. So,
> funnywise,
> >my equation supported your formula because it denied the very
> assumption you
> >imposed to derive it ;-)
> >
> >Though I understand you were led to suppose that assumption  in order
> to be
> >able to provide at least an intuitive "proof" for that formula.
> However, the
> >assumption that lifetime distance is a measure of attribute
> independence (as
> >I may recast your assumption) is incorrect and could have led you
> either to
> >no result or to a wrong result if it were consequently applied in a
> >mathematically sound proof.
> >
> >> >The confusion is thus simple -- two things that have the same
> lifetime
> >> >do not have to begin at exactly the same time
> >>
> >> They certainly don't have to, but in many cases they actually DO.
> The
> >> example I gave above is one case; the same information encoded
> >> on a driver's license for me is a derivative which exemplifies
> >> a broad class of certification scenarios from the real world which
> >> also have this property.
> >
> >I disagree. And, there are billions of counter-examples. For example,
> >if men's biological lifetime is 70 years this does not mean that all
> men
> >were born at the same time -- and yet they all have the same
> lifetime.
> >
> >
> >> >> In order to lower the *lifetime* of the certificate, what's
> required is
> >> that
> >> >> attributes expire at *different* times
> >> >
> >> >No, as above. Also, if the attributes have the same lifetime but
> their
> >> >decay rates are non-exponential (eg, a square-function)  then they
> >> >will need to be modeled at least as two exponentials (see my
> former
> >> >workout of David's example) and they will cause different
> reductions
> >> >as compared to the pure exponential case (see my example above)..
> >>
> >> Except again I think this can be abstracted away using a much less
> complex
> >> analysis in terms of simple probabilities which will be a correct
> first-order
> >> approximation of the real behavior of the majority of certification
> systems
> >> we actually build.
> >
> >I think your comment goes back to that assumption.
> >
> >Cheers,
> >
> >Ed Gerck
> >_____________________________________________________________________
> _
> >Dr.rer.nat. E. Gerck
> [e-mail]
> >  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---
> >
> >
> >
> >
> 
> Tony Bartoletti                                             LL
> Center for Information Operations and Assurance          LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 303                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: [phone]   fax: [phone]               LL LLLLLLLL
> email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA18562 for ietf-pkix-bks; Mon, 24 May 1999 18:08:37 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA18547 for <[e-mail]>; Mon, 24 May 1999 18:07:16 -0700 (PDT)
Received: from catalyst ([128.115.223.61]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with SMTP id SAA17358; Mon, 24 May 1999 18:04:39 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 24 May 1999 18:04:22 -0700
To: Ed Gerck <[e-mail]>, Bob Blakley <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Certificate life-cycle costs.
Cc: Bob Jueneman <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <015f01bea3c7$a3518280$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed,

Not to disagree with your most general findings, but in the case
of "purely dependent" attributes (purely redundant, perhaps) I
cannot see how the formula is to work.

To abstract/simplify Bob Blakeley's example further, I consider
the possible lifetime of my own first name (Anthony).  Let it's
lifetime be given by L, in some formulation.

Consider certifying my following attributes:

1.  First Name = "Anthony"

2.  First Name Writ Backward = "ynohtnA"

3.  First Name all in caps = "ANTHONY"

etc.  I suppose I could go on for several hundred such "attributes"
if I had to.  And yet I cannot see how the lifetime of the collection
could be different from the lifetime of the first.  Indeed, they are
really one attribute presented as many.  Easy to see that in this
particular case, but how to recognize such in general?

Comments?

___tony___ 


At 03:37 PM 5/21/99 -0700, Ed Gerck wrote:
>
>
>Bob Blakley wrote:
>
>> Ed,
>>
>> >> I think this is not quite correct because of imprecise phrasing.  What I
>> >> would have said here is
>> >
>> >Bob:
>> >
>> >This is a simple confusion, as that quote of mine was written to Bob
>> >Jueneman, in regard to Bob Jueneman's comments -- not to Bob Blakley
>> >nor in regard to Bob Blakley's comments ;-) Please check the message.
>>
>> Actually, it's a more complicated confusion than you imagine!
>> I did realize that you were answering Bob J.; I was just interposing myself
>> into the discussion!  Name capture creates ambiguities of all sorts (type 1
>> *and* type 2 errors!)
>
>Bob and, perhaps, Bob ;-)
>
>> >Thus, it will of course NOT apply to what you would have said. Hovewer,
>> >what I wrote is correct -- independently of where it is applied. Let me
>> >prove it:
>> >
>> >Suppose, as I said, that each attribute and the key have the same lifetime
>> >"L" -- thus, for N attributes + 1 key, we have:
>> >
>> >1/T = 1/L + 1/L + ...+ 1/L +   1/L
>> >          ^^^^^^^^^^^^^^^       ^^
>> >             N attributes               1 key
>> >
>> >so that:
>> >
>> >1/T = N/L + 1/L  => T = L/(1 + N)
>>
>> All obviously correct but not on the point I was making, which is that there
>> are situations where, because of a lack of independence, N attributes do NOT
>> give rise to N/L, but instead to only 1/L.
>
>I understood your point and I disagreed with it. That is why I included
>two examples which showed that lack of independence is NOT the deciding
>issue to change the result  L/(1+N) to L, but lack of exponential decay.
>And, I also wrote:
>
> "... I did not include the word "independent" since the attributes do
>  not have to be independent for the phrase to apply."
>
>> An example of this is the following attribute certificate:
>>
>>             Attribute 1:    eye-color = gray
>>             Attribute 2:    blood-type = O positive
>>             Attribute 3:    name = George Robert Blakley III
>>
>> Here all attributes have the same lifetime in the sense in which I use the
>> term - which happens also to correspond to the naive notion of "lifetime" you'd see
>> in the dictionary.  I don't know what L is, but I do know that L1 = L2 = L3.
>
>The dictionary definition of lifetime is fine, I have no quibbles about it.  But
>because you believe those three attributes *will* have the same lifetime, this
>does NOT mean:
>
>1. that they were all created (ie, defined) at the same time
>2. that they will all end their validity at the same time
>3. that they are all dependent
>4. that they will all obey the same validity time-decay law
>5. that they will all actually have the same lifetime.
>
>I hope my previous comment is now clearer.
>
>> Now if I add some other attributes:
>>
>>             Attribute 4:    hair-color = brown
>>             Attribute 5:    weight = 150 (well, approximately :)
>>             Attribute 6:    height = 5'9"
>>
>> These all have different L's; Attribute 4 is going to have to be changed to
>> "hair-color = gray" based on some kind of majority-rule algorithm pretty
>> soon now - hopefully before L1 expires!
>
>;-) I hope so -- but my 5 comments above apply in reverse to these other 3
>attributes as well, since what you wrote does NOT mean:
>
>1. that they were all created (ie, defined) at different times
>2. that they will all end their validity at different times
>3. that they are all independent.
>4. that they will all obey different validity time-decay laws
>5. that they will all actually have different lifetimes.
>
>
>> > Bob Blakley wrote:
>> >>
>> >> Normally when I think of "lifetime" I think of a validity interval, and if
>> >> two things have the same lifetime, they come into existence at exactly
>> > > the same time and cease to exist at exactly the same time.  In this case
>> >> there is no independence whatsoever, and the two things should be
>> >> thought of as essentially one attribute (hence my caveats about
>> >> independence in earlier notes).
>> >
>> >This logic is unfounded. Lifetime is a statistical concept by nature -- since
>> >it pertains to the future and no future is deterministic (it is easy to prove
>> >...
>>
>> But I don't think this is really relevant; you can simply re-cast the problem
>> in terms of open intervals to take care of minor nondeterminism surrounding
>> the exact moment of expiry.
>
>Still, this does NOT mean that "if two things have the same lifetime, they come
>into existence at exactly [with some minor nondeterminism] the same time and
>cease to exist at exactly [with some minor nondeterminism] the same time."
>
>As I argued, there is no relationship at all between these events that could
>be inferred from equal lifetimes -- thus, assuming it is unfounded. And,
>this needed generality is at the base of my previous derivation of the lifetime
>equation, as I commented in reference [1] of that posting.
>
>Also, recasting the problem in terms of open intervals where "minor
>nondeterminism" could play a role to define neighborhoods for
>similar lifetimes does NOT mean that "In this case there is no
>independence whatsoever, and the two things should be thought of
>as essentially one attribute (hence my caveats about  independence
>in earlier notes)."
>
>Further, I note that exactly this point of assuming that attributes that
>have the same lifetime are essentially one attribute, and otherwise that
>attributes that have different lifetimes are independent, is at the root of
>David's remarks that questioned the validity of your intuitive derivation:
>
>DOUBT 3: There is no conventional wisdom about the distribution of
>attribute lifetimes, but one would venture that it is a discrete, not a
>continuous distribution.  Therefore, one cannot say that  "with
>probability 1, attribute 2 doesn't expire at t1".
>
>DOUBT 4: Possibly, attributes within a single certificate will not have
>pairwise mutually independent lifetimes, so their lifetimes are more than
>likely correlated.
>
>DOUBT 5: The question whether pairwise mutual independence is sufficient
>for Bob's formula to hold, or whether the stronger joint independence is
>required.
>
>DOUBT 6: The preconditions for Bob's formula to be correct cannot be
>demonstrated.
>
>which I showed were irrelevant because the formula you derived was a special
>case of an equation that did not include any such assumption. So, funnywise,
>my equation supported your formula because it denied the very assumption you
>imposed to derive it ;-)
>
>Though I understand you were led to suppose that assumption  in order to be
>able to provide at least an intuitive "proof" for that formula. However, the
>assumption that lifetime distance is a measure of attribute independence (as
>I may recast your assumption) is incorrect and could have led you either to
>no result or to a wrong result if it were consequently applied in a
>mathematically sound proof.
>
>> >The confusion is thus simple -- two things that have the same lifetime
>> >do not have to begin at exactly the same time
>>
>> They certainly don't have to, but in many cases they actually DO.  The
>> example I gave above is one case; the same information encoded
>> on a driver's license for me is a derivative which exemplifies
>> a broad class of certification scenarios from the real world which
>> also have this property.
>
>I disagree. And, there are billions of counter-examples. For example,
>if men's biological lifetime is 70 years this does not mean that all men
>were born at the same time -- and yet they all have the same lifetime.
>
>
>> >> In order to lower the *lifetime* of the certificate, what's required is
>> that
>> >> attributes expire at *different* times
>> >
>> >No, as above. Also, if the attributes have the same lifetime but their
>> >decay rates are non-exponential (eg, a square-function)  then they
>> >will need to be modeled at least as two exponentials (see my former
>> >workout of David's example) and they will cause different reductions
>> >as compared to the pure exponential case (see my example above)..
>>
>> Except again I think this can be abstracted away using a much less complex
>> analysis in terms of simple probabilities which will be a correct first-order
>> approximation of the real behavior of the majority of certification systems
>> we actually build.
>
>I think your comment goes back to that assumption.
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck                                 [e-mail]
>  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---
>
>
>
>

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: [phone]   fax: [phone]               LL LLLLLLLL
email: [e-mail]                                   LLLLLLLL


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18303 for ietf-pkix-bks; Mon, 24 May 1999 17:43:38 -0700 (PDT)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA18299 for <[e-mail]>; Mon, 24 May 1999 17:43:36 -0700 (PDT)
Received: from coldhcp1-179.bbn.com by COLUMBIA.BBN.COM id aa24772; 24 May 99 20:40 EDT
Reply-To: <[e-mail]>
From: "Dave Sweigert" <[e-mail]>
To: "'Alan Lloyd'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: tokens anyone ? [DoD PKI]
Date: Mon, 24 May 1999 20:35:05 -0400
Message-ID: <001201bea646$6fb66ae0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4F6@DSG1>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

[DOCID: f:s1059pcs.txt]

                                                       Calendar No. 114

106th CONGRESS

  1st Session

                                S. 1059

                          [Report No. 106-50]
_______________________________________________________________________

                                 A BILL

     To authorize appropriations for fiscal year 2000 for military
activities of the Department of Defense, for military construction, and
   for defense activities of the Department of Energy, to prescribe
personnel strengths for such fiscal year for the Armed Forces, and for
                            other purposes.

_______________________________________________________________________

                 May 17 (legislative day, May 14), 1999

[Excerpt]

SEC. 346. USE OF SMART CARD TECHNOLOGY IN THE DEPARTMENT OF DEFENSE.

    (a) Leadership, Planning, and Execution of Smart Card Program.--(1)
Not later than October 1, 1999, the Secretary of Defense shall
designate the Department of the Navy to be the lead agency for the
development and implementation of a Smart Card program for the
Department of Defense effective as of the date of the designation.
    (2) The Secretary of Defense shall direct the Secretary of the Army
and the Secretary of the Air Force to establish Smart Card project
offices for the Department of the Army and the Department of the Air
Force, respectively, not later than November 30, 1999. The designated
offices shall coordinate closely with the lead agency to develop
implementation plans for exploiting the capability of Smart Card
technology as a means for enhancing readiness and improving business
processes throughout the military departments.
    (3) Not later than November 30, 1999, the Secretary of Defense
shall establish a senior coordinating group chaired by a representative
of the Secretary of the Navy. The group shall include senior
representatives from each of the Armed Forces. The senior coordinating
group shall develop and implement Department-wide interoperability
standards for use of Smart Card technology and a plan to exploit Smart
Card technology as a means for enhancing readiness and improving
business processes.
    (4) The Secretary of the Army and the Secretary of the Air Force,
in coordination with the Secretary of the Navy, shall each develop and
implement a program to demonstrate the benefits of Smart Card
technology in the Army and the Air Force, respectively.
    (b) Increased Use Targeted to Certain Naval Regions.--Not later
than November 30, 1999, the Secretary of the Navy shall establish a
business plan to implement the use of Smart Cards in one major Naval
region of the continental United States that is in the area of
operations of the United States Atlantic Command and one major Naval
region of the continental United States that is in the area of
operations of the United States Pacific Command. The regions selected
shall include a major fleet concentration area. The implementation of
the use of Smart Cards in each region shall cover the Navy and Marine
Corps bases and all non-deployed units in the region. The Secretary of
the Navy shall submit the business plan to the congressional defense
committees.
    (c) Funding for Increased Use of Smart Cards.--(1) Of the funds
authorized to be appropriated for the Navy for fiscal year 2000 under
section 102(a)(4) or 301(a)(2), the Secretary of the Navy--
            (A) shall allocate sufficient amounts, up to $30,000,000,
        for ensuring that significant progress is made toward complete
        implementation of the use of Smart Card technology in the
        Department of the Navy; and
            (B) may allocate additional amounts for the conversion of
        paper-based records to electronic media for records systems
        that have been modified to use Smart Card technology.
    (2) Of the funds authorized to be appropriated under section
301(a)(1), up to $5,000,000 shall be available for Army demonstration
programs under subsection (a)(4). Of the funds authorized to be
appropriated under section 301(a)(4), up to $5,000,000 shall be
available for Air Force demonstration programs under subsection (a)(4).
    (d) Report.--Not later than March 31, 2000, the Secretary of
Defense shall submit to the Committees on Armed Services of the Senate
and the House of Representatives a report containing a detailed
discussion of the progress made by the senior coordinating group in
carrying out its duties under subsection (a)(3).
    (e) Definitions.--In this section:
            (1) The term ``Smart Card'' means a credit card-size
        device, normally for carrying and use by personnel, that
        contains one or more integrated circuits and may also employ
        one or more of the following technologies:
                    (A) Magnetic stripe.
                    (B) Bar codes, linear or two-dimensional.
                    (C) Non-contact and radio frequency transmitters.
                    (D) Biometric information.
                    (E) Encryption and authentication.
                    (F) Photo identification.
            (2) The term ``Smart Card technology'' means a Smart Card
        together with all of the associated information technology
        hardware and software that comprise the system for support and
        operation.
    (f) Repeal of Requirement for Automated Identification Technology
Office.--Section 344(b) of the Strom Thurmond National Defense
Authorization Act for Fiscal Year 1999 (Public Law 105-261; 112 Stat.
1977; 10 U.S.C. 113 note) is repealed.

SEC. 347. STUDY ON USE OF SMART CARD AS PKI AUTHENTICATION DEVICE
              CARRIER FOR THE DEPARTMENT OF DEFENSE.

    (a) Study Required.--The Secretary of Defense shall conduct a study
to determine the potential benefits of Department of Defense use of the
Smart Card for addressing the need of the Department of Defense for a
Public-Private Key Infrastructure (PKI) authentication device carrier.
    (b) Report.--Not later than January 31, 2000, the Secretary shall
submit to the Committees on Armed Services of the Senate and the House
of Representatives a report on the results of the study. The report
shall include the Secretary's findings and any recommendations that the
Secretary considers appropriate regarding Department of Defense use of
the Smart Card for addressing the need identified in subsection (a).
    (c) Definitions.--In this section:
            (1) The term ``Smart Card'' means a credit card-size
        device, normally for carrying and use by personnel, that
        contains one or more integrated circuits and may also employ
        one or more of the following technologies:
                    (A) Magnetic stripe.
                    (B) Bar codes, linear or two-dimensional.
                    (C) Non-contact and radio frequency transmitters.
                    (D) Biometric information.
                    (E) Encryption and authentication.
                    (F) Photo identification.
            (2) The term ``Public-Private Key Infrastructure (PKI)
        authentication device carrier'' means a device that physically
        stores, carries, and employs electronic authentication or
        encryption keys necessary to create a unique digital signature,
        digital certificate, or other mark on an electronic document or
        file.

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

[DOCID: f:sr050.106]
>From the Senate Reports Online via GPO Access
[wais.access.gpo.gov]

                                                       Calendar No. 114
_______________________________________________________________________
106th Congress                                                   Report
                                 SENATE
1st Session                                                      106-50
_______________________________________________________________________


                     NATIONAL DEFENSE AUTHORIZATION
                        ACT FOR FISCAL YEAR 2000
                                 REPORT
                         [TO ACCOMPANY S. 1059]

                                   on

AUTHORIZING APPROPRIATIONS FOR FISCAL YEAR 2000 FOR MILITARY ACTIVITIES
  OF THE DEPARTMENT OF DEFENSE, FOR MILITARY CONSTRUCTION, AND FOR
  DEFENSE ACTIVITIES OF THE DEPARTMENT OF ENERGY, TO PRESCRIBE PERSONNEL
  STRENGTHS FOR SUCH FISCAL YEAR FOR THE ARMED FORCES, AND FOR OTHER
  PURPOSES

[Excerpt]

Use of smart card technology in the Department of Defense (sec. 346)

    The committee recommends a provision that would require the
Secretary of Defense to designate the Navy as the lead agency
for development and implementation of the SMART CARD program.
The provision would further authorize the Navy to spend up to
$30.0 million for further fielding of the Smart Card. The
provision would further authorize up to $5.0 million for the
Army, and $5.0 million for the Air Force, to expand
implementation of smart card technology throughout the
Department of Defense.
    The committee is pleased with the Navy's efforts to develop
and implement smart card technology. As part of its Revolution
in Business Affairs initiative, the Navy has begun to use smart
cards to re-engineer the processing of new recruits, ensure
seamless transitions from ship to shore in its carrier battle
groups, and significantly improve manifesting and in-transit
visibility of troops.
    The committee encourages the Navy to expand upon its
existing program, and begin to roll out smart card technology
across the entire department. The Navy should also begin to
identify ways smart cards can be exploited to further improve
business processes. One potential area is the conversion of
existing paper-based personnel records to electronic media for
systems that have been modified to use smart card technology.
    The committee understands that both the Army and the Air
Force have expressed an interest in smart card technology, and
have begun to examine ways in which smart cards can be
exploited. With the progress already made by the Navy, benefits
and savings of smart card technology can best be achieved by
ensuring that smart card initiatives are coordinated among all
military services. Accordingly, the committee directs the
Secretary of Defense to establish a senior coordinating group,
led by the Navy, to oversee the development and implementation
of smart card technology across the services. To ensure that
duplicative systems are not needlessly developed, the senior
coordinating group should take particular care to ensure that
smart cards are interoperable both within and among the
services.
    The senior coordinating group should identify and fund
demonstration projects in the Army and Air Force that will
exploit smart cards to improve business processes and enhance
readiness. The committee allocates $5.0 million for each
service for this purpose. The committee is particularly
impressed with reports from USTRANSCOM that smart cards have
reduced the time required to manifest a wide-body aircraft from
3 to 4 hours, to under 20 minutes. A demonstration project that
builds upon the initial success of USTRANSCOM would be an
appropriate use of the Air Force funds.

Study on use of smart card as PKI authentication device carrier for the
        Department of Defense (sec. 347)

    The Department of Defense (DOD) is planning to use Public
Key Infrastructure (PKI) devices as a tool for authenticating
and securing electronic mail and other network communications
as part of its information assurance program. Smart card
technology appears to be a strong candidate for contributing to
the satisfaction of this requirement. Therefore, the committee
recommends a provision that would require the Secretary
ofDefense to conduct a study of the possibility of using smart card
technology for application to satisfy DOD's PKI requirements. The
provision also requires the Secretary to submit to the Senate and House
Armed Services Committees a report on the results of the study not
later than January 31, 2000.

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18251 for ietf-pkix-bks; Mon, 24 May 1999 17:38:01 -0700 (PDT)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA18247 for <[e-mail]>; Mon, 24 May 1999 17:37:59 -0700 (PDT)
Received: from coldhcp1-179.bbn.com by COLUMBIA.BBN.COM id ab24510; 24 May 99 20:33 EDT
Reply-To: <[e-mail]>
From: "Dave Sweigert" <[e-mail]>
To: "'Alan Lloyd'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: CRL retrieval
Date: Mon, 24 May 1999 20:28:14 -0400
Message-ID: <000d01bea645$7a9b39a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC0BEA17@DSG1>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alan:

Not to mention applications timing out waiting for a response
[if using CRLS for access control].

dgs



-----Original Message-----
From: Alan Lloyd [mailto:[e-mail]]
Sent: Monday, May 24, 1999 6:55 PM
To: '[e-mail]'; [e-mail]
Subject: RE: CRL retrieval


>From a technical perspective - ie a User reading a CRL from a directory
service - with the appropriate authentication and access controls should
not be a problem. 

What is the issue - is it a firewall problem, authentication failure,
access controls denial, an LDAP issue and CRL location issue, or a
product bug.
please advise.

regards alan

> -----Original Message-----
> From:	[e-mail] 
> Sent:	Thursday, May 20, 1999 3:51 AM
> To:	[e-mail]
> Subject:	CRL retrieval 
> 
> 
> I am currently writing some code that will be using CRLs to validate
> Certificates.  The Certificate portion without CRLs is complete.  I
> have been
> looking for a way to retrieve CRLs from any CA, but especially
> Verisign and have
> been unable to find a repository or any other means to retrive a CRL.
> I did
> find a page on the Verisign web site that allowed you to enter a
> certificate on
> the web site itself but I need an actual CRL to verify my certificate.
> Does
> anyone know how to retrieve CRLs or how to retrieve a CRL from
> Verisign in
> particular?
> 
> Matthew DeRuyter
> bldg 256-2  J006
> ext:  x6927
> tie-line: 855-6927
> 
> 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18245 for ietf-pkix-bks; Mon, 24 May 1999 17:37:53 -0700 (PDT)
Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18241 for <[e-mail]>; Mon, 24 May 1999 17:37:52 -0700 (PDT)
Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA24357; Mon, 24 May 1999 17:38:13 -0700 (PDT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2448.0) id <LFVSHLL8>; Mon, 24 May 1999 17:38:02 -0700
Message-ID: <[e-mail]>
From: "Ellison, Carl M" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Carl Ellison <[e-mail]>
Cc: Carl Ellison <[e-mail]>, "Ellison, Carl M" <[e-mail]>, "Ellison, Carl M" <[e-mail]>, Ari Huttunen <[e-mail]>, [e-mail], [e-mail]
Subject: RE: X.509 ACs vs. SPKI?
Date: Mon, 24 May 1999 17:38:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russ,

nit picking:

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Monday, May 24, 1999 1:58 PM
> To: Carl Ellison
> Cc: Ari Huttunen; [e-mail]; [e-mail]; Carl Ellison; Carl
> Ellison
> Subject: Re: X.509 ACs vs. SPKI?
> 
[snip]

> 
> X.509 ACs offer three methods of binding the attributes to an 
> owner.  They
> each offer different advantages and disadvantages.
> 
> 	(1) Issuer Distinguished Name and Serial Number.  This binds the
> attributes to a particular X.509 public key certificate.

IssuerSerial does not identify a particular X.509 certificate.  The
problem is that an Issuer Distinguished Name does not identify an
issuer uniquely, since there are no distinguished names except in name
only.  If the X.500 dream had come true there might be, but it hasn't
and won't.

> 	(2) Subject Distinguished Name.  This binds the 
> attributes to a collection
> of certificates that were issued to the same subject, perhaps 
> by different CAs.

Again, since there are no distinguished names, especially from
multiple issuers, you can't identify certificates issued to the same
subject merely by comparing DNs.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQA/AwUBN0nw/sxqBGb+WvJAEQL+ygCfbuqldwXCWH1zDbNbvPlUejhwc08An1p8
9iuRKe5vW+t2zaqu/lm9i3Zp
=1v3c
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18190 for ietf-pkix-bks; Mon, 24 May 1999 17:32:20 -0700 (PDT)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18186 for <[e-mail]>; Mon, 24 May 1999 17:32:19 -0700 (PDT)
Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA18439; Mon, 24 May 1999 17:32:43 -0700 (PDT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0) id <KVLGXFQ1>; Mon, 24 May 1999 17:32:41 -0700
Message-ID: <[e-mail]>
From: "Ellison, Carl M" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, Carl Ellison <[e-mail]>
Cc: Ari Huttunen <[e-mail]>, [e-mail], [e-mail], Carl Ellison <[e-mail]>, "Ellison, Carl M" <[e-mail]>, "Ellison, Carl M" <[e-mail]>
Subject: RE: X.509 ACs vs. SPKI?
Date: Mon, 24 May 1999 17:32:36 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Russ,

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Monday, May 24, 1999 1:58 PM
> To: Carl Ellison
> Cc: Ari Huttunen; [e-mail]; [e-mail]; Carl Ellison; Carl
> Ellison
> Subject: Re: X.509 ACs vs. SPKI?
> 
> 
> At 09:22 AM 5/12/99 -0700, Carl Ellison wrote:
> >[snip]
> >
> >I see three problems doing the equivalent of SPKI within 
> X.509 and in 
> >particular with ACs.
> >
> >1.	The identification of issuer and subject is convoluted 
> at best.  Missing 
> >is the option that is needed for maximum security (not to mention 
> >anonymity): a public key or the hash of the key.  The 
> IssuerSerial option is 
> >subject to constraints not expressed in the certificate.  
> GeneralNames isn't 
> >constrained or defined, AFAIK, in this spec, so that too depends on

> >constraints not evident in the certificate.  The 
> ObjectDigestInfo might be 
> >used to refer to some public key, but that use isn't spelled 
> out -- and even 
> >then, it is only the subject ID that has this option so 
> identification of 
> >the Issuer is left troubled.
> 
> X.509 ACs offer three methods of binding the attributes to an 
> owner.  They
> each offer different advantages and disadvantages.
> 
> 	(1) Issuer Distinguished Name and Serial Number.  This binds the
> attributes to a particular X.509 public key certificate.
> 
> 	(2) Subject Distinguished Name.  This binds the 
> attributes to a collection
> of certificates that were issued to the same subject, perhaps 
> by different CAs.
> 
> 	(3) Hash of the Public Key.  This binds the attributes 
> to any certificate
> that contains the correct public key.
> 
> It is clear how (1) and (2) can be used.  And, (3) seems to 
> provide what
> Carl is looking for.  Right?  If so, maybe you can help flesh 
> out that part
> of the Internet-Draft.


Yes, if ACs allow the hash of the public key as the subject, then that
option makes what I call an authorization certificate and it works
just fine.  It's the first two cases that are broken because their
name spaces are not globally unique and meaningful to those involved
in making and using the certificate.

However, when I read the spec, I didn't see your case #3.  It must be
well hidden :)
 
> >2.	X.509 does not define the semantics of a certificate, 
> only the syntax.  I 
> >find this especially when mapping out the CDSA extensions 
> that extract SPKI 
> >authorization information from existing X.509 certificates 
> (so that our 
> >implementation will accept and use a mixture of certificate 
> types: X.509, 
> >PGP, SPKI, ....).  Interpreting an X.509v3 certificate 
> requires a different 
> >trust policy module (in CDSA terms -- the code module that 
> understands the 
> >semantics of each field) for each different CPS -- or, to an 
> approximation, 
> >for each different root key.  For example, SET cardholder 
> certificates 
> >define an authorization (permission to use a given PAN/EXP) 
> but plant that 
> >authorization in the CommonName field of the SubjectName.  
> Meanwhile, some 
> >extensions of the SET certificate carry authorization 
> information while 
> >others are to be used for chain validation only.
> 
> There should be common syntax and semantics for base 
> certificate fields.
> Certainly any private extension could be an issue.
> 
> I think that the semantics should be the same for any 
> certificate issued
> under the same Certificate Policy (CP), regardless of the 
> Certification
> Practice Statement (CPS) used by a particular CA.


Perhaps I used the wrong word.  The fact remains that the code that
interprets a full X.509 certificate (including all extensions) needs
to be aware of (to embody) the definitions found in some paper
document.  This is by contrast with SPKI certificates that can be
processed through tuple-reduction without any special knowledge about
such paper documents.  That is why SPKI can have a single Trust Policy
engine while X.509 requires a different one for each application (in
the limit, for each root key).

> >3.	X.509 may be able to define SDSI names, but there is no 
> mechanism for 
> >referring to a fully qualified SDSI name.  That means that the only

> >mechanisms for making an SPKI attribute certificate (one 
> that gives an 
> >authorization to a named entity or group) have to rely on 
> assumptions about 
> >naming conventions.  In particular, I see no way to express:
> >
> >	(name <key> N_1 N_2 ... N_k)
> >
> >in X.509.
> 
> The  X.509 public key certificate provides (name <key>).
> 
> The X.509 ACs could provide (name N_1), (name N_2 N_3), ... 
> (name N_k).
> Where a collection of ACs each contain one or more attributes.

I don't believe you're talking about the same thing I am, Russ.

Unless something has been added very recently to X.509 to accommodate
this, the spec does not permit me to use a list of the root key plus
all names in the certificate chain down to the leaf name and use that
list as the subject of an AC.  Have I missed something?

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQA/AwUBN0nvusxqBGb+WvJAEQKUAACeLIx6WAIuq8cwB1+uqYe5teY8QCsAnipW
wp1seQPlzFVlM/JoBBGVcRq/
=RhOh
-----END PGP SIGNATURE-----


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17220 for ietf-pkix-bks; Mon, 24 May 1999 15:55:11 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17215 for <[e-mail]>; Mon, 24 May 1999 15:55:07 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <LPZKDWG8>; Tue, 25 May 1999 08:55:22 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BEA17@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: CRL retrieval 
Date: Tue, 25 May 1999 08:55:19 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>From a technical perspective - ie a User reading a CRL from a directory
service - with the appropriate authentication and access controls should
not be a problem. 

What is the issue - is it a firewall problem, authentication failure,
access controls denial, an LDAP issue and CRL location issue, or a
product bug.
please advise.

regards alan

> -----Original Message-----
> From:	[e-mail] 
> Sent:	Thursday, May 20, 1999 3:51 AM
> To:	[e-mail]
> Subject:	CRL retrieval 
> 
> 
> I am currently writing some code that will be using CRLs to validate
> Certificates.  The Certificate portion without CRLs is complete.  I
> have been
> looking for a way to retrieve CRLs from any CA, but especially
> Verisign and have
> been unable to find a repository or any other means to retrive a CRL.
> I did
> find a page on the Verisign web site that allowed you to enter a
> certificate on
> the web site itself but I need an actual CRL to verify my certificate.
> Does
> anyone know how to retrieve CRLs or how to retrieve a CRL from
> Verisign in
> particular?
> 
> Matthew DeRuyter
> bldg 256-2  J006
> ext:  x6927
> tie-line: 855-6927
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10935 for ietf-pkix-bks; Mon, 24 May 1999 14:04:05 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10931 for <[e-mail]>; Mon, 24 May 1999 14:04:03 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id OAA04728; Mon, 24 May 1999 14:00:53 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 24 May 1999 16:57:30 -0400
To: Carl Ellison <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: Ari Huttunen <[e-mail]>, [e-mail], [e-mail], Carl Ellison <[e-mail]>, Carl Ellison <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:22 AM 5/12/99 -0700, Carl Ellison wrote:
>[snip]
>
>I see three problems doing the equivalent of SPKI within X.509 and in 
>particular with ACs.
>
>1.	The identification of issuer and subject is convoluted at best.  Missing 
>is the option that is needed for maximum security (not to mention 
>anonymity): a public key or the hash of the key.  The IssuerSerial option is 
>subject to constraints not expressed in the certificate.  GeneralNames isn't 
>constrained or defined, AFAIK, in this spec, so that too depends on 
>constraints not evident in the certificate.  The ObjectDigestInfo might be 
>used to refer to some public key, but that use isn't spelled out -- and even 
>then, it is only the subject ID that has this option so identification of 
>the Issuer is left troubled.

X.509 ACs offer three methods of binding the attributes to an owner.  They
each offer different advantages and disadvantages.

	(1) Issuer Distinguished Name and Serial Number.  This binds the
attributes to a particular X.509 public key certificate.

	(2) Subject Distinguished Name.  This binds the attributes to a collestion
of certificates that were issued to the same subject, perhaps by different CAs.

	(3) Hash of the Public Key.  This binds the attributes to any certificate
that contains the correct public key.

It is clear how (1) and (2) can be used.  And, (3) seems to provide what
Carl is looking for.  Right?  If so, maybe you can help flesh out that part
of the Internet-Draft.

>2.	X.509 does not define the semantics of a certificate, only the syntax.  I 
>find this especially when mapping out the CDSA extensions that extract SPKI 
>authorization information from existing X.509 certificates (so that our 
>implementation will accept and use a mixture of certificate types: X.509, 
>PGP, SPKI, ....).  Interpreting an X.509v3 certificate requires a different 
>trust policy module (in CDSA terms -- the code module that understands the 
>semantics of each field) for each different CPS -- or, to an approximation, 
>for each different root key.  For example, SET cardholder certificates 
>define an authorization (permission to use a given PAN/EXP) but plant that 
>authorization in the CommonName field of the SubjectName.  Meanwhile, some 
>extensions of the SET certificate carry authorization information while 
>others are to be used for chain validation only.

There should be common syntax and semantics for base certificate fields.
Certainly any private extension could be an issue.

I think that the semantics should be the same for any certificate issued
under the same Certificate Policy (CP), regardless of the Certification
Practice Statement (CPS) used by a particular CA.

>3.	X.509 may be able to define SDSI names, but there is no mechanism for 
>referring to a fully qualified SDSI name.  That means that the only 
>mechanisms for making an SPKI attribute certificate (one that gives an 
>authorization to a named entity or group) have to rely on assumptions about 
>naming conventions.  In particular, I see no way to express:
>
>	(name <key> N_1 N_2 ... N_k)
>
>in X.509.

The  X.509 public key certificate provides (name <key>).

The X.509 ACs could provide (name N_1), (name N_2 N_3), ... (name N_k).
Where a collection of ACs each contain one or more attributes.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09325 for ietf-pkix-bks; Mon, 24 May 1999 13:53:37 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA09321 for <[e-mail]>; Mon, 24 May 1999 13:53:36 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA09998 for <[e-mail]>; Mon, 24 May 1999 13:53:39 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FC98PF00.B4N; Mon, 24 May 1999 13:53:39 -0700 
Message-ID: <[e-mail]>
Date: Mon, 24 May 1999 13:53:32 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Comments on time-stamp-01: Identification of TSA
Content-Type: multipart/mixed; boundary="------------E77ADB3AE4E20A4F4CDA92EE"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------E77ADB3AE4E20A4F4CDA92EE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The current time-stamp draft contains several places that define fields
or recommend use of previously defined fields to identify the TSA
creating the token.  I believe that the draft provides too many ways to
do this, which will work against creation of interoperable
implementations.  In addition, I believe that some of the current
options are motivated by concerns that are better addressed in other
ways.

First, the protocol uses a CMS SignedData object as the basic form of
the time-stamp token.  This object allows identification of the signer
in the SignerInfo section.  This data is sufficient to locate the
correct certificate, build the chain and validate TSA's identity.  This
should be the primary (and possibly only) method of identifying the TSA
that generated the token.  However, the current draft goes on to mention
several other identification fields.

The draft contains the following text:

     The purpose of the tsa field is to identify the name of the
     TSA.  If present, it MUST correspond to one of the subject
     names included in the certificate that is to be used to verify
     the token.  This field MAY be omitted if the Signing
     Certificate Attribute has been included as a signed
     attribute.  (See Section 5 of [ESS].) It MUST be present if
     the ESSCertID Attribute is not used to identify the TSA.

'tsa' is an optional GeneralName field defined within the TSTInfo
sequence.  Because it is optional, it cannot be relied upon to locate
the proper certificate needed to verify the token.  It may be useful to
locate the certificate if a verifier files certificates using values
other than Issuer/SerialNumber or SubjectKeyIdentifier.  However, the
TSA would need to know what other types of GeneralName might be useful
to a client.  The 'tsa' field does have one difference from the
SignerInfo fields - it is signed with the message.  This has some
significance for some attacks on the protocol, which I'll discuss later.

The 'substitution attack' ([ESS]) is prevented for TSA signatures in two
ways.  First, the key used for signing time-stamp tokens is required to
be used only for that purpose.  This means that existence of a second
certificate (with different capabilities) for the same key is already
prohibited by the draft.  Second, the token also contains a
PolicyIdentifier that is effect for the signature.  The verifier must
check that the certificate chain allows this policy to be used.  This
requirement prevents a second certificate (with different
PolicyIdentifier values) from being used to check the signature.  In
fact, the policy identifiers in the SigningCertificate sequence of [ESS]
duplicate the value already found in the token.

Finally, the time-stamping draft expresses concern for attacks that may
occur when the CA does not perform proof-of-possession checks on the TSA
key.  To counter these, the draft encourages use of the fields mentioned
above (including the tsa field, and the SigningCertificate attribute)
which are included within the token signature.  This prevents a
substitution attack where the substitute certificate is for an entirely
different subject name.  However, since other drafts will address these
attacks during the certificate enrollment process (the CMC draft
contains proof-of-possession protocol), I think the time-stamp protocol
should not define its own mechanisms for dealing with the problem.

In summary, there are too many ways to identify the TSA certificate.  We
should use the basic CMS SignerInfo for this data.  Attacks (as listed
in [ESS]) Concerns about proof-of-possession flaws should be addressed
elsewhere, specifically in the certificate request process.

--------------E77ADB3AE4E20A4F4CDA92EE
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------E77ADB3AE4E20A4F4CDA92EE--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03789 for ietf-pkix-bks; Mon, 24 May 1999 11:56:58 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03782 for <[e-mail]>; Mon, 24 May 1999 11:56:56 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA29684 for <[e-mail]>; Mon, 24 May 1999 11:56:59 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FC93AZ00.T3E; Mon, 24 May 1999 11:56:59 -0700 
Message-ID: <[e-mail]>
Date: Mon, 24 May 1999 11:56:27 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Comments on time-stamp-01: Use of PolicyInformation
Content-Type: multipart/mixed; boundary="------------0095857523297956EAB04B9B"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------0095857523297956EAB04B9B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have some questions/comments on the use of PolicyInformation in the
proposed time-stamping protocol.

First, a PolicyInformation field is required in the TSTInfo (response)
data structure, but no standard policy OID is defined by this draft.  To
allow interoperability, there should be at least one standard OID
defined (with appropriate definition, see following).  An alternative to
this is to make the policy field in the response optional.  This would
indicate that the response is delivered under some standard (minimum)
policy, or that the policy is as agreed between the client (or CA) and
the TSA.

Second, the draft needs to indicate (or suggest) what types of
information (guarantees?) are carried by the policy.  I can think of
several:

   * indicate method used to define valid message imprint digests.  The
     TSA would be guaranteeing that the digest was considered usable at
     the time of the time-stamp.
   * indicate the availability of a time-stamp log, to allow later
     verification that a time-stamp token is authentic.
   * indicate certification of the timestamp accuracy (by some third
     party?)

Since there is no discussion in the draft on what the "policy" field
might represent, it will be difficult to build interoperable clients and
servers.  I suggest that a standard OID should indicate:

   * The TSA checks digests against a current list of acceptable digests
     defined by RFC/standard - either the time-stamp document itself, or
     a separate document that is updated to follow the latest
     technology.
   * A qualifier indicates whether the TSA logs time-stamps and can
     provide access to logs if needed for arbitration purposes.

Third, I believe that the authors assume that clients perform validation
of the TSA certificate chain using the appropriate policy value.  This
is standard X.509 processing.  However, it would be better to state the
requirement (briefly) in the time-stamp draft.

--------------0095857523297956EAB04B9B
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------0095857523297956EAB04B9B--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA21279 for ietf-pkix-bks; Mon, 24 May 1999 01:39:27 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA21275 for <[e-mail]>; Mon, 24 May 1999 01:39:24 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id KAA20569 for <[e-mail]>; Mon, 24 May 1999 10:39:54 +0200
Received: from mega (t2o69p41.telia.com [62.20.144.161]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id KAA44828 for <[e-mail]>; Mon, 24 May 1999 10:39:52 +0200
Message-ID: <003f01bea5c9$16b60630$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: Pamphlet: Smart Card vs. Smart Terminals
Date: Mon, 24 May 1999 10:37:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA21276
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,
For those who have interests in smart cards and mobile phones you may find the following paper
of some value:

http://www.mobilephones-tng.com/papers/smartcardsvssmartterminals.html

Regards
Anders Rundgren
Senior Internet e-commerce Architect




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA10669 for ietf-pkix-bks; Sun, 23 May 1999 19:39:17 -0700 (PDT)
Received: from www.eci.com.cn ([159.226.41.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10651 for <[e-mail]>; Sun, 23 May 1999 19:39:13 -0700 (PDT)
Received: from eci.com.cn ([10.226.41.80]) by www.eci.com.cn (Netscape Messaging Server 3.5)  with ESMTP id 389 for <[e-mail]>; Mon, 24 May 1999 10:38:09 +0100
Message-ID: <[e-mail]>
Date: Mon, 24 May 1999 10:39:30 +0800
From: "gang cao" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: about rfc2585.txt
Content-Type: multipart/alternative; boundary="------------7ACF23882C2257BC18897326"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------7ACF23882C2257BC18897326
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

in section 2 and section 3 first paragraph:
   Within certificate extensions and CRL extensions, the URI form of
   GeneralName is used to specify the location where issuer certificates

   and CRLs may be obtained.

what is the certificate and CRL meaning?
if i need get someone certificate , how can i get the certificate
extensions?
if i need get CRL , how can i get the CRL extensions?

--------------7ACF23882C2257BC18897326
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
in section 2 and section 3 first paragraph:
<br>&nbsp;&nbsp; Within <i><u>certificate</u></i> extensions and <i><u>CRL</u></i>
extensions, the URI form of
<br>&nbsp;&nbsp; GeneralName is used to specify the location where issuer
certificates
<br>&nbsp;&nbsp; and CRLs may be obtained.
<p>what is the certificate and CRL meaning?
<br>if i need get someone certificate , how can i get the certificate extensions?
<br>if i need get CRL , how can i get the CRL extensions?</html>

--------------7ACF23882C2257BC18897326--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01836 for ietf-pkix-bks; Sun, 23 May 1999 15:53:06 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01831 for <[e-mail]>; Sun, 23 May 1999 15:52:42 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <LPZKDWA6>; Mon, 24 May 1999 08:52:51 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BEA03@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Nick Pope'" <[e-mail]>, [e-mail], Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Rename Qualified Certificates?
Date: Mon, 24 May 1999 08:52:50 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Nick here.

Syntax is not that useful unless one understands the semantic behind it
for process and validation.

Syntax definitions should be the last part of a system design - not the
first.

regards alan

> -----Original Message-----
> From:	Nick Pope 
> Sent:	Saturday, May 22, 1999 2:52 AM
> To:	[e-mail]; Stephen Kent
> Cc:	[e-mail]; [e-mail]
> Subject:	RE: Rename Qualified Certificates?
> 
> This seems to be a bit of a Blunderbus approach.  It may well hit a
> number
> of things that wasn't intended and may well miss what we were aiming
> at.
> 
> Nick
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: 21 May 1999 17:12
> > To: Stephen Kent
> > Cc: Nick Pope; [e-mail]; [e-mail]
> > Subject: RE: Rename Qualified Certificates?
> >
> >
> > I agree with Steve and Hoyt that we certificate policy qualifiers
> > are a good
> > place for fields qualifying such things as signature authority
> > amounts.  So,
> > even though RFC 2459 section 4.2.1.5
> > "strongly recommends that use of qualifiers be limited to those
> > identified in
> > this section", of which there are only two, which suggests to me
> that new
> > extensions are should be used instead, I'd like to submit some
> > proposed generic
> > qualifier syntaxes for discussion.  These are quite large to
> > reduce the number
> > of qualifiers people would need to add to their ASN.1 parsers:
> >
> > PrimitiveField      ::=  SEQUENCE  {
> >      fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
> >      CHOICE    {
> >      number         NumericString,
> >      printable PrintableString,
> >      wideChar  BMPString,
> >      universal UTF8String,
> >      hugeChar  UniversalString,
> >      ascii          IA5String,
> >      boolean   BOOLEAN,
> >      int       INTEGER,
> >      realValue REAL,
> >      boolArray BIT STRING,
> >      bitData        [29] IMPLICIT BIT STRING,
> >      blob      OCTET STRING,
> >      omitted        NULL,
> >      id        OBJECT IDENTIFIER,
> >      time      GeneralizedTime,
> >      oldTime   UTCTime
> >      }
> > }
> >
> > InternetField  ::=  SEQUENCE  {
> >      fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
> >      CHOICE    {    -- mainly extracted from GeneralName
> >      generalNames        SEQUENCE OF GeneralName,
> >      otherName      [0]  INSTANCE OF OTHER-NAME,
> >      rfc822Name          [1]  IMPLICIT IA5String,
> >      dNSName        [2]  IMPLICIT IA5String,
> >      x400Address         [3]  IMPLICIT ORAddress,
> >      directoryName       [4]  IMPLICIT Name,
> >      ediPartyName        [5]  IMPLICIT EDIPartyName,
> >      uniformResourceIdentifier     [6]   IMPLICIT IA5String,
> >      iPAddress      [7]  IMPLICIT OCTET STRING,
> >      registeredID        [8]  IMPLICIT OBJECT IDENTIFIER,
> >      TCPPort        [10] IMPLICIT INTEGER,
> >      UDPPort        [11] IMPLICIT INTEGER,
> >      OSIPSAP        [12] IMPLICIT SEQUENCE OF OCTET STRING
> >      }
> > }
> >
> > FinancialAmount     ::=  SEQUENCE
> > {    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
> >      Currency  PrintableString,               -- e.g. "USD" for
> > U.S. Dollar
> >      CHOICE    {
> >           amount         NumericString,
> >           value          INTEGER         -- no need for
> floating-point
> >      }
> > }
> >
> >      Tom Gindin
> >
> >
> >


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04421 for ietf-pkix-bks; Sat, 22 May 1999 14:43:47 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04417 for <[e-mail]>; Sat, 22 May 1999 14:43:45 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id XAA30039 for <[e-mail]>; Sat, 22 May 1999 23:45:10 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 22 May 1999 23:44:12 +0200
To: <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA04418
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hoyt,

I agree with you. I think that policy qualifiers should be used for this
purpose. Financial ammount are absolutely a matter of policy and if there
are a variable value related to a policy, then it seams to me that policy
qualifiers serves just that purpose.

/Stefan


At 07:23 PM 5/20/99 -0700, [e-mail] wrote:
>
>
>hello, i rarely stick my oar into these conversations but this is an
>important point to me.
>
>steve's proposal is what i thought we intended so long ago when we designed
>the public key certificate policy information. i have been somewhat bemused
>with certificates holding long human consumable text strings (long enough
>without even being localized).
>
>i had hoped that for example, a certificate policy might specify that the
>certificate can only be used in support of a transaction whose value did
>not exceed a value contained in the policy qualifier (which may hold a
>structure with that value specified in several currencies) and that the
>relying party software would inforce the policy rule, not the humans using
>the system.
>
> some time ago at an aba information security committee meeting, i proposed
>a briefly explored idea that a standard form contract could be identified
>in the cp while modifications to that contract, e.g. excluded clauses,
>would be specified in the qualifier. i believe the significant value  is
>not that some consumer can study the contract, but that the relying
>application can understand how each value in the policy qualifier affects
>what the application will do (assuming we move beyond limited browser
>handling of the certificate and its policy - mobile code seems to be the
>enabler for this)
>
>i am not happy with overloaded certificates but my first target would be
>eliminating long text strings. i know this requires a program that can
>intelligently handle the values in the certificate. then i believe that it
>is possible that some information, common across a large number of
>certificates, could be contained in a separate signed structure, e.g.
>another certificate. but i also want to avoid giving the relying party any
>more signed structures to verify than necessary. what if i reduce the size
>of the public key certificate but am required to verify two certificates
>instead of one.
>
>i don't beleive we can avoid some of those structures however. for example,
>if we want to identify a policy with an object id, then assuming the rely
>party can get to that policy and supporting mobile code, how does the
>relying party know it is working with the intended policy definition? one
>approach is a standardized structure that holds the object id of the
>policy, names of and pointers to mobile code, and other relevant
>information. that structure would be signed by the CA that issued the
>certificate or by some other entity whose relationship to the issuing CA is
>specified. however, the retrieval, verification,  and evaluation of this
>structure shouldn't have to be done for every transaction but only in the
>initialization of support for the identified policy.
>
>i realize that if one's focus is on non-augmented browser use, none of what
>i propose is useful. my comments are based on the hope that we will move
>away from such lowest common denominator use.
>
>    hoyt
>
>
>
>
>Stephen Kent <[e-mail]> on 05/20/99 02:57:49 PM
>
>To:   "Nick Pope" <[e-mail]>
>cc:   "Stephen Kent" <[e-mail]>, [e-mail] (bcc: Hoyt
>      Kesterson/US/BULL)
>Subject:  RE: Rename Qualified Certificates?
>
>
>
>
>Nick,
>
>>I agree with the aim of not over-loading a certificate.  However, I don't
>>want to go too far the other way and overload the policy id so that a new
>>policy id is required for any minor variation on the use certificates
>within
>>a common overall policy.
>
>Fair comment.  One might use a new extension, as Bob Junenman suggested,
>although when I look at policy qualifiers I see a ready made place to plug
>in a range of values for approval authority, currency and max value for
>liability, etc.
>
>Steve
>
>

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27783 for ietf-pkix-bks; Sat, 22 May 1999 08:15:59 -0700 (PDT)
Received: from goose.prod.itd.earthlink.net (goose.prod.itd.earthlink.net [207.217.120.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27779 for <[e-mail]>; Sat, 22 May 1999 08:15:55 -0700 (PDT)
Received: from brick (sdn-ar-008casfraP129.dialsprint.net [158.252.215.131]) by goose.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA28607; Sat, 22 May 1999 08:15:25 -0700 (PDT)
Message-ID: <00bf01bea465$ec499510$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: <[e-mail]>, "Robert Zuccherato" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Sat, 22 May 1999 08:15:12 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert, I think what we need is a state/event diagram describing the
transaction of using the DCS and the Client to TSA relational model. I think
this is an important missing piece of the puzzle.

Todd

----- Original Message -----
From: Terry Hayes <[e-mail]>
To: Robert Zuccherato <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, May 21, 1999 6:54 PM
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt


> Robert Zuccherato wrote:
>
> > If the Extended Key Usage Extension was not critical two things may
happen.
> > Some clients may not check for it and therefore allow any entity to act
as a
> > TSA.  Also, clients may ignore the extension and accept the signature as
any
> > other signature.  However, it is not just a signature, it is meant to
> > provide certain assurances.  The semantics of this signature are very
> > important and I don't want those semantics to be lost.
>
> I think the first case is just a bug in the client application.  A client
> implementing time-stamping according to this protocol should check the
keyusage
> bit as required by the standard.  There isn't much a CA can do to force
software
> to do the right thing (except publish a list of certified software).
Setting
> the extension to critical isn't going to force broken software to do the
check.
>
> The second case has more merit.  The CA is preventing the TSA from fooling
older
> clients into believing it's certified for more than it is.  Given that the
TSA
> is supposed to use the key ONLY for time-stamping operations, requiring
the
> extension to be critical makes sense.  However, if the CA wanted to
certify the
> key for both time-stamping and SSL operations (say), then marking it
critical
> could be a problem, since older SSL clients might be unable to use the
> certificate.
>
> Another example of the second case is the "delta" extension for CRLs.
Older
> CRL-using applications would not work correctly if there wasn't a strong
> indication that the CRL was unusable for them.  Marking the extension
critical
> does that very well.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA25793 for ietf-pkix-bks; Fri, 21 May 1999 19:12:28 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA25785 for <[e-mail]>; Fri, 21 May 1999 19:12:27 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id TAA27039 for <[e-mail]>; Fri, 21 May 1999 19:12:16 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FC43GG00.BAO; Fri, 21 May 1999 19:12:16 -0700 
Message-ID: <[e-mail]>
Date: Fri, 21 May 1999 19:12:11 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: "'Jose A. Manas'" <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------F925A5A0797DA30F64A023FE"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------F925A5A0797DA30F64A023FE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Zuccherato wrote:

> How can we do this (separate transient data from long-lived data) and still
> maintain simplicity and security?

I don't think this is too hard to do.  First, define the basic (low-level)
operation of the protocol as a request, followed by one of two responses:

   * a TimestampToken
   * an unauthenticated error message

The error message will need the nonce and/or imprint fields to tie it to the
original request. (I won't define that type here)

You can run the protocol like this (or just not respond for errors).  As you
have pointed out, this is subject to denial-of-service attacks.

So now add another level of protocol that packages sends either the token, or a
signed version of the error message.

     BetterTSAResponse ::= CHOICE {
       [0] tsatoken TimestampToken,
       [1] authenticatedError SignedData
     }

The SignedData will contain a TSAErrorResponse type and you'll need an OID to
indicate that (id-ct-TSTError).  You can adopt the same rules for validating
the signer of this data as you did for TimestampToken (allowing the TSA to sign
its error messages), or you can define different requirements altogether.



--------------F925A5A0797DA30F64A023FE
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------F925A5A0797DA30F64A023FE--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA23010 for ietf-pkix-bks; Fri, 21 May 1999 18:54:38 -0700 (PDT)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA23006 for <[e-mail]>; Fri, 21 May 1999 18:54:33 -0700 (PDT)
Received: from tintin.mcom.com (tintin.mcom.com [205.217.233.42]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA26458 for <[e-mail]>; Fri, 21 May 1999 18:54:22 -0700 (PDT)
Received: from netscape.com ([208.12.62.90]) by tintin.mcom.com (Netscape Messaging Server 4.03) with ESMTP id FC42ML00.VAN; Fri, 21 May 1999 18:54:21 -0700 
Message-ID: <[e-mail]>
Date: Fri, 21 May 1999 18:54:08 -0700
From: [e-mail] (Terry Hayes)
Reply-To: [e-mail]
Organization: Netscape Communications, Inc.
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------F9E24351895EF4F9925989E4"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------F9E24351895EF4F9925989E4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert Zuccherato wrote:

> If the Extended Key Usage Extension was not critical two things may happen.
> Some clients may not check for it and therefore allow any entity to act as a
> TSA.  Also, clients may ignore the extension and accept the signature as any
> other signature.  However, it is not just a signature, it is meant to
> provide certain assurances.  The semantics of this signature are very
> important and I don't want those semantics to be lost.

I think the first case is just a bug in the client application.  A client
implementing time-stamping according to this protocol should check the keyusage
bit as required by the standard.  There isn't much a CA can do to force software
to do the right thing (except publish a list of certified software).  Setting
the extension to critical isn't going to force broken software to do the check.

The second case has more merit.  The CA is preventing the TSA from fooling older
clients into believing it's certified for more than it is.  Given that the TSA
is supposed to use the key ONLY for time-stamping operations, requiring the
extension to be critical makes sense.  However, if the CA wanted to certify the
key for both time-stamping and SSL operations (say), then marking it critical
could be a problem, since older SSL clients might be unable to use the
certificate.

Another example of the second case is the "delta" extension for CRLs.  Older
CRL-using applications would not work correctly if there wasn't a strong
indication that the CRL was unusable for them.  Marking the extension critical
does that very well.

--------------F9E24351895EF4F9925989E4
Content-Type: text/x-vcard; charset=us-ascii;
 name="thayes.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Terry Hayes
Content-Disposition: attachment;
 filename="thayes.vcf"

begin:vcard 
n:Hayes;Terry
tel;work:[phone]
x-mozilla-html:TRUE
org:Netscape Communications Corp.
adr:;;;;;;
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Terry Hayes
end:vcard

--------------F9E24351895EF4F9925989E4--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22118 for ietf-pkix-bks; Fri, 21 May 1999 15:46:35 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA22114 for <[e-mail]>; Fri, 21 May 1999 15:46:34 -0700 (PDT)
Received: from mcg.org.br (pm09-31.sac.verio.net [209.162.65.144]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id PAA12284; Fri, 21 May 1999 15:46:43 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 21 May 1999 15:37:51 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: Certificate life-cycle costs.
References: <015f01bea3c7$a3518280$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Blakley wrote:

> Ed,
>
> >> I think this is not quite correct because of imprecise phrasing.  What I
> >> would have said here is
> >
> >Bob:
> >
> >This is a simple confusion, as that quote of mine was written to Bob
> >Jueneman, in regard to Bob Jueneman's comments -- not to Bob Blakley
> >nor in regard to Bob Blakley's comments ;-) Please check the message.
>
> Actually, it's a more complicated confusion than you imagine!
> I did realize that you were answering Bob J.; I was just interposing myself
> into the discussion!  Name capture creates ambiguities of all sorts (type 1
> *and* type 2 errors!)

Bob and, perhaps, Bob ;-)

> >Thus, it will of course NOT apply to what you would have said. Hovewer,
> >what I wrote is correct -- independently of where it is applied. Let me
> >prove it:
> >
> >Suppose, as I said, that each attribute and the key have the same lifetime
> >"L" -- thus, for N attributes + 1 key, we have:
> >
> >1/T = 1/L + 1/L + ...+ 1/L +   1/L
> >          ^^^^^^^^^^^^^^^       ^^
> >             N attributes               1 key
> >
> >so that:
> >
> >1/T = N/L + 1/L  => T = L/(1 + N)
>
> All obviously correct but not on the point I was making, which is that there
> are situations where, because of a lack of independence, N attributes do NOT
> give rise to N/L, but instead to only 1/L.

I understood your point and I disagreed with it. That is why I included
two examples which showed that lack of independence is NOT the deciding
issue to change the result  L/(1+N) to L, but lack of exponential decay.
And, I also wrote:

 "... I did not include the word "independent" since the attributes do
  not have to be independent for the phrase to apply."

> An example of this is the following attribute certificate:
>
>             Attribute 1:    eye-color = gray
>             Attribute 2:    blood-type = O positive
>             Attribute 3:    name = George Robert Blakley III
>
> Here all attributes have the same lifetime in the sense in which I use the
> term - which happens also to correspond to the naive notion of "lifetime" you'd see
> in the dictionary.  I don't know what L is, but I do know that L1 = L2 = L3.

The dictionary definition of lifetime is fine, I have no quibbles about it.  But
because you believe those three attributes *will* have the same lifetime, this
does NOT mean:

1. that they were all created (ie, defined) at the same time
2. that they will all end their validity at the same time
3. that they are all dependent
4. that they will all obey the same validity time-decay law
5. that they will all actually have the same lifetime.

I hope my previous comment is now clearer.

> Now if I add some other attributes:
>
>             Attribute 4:    hair-color = brown
>             Attribute 5:    weight = 150 (well, approximately :)
>             Attribute 6:    height = 5'9"
>
> These all have different L's; Attribute 4 is going to have to be changed to
> "hair-color = gray" based on some kind of majority-rule algorithm pretty
> soon now - hopefully before L1 expires!

;-) I hope so -- but my 5 comments above apply in reverse to these other 3
attributes as well, since what you wrote does NOT mean:

1. that they were all created (ie, defined) at different times
2. that they will all end their validity at different times
3. that they are all independent.
4. that they will all obey different validity time-decay laws
5. that they will all actually have different lifetimes.


> > Bob Blakley wrote:
> >>
> >> Normally when I think of "lifetime" I think of a validity interval, and if
> >> two things have the same lifetime, they come into existence at exactly
> > > the same time and cease to exist at exactly the same time.  In this case
> >> there is no independence whatsoever, and the two things should be
> >> thought of as essentially one attribute (hence my caveats about
> >> independence in earlier notes).
> >
> >This logic is unfounded. Lifetime is a statistical concept by nature -- since
> >it pertains to the future and no future is deterministic (it is easy to prove
> >...
>
> But I don't think this is really relevant; you can simply re-cast the problem
> in terms of open intervals to take care of minor nondeterminism surrounding
> the exact moment of expiry.

Still, this does NOT mean that "if two things have the same lifetime, they come
into existence at exactly [with some minor nondeterminism] the same time and
cease to exist at exactly [with some minor nondeterminism] the same time."

As I argued, there is no relationship at all between these events that could
be inferred from equal lifetimes -- thus, assuming it is unfounded. And,
this needed generality is at the base of my previous derivation of the lifetime
equation, as I commented in reference [1] of that posting.

Also, recasting the problem in terms of open intervals where "minor
nondeterminism" could play a role to define neighborhoods for
similar lifetimes does NOT mean that "In this case there is no
independence whatsoever, and the two things should be thought of
as essentially one attribute (hence my caveats about  independence
in earlier notes)."

Further, I note that exactly this point of assuming that attributes that
have the same lifetime are essentially one attribute, and otherwise that
attributes that have different lifetimes are independent, is at the root of
David's remarks that questioned the validity of your intuitive derivation:

DOUBT 3: There is no conventional wisdom about the distribution of
attribute lifetimes, but one would venture that it is a discrete, not a
continuous distribution.  Therefore, one cannot say that  "with
probability 1, attribute 2 doesn't expire at t1".

DOUBT 4: Possibly, attributes within a single certificate will not have
pairwise mutually independent lifetimes, so their lifetimes are more than
likely correlated.

DOUBT 5: The question whether pairwise mutual independence is sufficient
for Bob's formula to hold, or whether the stronger joint independence is
required.

DOUBT 6: The preconditions for Bob's formula to be correct cannot be
demonstrated.

which I showed were irrelevant because the formula you derived was a special
case of an equation that did not include any such assumption. So, funnywise,
my equation supported your formula because it denied the very assumption you
imposed to derive it ;-)

Though I understand you were led to suppose that assumption  in order to be
able to provide at least an intuitive "proof" for that formula. However, the
assumption that lifetime distance is a measure of attribute independence (as
I may recast your assumption) is incorrect and could have led you either to
no result or to a wrong result if it were consequently applied in a
mathematically sound proof.

> >The confusion is thus simple -- two things that have the same lifetime
> >do not have to begin at exactly the same time
>
> They certainly don't have to, but in many cases they actually DO.  The
> example I gave above is one case; the same information encoded
> on a driver's license for me is a derivative which exemplifies
> a broad class of certification scenarios from the real world which
> also have this property.

I disagree. And, there are billions of counter-examples. For example,
if men's biological lifetime is 70 years this does not mean that all men
were born at the same time -- and yet they all have the same lifetime.


> >> In order to lower the *lifetime* of the certificate, what's required is
> that
> >> attributes expire at *different* times
> >
> >No, as above. Also, if the attributes have the same lifetime but their
> >decay rates are non-exponential (eg, a square-function)  then they
> >will need to be modeled at least as two exponentials (see my former
> >workout of David's example) and they will cause different reductions
> >as compared to the pure exponential case (see my example above)..
>
> Except again I think this can be abstracted away using a much less complex
> analysis in terms of simple probabilities which will be a correct first-order
> approximation of the real behavior of the majority of certification systems
> we actually build.

I think your comment goes back to that assumption.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21635 for ietf-pkix-bks; Fri, 21 May 1999 14:42:56 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA21631 for <[e-mail]>; Fri, 21 May 1999 14:42:55 -0700 (PDT)
Received: 	id RAA22454; Fri, 21 May 1999 17:39:44 -0400
Received: by gateway id <LMML9QSR>; Fri, 21 May 1999 17:42:10 -0400
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: DirectoryString Encoding
Date: Fri, 21 May 1999 17:42:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have some questions about how ASN.1 encodings are to be done in
certificates etc. with respect to distinguished names and RFC 2459.

>From what I understand:

1) By the year 2004 (Jan.1) all objects with attributes of DirectoryString
syntax are to be encoded (tagged) as UTF8 regardless of whether or not the
particular string being encoded has only ASCII data, printable string
characters or data outside the 7bit ascii range. Attributes not defined as
DirectoryString are to be encoded as indicated by their syntax i.e.
Ia5String attributes will be tagged as ia5String (such as dc),
printableString will be tagged as printableString (such as serialNumber).

2) Until the year 2004, the preferred technique is to use the encoding
mechanism described above however, implementers have the choice of using an
alternate encoding scheme. The alternate technique would be to use the
indicated syntax tag as described above except for DirectoryString, the
encoding would be printableString unless data outside the printableString
set is detected in which case BMPString should be used.

3) Attributes defined in various RFCs as CaseIgnoreString or CaseExactString
are to be treated as if they had been defined as DirectoryString. An example
would be RFC 1274 which defines attributes like userid (uid). This is
because those syntaxes defined in the 1988 edition of X.500 were upgraded by
the DirectoryString syntax of 1993 X.500 which has continued to be upgraded
in recent versions by including BMP and UTF8 Strings.

Is there anyone who has a different intepretation?

Chris.


-----------------------------------------
Chris Oliva
Entrust Technologies

[phone]
[e-mail]
http://www.entrust.com

Mark your calendar now for Entrust SecureSummit '99
June 14-17, Hyatt Grand Cypress Resort, Orlando, FL
-----------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21149 for ietf-pkix-bks; Fri, 21 May 1999 13:21:22 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21145 for <[e-mail]>; Fri, 21 May 1999 13:21:21 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id PAA08616; Fri, 21 May 1999 15:20:04 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id PAA10209; Fri, 21 May 1999 15:20:02 -0500 (CDT)
Message-ID: <015f01bea3c7$a3518280$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>
Cc: "Bob Jueneman" <[e-mail]>, <[e-mail]>
Subject: Re: Certificate life-cycle costs.
Date: Fri, 21 May 1999 15:22:24 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_015C_01BEA39D.BA417EC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_015C_01BEA39D.BA417EC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,



>> I think this is not quite correct because of imprecise phrasing.  What I
>> would have said here is
>
>Bob:
>
>This is a simple confusion, as that quote of mine was written to Bob
>Jueneman, in regard to Bob Jueneman's comments -- not to Bob Blakley
>nor in regard to Bob Blakley's comments ;-) Please check the message.

Actually, it's a more complicated confusion than you imagine!
I did realize that you were answering Bob J.; I was just interposing myself
into the discussion!  Name capture creates ambiguities of all sorts (type 1
*and* type 2 errors!)

>Thus, it will of course NOT apply to what you would have said. Hovewer,
>what I wrote is correct -- independently of where it is applied. Let me
>prove it:
>
>Suppose, as I said, that each attribute and the key have the same lifetime
>"L" -- thus, for N attributes + 1 key, we have:
>
>1/T = 1/L + 1/L + ...+ 1/L +   1/L
>          ^^^^^^^^^^^^^^^       ^^
>             N attributes               1 key
>
>so that:
>
>1/T = N/L + 1/L  => T = L/(1 + N)

All obviously correct but not on the point I was making, which is that there
are
situations where, because of a lack of independence, N attributes do NOT
give rise to N/L, but instead to only 1/L.

An example of this is the following attribute certificate:

            Attribute 1:    eye-color = gray
            Attribute 2:    blood-type = O positive
            Attribute 3:    name = George Robert Blakley III

Here all attributes have the same lifetime in the sense in which I use the
term -
which happens also to correspond to the naive notion of "lifetime" you'd see
in the dictionary.  I don't know what L is, but I do know that L1 = L2 = L3.

Now if I add some other attributes:

            Attribute 4:    hair-color = brown
            Attribute 5:    weight = 150 (well, approximately :)
            Attribute 6:    height = 5'9"

These all have different L's; Attribute 4 is going to have to be changed to
"hair-color = gray"
based on some kind of majority-rule algorithm pretty soon now - hopefully
before L1 expires!


>>     ...the attributes as a whole will very much lower the certificate
lifetime
>> even
>>     if each attribute and the key have the *same* [expected validity
>> duration].
>>
>> Normally when I think of "lifetime" I think of a validity interval, and if
two
>> things have the same lifetime, they come into existence at exactly the
>> same time and cease to exist at exactly the same time.  In this case
>> there is no independence whatsoever, and the two things should be
>> thought of as essentially one attribute (hence my caveats about
>> independence in earlier notes).
>
>This logic is unfounded. Lifetime is a statistical concept by nature -- since
>it pertains to the future and no future is deterministic (it is easy to prove
>that if any future attribute is deterministic to a measure To in future time,
>then the whole universe must be deterministic to measure To).

But I don't think this is really relevant; you can simply re-cast the problem
in terms of open intervals to take care of minor nondeterminism surrounding
the exact moment of expiry.

>The confusion is thus simple -- two things that have the same lifetime
>do not have to begin at exactly the same time

They certainly don't have to, but in many cases they actually DO.  The
example I gave above is one case; the same information encoded
on a driver's license for me is a derivative which exemplifies
a broad class of certification scenarios from the real world which
also have this property.

>> In order to lower the *lifetime* of the certificate, what's required is
that
>> attributes expire at *different* times
>
>No, as above. Also, if the attributes have the same lifetime but their
>decay rates are non-exponential (eg, a square-function)  then they
>will need to be modeled at least as two exponentials (see my former
>workout of David's example) and they will cause different reductions
>as compared to the pure exponential case (see my example above)..

Except again I think this can be abstracted away using a much less complex
analysis in terms of simple probabilities which will be a correct first-order
approximation of the real behavior of the majority of certification systems
we actually build.


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_015C_01BEA39D.BA417EC0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990521T202224Z
END:VCARD

------=_NextPart_000_015C_01BEA39D.BA417EC0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA21025 for ietf-pkix-bks; Fri, 21 May 1999 12:59:58 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA21021 for <[e-mail]>; Fri, 21 May 1999 12:59:55 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id OAA08557; Fri, 21 May 1999 14:58:36 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id OAA10156; Fri, 21 May 1999 14:58:35 -0500 (CDT)
Message-ID: <012d01bea3c4$a4b81ec0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Linn, John" <[e-mail]>, "Ed Gerck" <[e-mail]>, "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Certificate life-cycle costs.
Date: Fri, 21 May 1999 15:00:58 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_012A_01BEA39A.BBAFBC20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_012A_01BEA39A.BBAFBC20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

John Linn writes

>It strikes me that some consideration of high costs of revocation in PKI
>systems, with a strong attendant goal of minimizing the proportion of
>certificates revoked before their validity expires, has derived from the
>traditional premise of CRL-based revocation. OCSP-based revocation may
>motivate different analysis; if the backing store behind an OCSP responder
>is a non-CRL database describing the status of issued certificates,
>revocation doesn't incur the incremental costs of generating, propagating,
>and maintaining growing CRLs.

This is undoubtedly true, ...

>If CRL management costs are removed, it may
>become reasonable to accept more statistically frequent revocation in order
>to gain the information value of additional certified attributes.

but this really depends on the environment.  Everyone is familiar with the
usual explanation given for the popularity of smartcards in Europe, namely
that the telco infrastructure is so expensive to use that merchants can't
afford
to do online credit-card status verification, so there's value in assigning
this
function to a dialog between the merchant and the card itself.

I don't actually know how much truth there is in this explanation, but I *do*
know
that the economics of online verification are different in Europe and the USA.

I think the high costs of revocation come from several different sources:

(1) The cost to the issuer of actually KNOWING what the correct status of
        a certificate is, and

(2) The cost to the issuer of distributing status information

(3) The cost to the relying party of consulting status information

#2 is certainly different in OCSP vs. CRL configurations; Some constituent
of #3 is also different, but some of the processing is the same for OCSP as
for
CRLs.

#1 is the same in both configurations.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_012A_01BEA39A.BBAFBC20
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990521T200058Z
END:VCARD

------=_NextPart_000_012A_01BEA39A.BBAFBC20--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20947 for ietf-pkix-bks; Fri, 21 May 1999 12:46:16 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20943 for <[e-mail]>; Fri, 21 May 1999 12:46:15 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 21 May 1999 19:44:58 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA21890; Fri, 21 May 1999 15:44:04 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <K8GYF8TD>; Fri, 21 May 1999 15:48:09 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Bob Blakley'" <[e-mail]>, Ed Gerck <[e-mail]>, Bob Jueneman <[e-mail]>
Cc: [e-mail]
Subject: RE: Certificate life-cycle costs.
Date: Fri, 21 May 1999 15:50:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob wrote, excerpting: 
 
> >> So there are two competing trends -- as certificate 
> validity periods
> >> increase, the cost of issuance decreases, but the cost of
> >> reissuance due to a change in the attributes tends to increase.
> >> In addition, as the validity time increases, the cost of carrying
> >> a revoked certificate in a CRL also increases.
> 
> Dan Geer has a very succint statement of this problem, which he
> uses to compare the costs of secret-key and public-key systems.
> He observes that in secret-key systems, the costs tend to be 
> concentrated
> at the time of issuance, whereas in public-key systems they tend to
> be concentrated at the time of validation (e.g. through 
> revocation checks
> etc...).  Hence, as he puts it, "you can pay me now or you 
> can pay me later".
> 

It strikes me that some consideration of high costs of revocation in PKI
systems, with a strong attendant goal of minimizing the proportion of
certificates revoked before their validity expires, has derived from the
traditional premise of CRL-based revocation. OCSP-based revocation may
motivate different analysis; if the backing store behind an OCSP responder
is a non-CRL database describing the status of issued certificates,
revocation doesn't incur the incremental costs of generating, propagating,
and maintaining growing CRLs. If CRL management costs are removed, it may
become reasonable to accept more statistically frequent revocation in order
to gain the information value of additional certified attributes.

--jl


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20887 for ietf-pkix-bks; Fri, 21 May 1999 12:35:15 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20883 for <[e-mail]>; Fri, 21 May 1999 12:35:14 -0700 (PDT)
Received: from mcg.org.br (pm04-02.sac.verio.net [209.162.64.115]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA28981; Fri, 21 May 1999 12:35:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 21 May 1999 12:26:34 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: Certificate life-cycle costs.
References: <005f01bea3ba$6a07e760$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Blakley wrote:

> Ed,
>
> A quibble here
>
> >But your last phrase is, you may realize, contradicted by the equation I
> >presented for the certificate lifetime as the inverse of the sum of the
> >inverses of the atttribute lifetimes contained in it -- because the
> >attributes as a whole will very much lower the certificate lifetime even if  each
> >attribute and the key have the *same* lifetime.
>

> I think this is not quite correct because of imprecise phrasing.  What I
> would have said here is

Bob:

This is a simple confusion, as that quote of mine was written to Bob
Jueneman, in regard to Bob Jueneman's comments -- not to Bob Blakley
nor in regard to Bob Blakley's comments ;-) Please check the message.

Thus, it will of course NOT apply to what you would have said. Hovewer,
what I wrote is correct -- independently of where it is applied. Let me
prove it:

Suppose, as I said, that each attribute and the key have the same lifetime
"L" -- thus, for N attributes + 1 key, we have:

1/T = 1/L + 1/L + ...+ 1/L +   1/L
          ^^^^^^^^^^^^^^^       ^^
             N attributes               1 key

so that:

1/T = N/L + 1/L  => T = L/(1 + N)

which proves my quote:

 "the attributes as a whole will very much lower the certificate
 lifetime even if  each attribute and the key have the *same*
 lifetime."

In fact,  the attributes as a whole will lower the certificate lifetime in
the ratio of N:1 when compared to the key.

Further, just to use the opportunity,  my quote disproves what has been
called here Steve Kent's Rule of Revocation: "The effective lifetime of
a certificate is inversely proportional to the square of the number of
attributes."

If all lifetimes are equal and all decay times are exponential, then the
correct rule is "The effective lifetime of a certificate is inversely
proportional to the number of attributes." If there are P attributes
(including key) then the lifetime is L/P -- as given above for
P = N +1.

However, if all the decay times are abrupt at the end of their validity,
then the correct rule is: "The effective lifetime of a certificate is
inversely proportional to the least lifetime of any attributes." And, this
follows from the same formula 1/T = 1/T1 + 1/T2 + ... 1/TN,
as I have discussed before.

>     ...the attributes as a whole will very much lower the certificate lifetime
> even
>     if each attribute and the key have the *same* [expected validity
> duration].
>
> Normally when I think of "lifetime" I think of a validity interval, and if two
> things have the same lifetime, they come into existence at exactly the
> same time and cease to exist at exactly the same time.  In this case
> there is no independence whatsoever, and the two things should be
> thought of as essentially one attribute (hence my caveats about
> independence in earlier notes).

This logic is unfounded. Lifetime is a statistical concept by nature -- since
it pertains to the future and no future is deterministic (it is easy to prove
that if any future attribute is deterministic to a measure To in future time,
then the whole universe must be deterministic to measure To). The
confusion is thus simple -- two things that have the same lifetime
do not have to begin at exactly the same time (think about an atom
emitting light, and all atoms emitting at different times and yet with the
same radiative lifetime for that transition and all independent -- where
one can be in Alpha Centauri and the other in the kitchen lamp.), neither
will they have to or even be expected to end at exactly the same time
since the future is not deterministic.

> In order to lower the *lifetime* of the certificate, what's required is that
> attributes expire at *different* times

No, as above. Also, if the attributes have the same lifetime but their
decay rates are non-exponential (eg, a square-function)  then they
will need to be modeled at least as two exponentials (see my former
workout of David's example) and they will cause different reductions
as compared to the pure exponential case (see my example above)..

> -- as you've pointed out, either
> the expected validity duration must be very long for each attribute, or
> there must be few independent attributes in order for the certificate
> lifetime to be long.

This is correct -- but I did not include the word "independent" since
the attributes do not have to be independent for the phrase to apply.

> The paper some years back by Masse and Fernandes of Chait Amyot
> makes Ed's point about risk being borne by the wrong party in "traditional"
> PKI trust models and suggests that the relying party's risk has to be
> correctly accounted for or else these systems won't work properly.
> It's a long paper, but interesting:
>
>     http://www.chait-amyot.ca/docs/pkif.htm
>

Thanks for the reference -- and the comments.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20532 for ietf-pkix-bks; Fri, 21 May 1999 11:46:59 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20527 for <[e-mail]>; Fri, 21 May 1999 11:46:58 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id NAA08375; Fri, 21 May 1999 13:45:24 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id NAA09982; Fri, 21 May 1999 13:45:22 -0500 (CDT)
Message-ID: <005f01bea3ba$6a07e760$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Certificate life-cycle costs.
Date: Fri, 21 May 1999 13:47:44 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_005C_01BEA390.80FF84C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01BEA390.80FF84C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ed,

A quibble here

>But your last phrase is, you may realize, contradicted by the equation I
>presented for the certificate lifetime as the inverse of the sum of the
>inverses of the atttribute lifetimes contained in it -- because the
attributes
>as a whole will very much lower the certificate lifetime even if  each
>attribute and the key have the *same* lifetime.

I think this is not quite correct because of imprecise phrasing.  What I
would have said here is

    ...the attributes as a whole will very much lower the certificate lifetime
even
    if each attribute and the key have the *same* [expected validity
duration].

Normally when I think of "lifetime" I think of a validity interval, and if two
things have the same lifetime, they come into existence at exactly the
same time and cease to exist at exactly the same time.  In this case
there is no independence whatsoever, and the two things should be
thought of as essentially one attribute (hence my caveats about
independence in earlier notes).

In order to lower the *lifetime* of the certificate, what's required is that
attributes expire at *different* times -- as you've pointed out, either
the expected validity duration must be very long for each attribute, or
there must be few independent attributes in order for the certificate
lifetime to be long.

>> So there are two competing trends -- as certificate validity periods
>> increase, the cost of issuance decreases, but the cost of
>> reissuance due to a change in the attributes tends to increase.
>> In addition, as the validity time increases, the cost of carrying
>> a revoked certificate in a CRL also increases.

Dan Geer has a very succint statement of this problem, which he
uses to compare the costs of secret-key and public-key systems.
He observes that in secret-key systems, the costs tend to be concentrated
at the time of issuance, whereas in public-key systems they tend to
be concentrated at the time of validation (e.g. through revocation checks
etc...).  Hence, as he puts it, "you can pay me now or you can pay me later".

>The two competing trends only exist if both certificate issuance and
>certificate validity are CA-centric. If one of them is not, the "loop"
>is at least partially broken -- for example, if certificate validity is not
>CA-centric (as above discussed) then the r-p can apply different decay
>times for each attribute and calculate an instantaneous confidence limit
>for each different  use of the certificate, at different times. Certificate
>validity is then IMO properly centered on the r-p --  who is
>the party at risk *and* knows what the certificate is being used for.
>This allows the r-p to cope with  revoked but partially valid certificates
>("false positives" as mentioned by Blakley as his concern), with
>expired but unrevoked certificates (as I exemplified in time logic),
>and other combinations of validity qualifiers.

The paper some years back by Masse and Fernandes of Chait Amyot
makes Ed's point about risk being borne by the wrong party in "traditional"
PKI trust models and suggests that the relying party's risk has to be
correctly accounted for or else these systems won't work properly.
It's a long paper, but interesting:

    http://www.chait-amyot.ca/docs/pkif.htm

>Alternatively, to center it on the CA will introduce artificial conflicts
>(as you describe above) and increase r-p risks.
>
>> My expectation is that these competing trends are likely to
>> add together, producing a classic bathtub curve that may be quite
>> shallow, indicating that the total cost is relatively insensitive
>> to certificate validity periods.


I don't really think this is likely, at least for certs. with lots of
attributes.



Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_005C_01BEA390.80FF84C0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990521T184744Z
END:VCARD

------=_NextPart_000_005C_01BEA390.80FF84C0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20385 for ietf-pkix-bks; Fri, 21 May 1999 11:29:14 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20381 for <[e-mail]>; Fri, 21 May 1999 11:29:12 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id NAA08328; Fri, 21 May 1999 13:27:28 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id NAA09936; Fri, 21 May 1999 13:27:25 -0500 (CDT)
Message-ID: <005001bea3b7$e84c26c0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: Re: Why do attr. cert. lifetimes matter?,was Example with sub-attributes
Date: Fri, 21 May 1999 13:29:48 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_004D_01BEA38D.FF761EC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_004D_01BEA38D.FF761EC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Anders,

Thanks for your note.


>Sorry, I don't understand how this works.  How do authentication with
key-less certs?

Ah!  This is where we've not been communicating.  I'm presuming that keyless
attribute
certs are NOT used for authentication; they're used to assert a third-party
view of
the attributes of the possessor.

Authentication would be done using a keyed cert., and the keyless attribute
cert, which
might or might not contain the distinguished name as a link back to the
authentication
cert., would be transmitted within the authenticated communication
susequently.

The point here is that the authority asserting the attributes may be
*different* from
the one asserting principal names; indeed many authorities may assert
attributes about the
same principal name.  The authentication operation establishes the principal
name by
showing possession of the private key matching the "identity cert" (not really
any such thing,
of course - it's really just a name cert).  Then a subsequent operation (AC
verification)
establishes attributes, based on the assumption that the principal name is
correct.

>>>Then (using my maybe naive thinking) there is no need for CAs, revocation,
>>CRLs or OCSPs for ACs.  Only for PKCs.
>>>And PKCs are typically issued by TTPs and therefore none of the listed
issues
>>apply.
>>
>>I don't get this at all!  How does the relying party know *when* the
>>organization's CA fabricated the AC?
>
>Well, maybe we should not talk about CA when it is really as signed message
object in
>the form of an AC?
>
>>And why use a cert. for this at all -- after all, Public-Key
>>operations are expensive compared
>>to other ways of doing what is essentially first-party trust.
>
>You are right!  You have just invented the "crippled AC" that just contains
the
>validity-time and attributes.  There could be some value in keeping the
format
>compatible with other ACs though.

Is this really an invention of mine?  Hmmm...

My notion here is that there's a *credential*, which is just a packet of
attributes,
and an AC, which is formed by adding a lifetime, serial number, and some other
housekeeping stuff to the credential and then signing the result.

If all the housekeeping stuff (signature, lifetime, etc...) checks out, then
the
recipient can feel confident using the attributes for authorization or other
decisions,
as long as the link back to the authentication cert. establishes that you're
really
talking to the subject to whom the AC was issued.

Is this different from others' view of how ACs are structured and used?

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_004D_01BEA38D.FF761EC0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990521T182948Z
END:VCARD

------=_NextPart_000_004D_01BEA38D.FF761EC0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA19144 for ietf-pkix-bks; Fri, 21 May 1999 09:52:33 -0700 (PDT)
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA19139 for <[e-mail]>; Fri, 21 May 1999 09:52:31 -0700 (PDT)
Received: from [158.152.35.12] (helo=nplaptop1) by finch-post-11.mail.demon.net with smtp (Exim 2.12 #1) id 10ksXP-000GpO-0B; Fri, 21 May 1999 16:52:47 +0000
From: "Nick Pope" <[e-mail]>
To: <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Date: Fri, 21 May 1999 17:51:37 +0100
Message-ID: <001f01bea3aa$3110b960$020aa8c0@nplaptop1>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This seems to be a bit of a Blunderbus approach.  It may well hit a number
of things that wasn't intended and may well miss what we were aiming at.

Nick

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 21 May 1999 17:12
> To: Stephen Kent
> Cc: Nick Pope; [e-mail]; [e-mail]
> Subject: RE: Rename Qualified Certificates?
>
>
> I agree with Steve and Hoyt that we certificate policy qualifiers
> are a good
> place for fields qualifying such things as signature authority
> amounts.  So,
> even though RFC 2459 section 4.2.1.5
> "strongly recommends that use of qualifiers be limited to those
> identified in
> this section", of which there are only two, which suggests to me that new
> extensions are should be used instead, I'd like to submit some
> proposed generic
> qualifier syntaxes for discussion.  These are quite large to
> reduce the number
> of qualifiers people would need to add to their ASN.1 parsers:
>
> PrimitiveField      ::=  SEQUENCE  {
>      fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
>      CHOICE    {
>      number         NumericString,
>      printable PrintableString,
>      wideChar  BMPString,
>      universal UTF8String,
>      hugeChar  UniversalString,
>      ascii          IA5String,
>      boolean   BOOLEAN,
>      int       INTEGER,
>      realValue REAL,
>      boolArray BIT STRING,
>      bitData        [29] IMPLICIT BIT STRING,
>      blob      OCTET STRING,
>      omitted        NULL,
>      id        OBJECT IDENTIFIER,
>      time      GeneralizedTime,
>      oldTime   UTCTime
>      }
> }
>
> InternetField  ::=  SEQUENCE  {
>      fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
>      CHOICE    {    -- mainly extracted from GeneralName
>      generalNames        SEQUENCE OF GeneralName,
>      otherName      [0]  INSTANCE OF OTHER-NAME,
>      rfc822Name          [1]  IMPLICIT IA5String,
>      dNSName        [2]  IMPLICIT IA5String,
>      x400Address         [3]  IMPLICIT ORAddress,
>      directoryName       [4]  IMPLICIT Name,
>      ediPartyName        [5]  IMPLICIT EDIPartyName,
>      uniformResourceIdentifier     [6]   IMPLICIT IA5String,
>      iPAddress      [7]  IMPLICIT OCTET STRING,
>      registeredID        [8]  IMPLICIT OBJECT IDENTIFIER,
>      TCPPort        [10] IMPLICIT INTEGER,
>      UDPPort        [11] IMPLICIT INTEGER,
>      OSIPSAP        [12] IMPLICIT SEQUENCE OF OCTET STRING
>      }
> }
>
> FinancialAmount     ::=  SEQUENCE
> {    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
>      Currency  PrintableString,               -- e.g. "USD" for
> U.S. Dollar
>      CHOICE    {
>           amount         NumericString,
>           value          INTEGER         -- no need for floating-point
>      }
> }
>
>      Tom Gindin
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18681 for ietf-pkix-bks; Fri, 21 May 1999 09:13:04 -0700 (PDT)
Received: from smtp7.ny.us.ibm.com (smtp7.ny.us.ibm.com [198.133.22.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA18677 for <[e-mail]>; Fri, 21 May 1999 09:13:02 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp7.ny.us.ibm.com (8.8.8/8.8.7) with ESMTP id MAA69064; Fri, 21 May 1999 12:13:29 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id MAA233096; Fri, 21 May 1999 12:12:47 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256778.005905CA ; Fri, 21 May 1999 12:12:21 -0400
X-Lotus-FromDomain: IBMUS
To: Stephen Kent <[e-mail]>
cc: "Nick Pope" <[e-mail]>, [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 21 May 1999 12:12:05 -0400
Subject: RE: Rename Qualified Certificates?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Steve and Hoyt that we certificate policy qualifiers are a good
place for fields qualifying such things as signature authority amounts.  So,
even though RFC 2459 section 4.2.1.5
"strongly recommends that use of qualifiers be limited to those identified in
this section", of which there are only two, which suggests to me that new
extensions are should be used instead, I'd like to submit some proposed generic
qualifier syntaxes for discussion.  These are quite large to reduce the number
of qualifiers people would need to add to their ASN.1 parsers:

PrimitiveField      ::=  SEQUENCE  {
     fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
     CHOICE    {
     number         NumericString,
     printable PrintableString,
     wideChar  BMPString,
     universal UTF8String,
     hugeChar  UniversalString,
     ascii          IA5String,
     boolean   BOOLEAN,
     int       INTEGER,
     realValue REAL,
     boolArray BIT STRING,
     bitData        [29] IMPLICIT BIT STRING,
     blob      OCTET STRING,
     omitted        NULL,
     id        OBJECT IDENTIFIER,
     time      GeneralizedTime,
     oldTime   UTCTime
     }
}

InternetField  ::=  SEQUENCE  {
     fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
     CHOICE    {    -- mainly extracted from GeneralName
     generalNames        SEQUENCE OF GeneralName,
     otherName      [0]  INSTANCE OF OTHER-NAME,
     rfc822Name          [1]  IMPLICIT IA5String,
     dNSName        [2]  IMPLICIT IA5String,
     x400Address         [3]  IMPLICIT ORAddress,
     directoryName       [4]  IMPLICIT Name,
     ediPartyName        [5]  IMPLICIT EDIPartyName,
     uniformResourceIdentifier     [6]   IMPLICIT IA5String,
     iPAddress      [7]  IMPLICIT OCTET STRING,
     registeredID        [8]  IMPLICIT OBJECT IDENTIFIER,
     TCPPort        [10] IMPLICIT INTEGER,
     UDPPort        [11] IMPLICIT INTEGER,
     OSIPSAP        [12] IMPLICIT SEQUENCE OF OCTET STRING
     }
}

FinancialAmount     ::=  SEQUENCE
{    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
     Currency  PrintableString,               -- e.g. "USD" for U.S. Dollar
     CHOICE    {
          amount         NumericString,
          value          INTEGER         -- no need for floating-point
     }
}

     Tom Gindin




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18357 for ietf-pkix-bks; Fri, 21 May 1999 08:47:34 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18353 for <[e-mail]>; Fri, 21 May 1999 08:47:32 -0700 (PDT)
Received: from DHARTER (d5-s17-49-telehouse.mistral.co.uk [195.184.228.49]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id PAA07090; Fri, 21 May 1999 15:47:27 +0100
Received: by DHARTER with Microsoft Mail id <01BEA3A9.AEC502E0@DHARTER>; Fri, 21 May 1999 16:47:58 +0100
Message-ID: <01BEA3A9.AEC502E0@DHARTER>
From: Darren Harter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'PKIX Mailing List'" <[e-mail]>
Subject: RE: No subject given
Date: Fri, 21 May 1999 16:47:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA18354
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Will,

Comments/thoughts inline...

-----Original Message-----
From:	[e-mail] [SMTP:[e-mail]]
Sent:	Friday, May 21, 1999 2:16 PM
To:	[e-mail]
Subject:	No subject given


[DH]  Intro snipped.
     
In order to help me identify an issuer, I will find in the certificate the 
issuing entity's DN. I also have none, any or all of the following:
     
     -issuer serial number
     -issuer key Id
     -issuer unique Id
     
1) Suppose, first, that none of these are present, but I find two 
(or more) certificates owned by the entity named in the issuer field of C1. 
How do I distinguish which is the right one?  I assume I can only try 
to verify the signature on C1 with the key in each of the candidate 
issuers, and see which one works. It is possible, I assume, that both 
may work if a CA has had the same key certified by two superior CAs. 
In that case I have to fork my candidate chains, keep going until I 
find a root and then check that the root policies are acceptable.

[DH]  One possible way to distinguish them would be through the algorithm.  Ensure that the algorithm specified in the body of C1 matches the algorithm in the Subject Public Key info of the candidate cert.
     
Effectively I use signature verification to distinguish which 
certificate to use. But this means that I cannot distinguish between 
signature verification failing due to a forged/corrupted subject 
certificate, and due to a wrong choice of issuer. So if I find only 
one certificate locally, and the signature does not verify, this might 
be simply because I have the wrong issuer certificate; and I will 
return a false negative. 

[DH]  I tend to verify the signatures after I've found a trusted root.  Build up a tree of possible certification paths, but only validate the one with a trusted root at the top.  If you have more than one with a trusted root just pick one.  Working this way also allows you to cope with cross certification without verifying the sig on a non-trusted root cert.

[DH]  IMHO you should not use the public key from any cert until you have verified the signature of that cert. A consequence of this is that you cannot verify the sig on C1 until you have verified the sig on its issuer cert - unless the issuer cert is one of your trusted roots.

Is it permissible for a CA to have the same key certified by two different 
CAs? If so, it seems that it would be possible for a two certificates to have 
the same issuer name and serial number, which seems wrong. 

[DH]  The answer to the first part is clearly yes.  But your second assumption doesn't hold.  It is the responsibility of each CA to ensure that it never generates certificates with duplicate serial numbers.  You never get two certs with the same serial number from the same issuer.  In your case you have two different issuers and therefore two different issuer DNs.  the serial number sets are therefore distinct.  You could of course have to different DNs but have the same serial number
     
2) Suppose the certificate does contain an issuer serial number, but I 
don't have a certificate locally with that DN + serial number. 
However, I do have a certificate locally with that DN, and this 
certificate contains the same key, which therefore successfully 
verifies C1. Is it acceptable for me to use this as my issuer 
certificate? It is of course possible that I'm not processing the 
authority key identifier at all, in which case I don't even realise 
that this may be an issue.  

[DH]  Part of the answer to this is a local security policy issue.  If your app only understands v1 or v2 certs you can use it (subject to local policy).  If your app does understand v3 certs but does not handle Authority Key Identifier AND it is not critical present then you could again use the cert.  However, if your app does understand Authority Key Identifier or it is critical you cannot use the cert.

Are these scenarios even valid?

Thanks,

Will
 
Hope this all helps,

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
http://www.entegrity.com
Tel:  [phone]
Fax: [phone]
Cell: [phone]
Email: mailto:[e-mail]

 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA17602 for ietf-pkix-bks; Fri, 21 May 1999 06:52:30 -0700 (PDT)
Received: from mail.motus.qc.ca (jplachance.motus.qc.ca [207.236.155.216]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA17598 for <[e-mail]>; Fri, 21 May 1999 06:52:28 -0700 (PDT)
Received: from nmaestre by mail.motus.qc.ca (Lotus SMTP MTA v1.06 (346.8 3-18-1997)) with SMTP id 85256778.004C82B2; Fri, 21 May 1999 09:51:36 -0400
Message-ID: <00f101bea391$b5c16b50$[e-mail]>
From: "Nanette Maestre" <[e-mail]>
To: <[e-mail]>
Date: Fri, 21 May 1999 09:56:22 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01BEA370.2E92CD70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00EE_01BEA370.2E92CD70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

subscribe

------=_NextPart_000_00EE_01BEA370.2E92CD70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>subscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_00EE_01BEA370.2E92CD70--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16938 for ietf-pkix-bks; Fri, 21 May 1999 05:18:23 -0700 (PDT)
Received: from mailgate.psion.com (mailgate.symbian.com [194.129.1.246]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16934 for <[e-mail]>; Fri, 21 May 1999 05:18:22 -0700 (PDT)
From: [e-mail]
Received: from software-data1.symbian.com (smtpgate2.symbian.com [194.129.2.236] (may be forged)) by mailgate.psion.com (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP id NAA02488 for <[e-mail]>; Fri, 21 May 1999 13:16:22 +0100
Received: from ccMail by software-data1.symbian.com (ccMail Link to SMTP R8.20.00.25) id AA927288852; Fri, 21 May 1999 13:14:15 GMT
Message-Id: <[e-mail]>
X-Mailer: ccMail Link to SMTP R8.20.00.25
Date: Fri, 21 May 1999 13:15:46 GMT
To: <[e-mail]>
Subject: No subject given
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: "cc:Mail Note Part"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     
Hi,
     
In the process of implementing a PKIX compliant certificate management 
client, I have come across some strangeness in the PKIX certificate 
chain construction process, and I'd be very grateful if anyone can 
shed any light.
     
Starting at the beginning: I receive a certificate ostensibly 
belonging to a sender (C1), and I want to find the certificate that 
issued it in order to construct a complete chain back to a trusted 
root. There are three places where I might find the issuer cert: a 
local store of trusted root certs, a collection of untrusted 
certs handed to me by client code, and a remote repository 
containing untrusted intermediate certs. 
     
In order to help me identify an issuer, I will find in the certificate the 
issuing entity's DN. I also have none, any or all of the following:
     
     -issuer serial number
     -issuer key Id
     -issuer unique Id
     
1) Suppose, first, that none of these are present, but I find two 
(or more) certificates owned by the entity named in the issuer field of C1. 
How do I distinguish which is the right one?  I assume I can only try 
to verify the signature on C1 with the key in each of the candidate 
issuers, and see which one works. It is possible, I assume, that both 
may work if a CA has had the same key certified by two superior CAs. 
In that case I have to fork my candidate chains, keep going until I 
find a root and then check that the root policies are acceptable.
     
Effectively I use signature verification to distinguish which 
certificate to use. But this means that I cannot distinguish between 
signature verification failing due to a forged/corrupted subject 
certificate, and due to a wrong choice of issuer. So if I find only 
one certificate locally, and the signature does not verify, this might 
be simply because I have the wrong issuer certificate; and I will 
return a false negative. 

Is it permissible for a CA to have the same key certified by two different 
CAs? If so, it seems that it would be possible for a two certificates to have 
the same issuer name and serial number, which seems wrong. 
     
2) Suppose the certificate does contain an issuer serial number, but I 
don't have a certificate locally with that DN + serial number. 
However, I do have a certificate locally with that DN, and this 
certificate contains the same key, which therefore successfully 
verifies C1. Is it acceptable for me to use this as my issuer 
certificate? It is of course possible that I'm not processing the 
authority key identifier at all, in which case I don't even realise 
that this may be an issue.  

Are these scenarios even valid?

Thanks,

Will
  



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA21287 for ietf-pkix-bks; Thu, 20 May 1999 19:23:28 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA21283 for <[e-mail]>; Thu, 20 May 1999 19:23:26 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 07256778.000CE664 ; Thu, 20 May 1999 19:20:54 -0700
X-Lotus-FromDomain: BULL
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 19:23:20 -0700
Subject: RE: Rename Qualified Certificates?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello, i rarely stick my oar into these conversations but this is an
important point to me.

steve's proposal is what i thought we intended so long ago when we designed
the public key certificate policy information. i have been somewhat bemused
with certificates holding long human consumable text strings (long enough
without even being localized).

i had hoped that for example, a certificate policy might specify that the
certificate can only be used in support of a transaction whose value did
not exceed a value contained in the policy qualifier (which may hold a
structure with that value specified in several currencies) and that the
relying party software would inforce the policy rule, not the humans using
the system.

 some time ago at an aba information security committee meeting, i proposed
a briefly explored idea that a standard form contract could be identified
in the cp while modifications to that contract, e.g. excluded clauses,
would be specified in the qualifier. i believe the significant value  is
not that some consumer can study the contract, but that the relying
application can understand how each value in the policy qualifier affects
what the application will do (assuming we move beyond limited browser
handling of the certificate and its policy - mobile code seems to be the
enabler for this)

i am not happy with overloaded certificates but my first target would be
eliminating long text strings. i know this requires a program that can
intelligently handle the values in the certificate. then i believe that it
is possible that some information, common across a large number of
certificates, could be contained in a separate signed structure, e.g.
another certificate. but i also want to avoid giving the relying party any
more signed structures to verify than necessary. what if i reduce the size
of the public key certificate but am required to verify two certificates
instead of one.

i don't beleive we can avoid some of those structures however. for example,
if we want to identify a policy with an object id, then assuming the rely
party can get to that policy and supporting mobile code, how does the
relying party know it is working with the intended policy definition? one
approach is a standardized structure that holds the object id of the
policy, names of and pointers to mobile code, and other relevant
information. that structure would be signed by the CA that issued the
certificate or by some other entity whose relationship to the issuing CA is
specified. however, the retrieval, verification,  and evaluation of this
structure shouldn't have to be done for every transaction but only in the
initialization of support for the identified policy.

i realize that if one's focus is on non-augmented browser use, none of what
i propose is useful. my comments are based on the hope that we will move
away from such lowest common denominator use.

    hoyt




Stephen Kent <[e-mail]> on 05/20/99 02:57:49 PM

To:   "Nick Pope" <[e-mail]>
cc:   "Stephen Kent" <[e-mail]>, [e-mail] (bcc: Hoyt
      Kesterson/US/BULL)
Subject:  RE: Rename Qualified Certificates?




Nick,

>I agree with the aim of not over-loading a certificate.  However, I don't
>want to go too far the other way and overload the policy id so that a new
>policy id is required for any minor variation on the use certificates
within
>a common overall policy.

Fair comment.  One might use a new extension, as Bob Junenman suggested,
although when I look at policy qualifiers I see a ready made place to plug
in a range of values for approval authority, currency and max value for
liability, etc.

Steve






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA17918 for ietf-pkix-bks; Thu, 20 May 1999 16:12:59 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA17914 for <[e-mail]>; Thu, 20 May 1999 16:12:58 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 20 May 1999 17:12:36 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 20 May 1999 17:12:29 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA17915
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve, as I replied to Nick off list, I think we have to differentiate
between attributes such as currency type and maximum liability,
which may have to be negotiated individually with the user, rather than
being CA-centric, vs. an indication of approval authority, which is certainly 
static and hence could go in the policy qualifier if necessary.

I confess to being averse to policy qualifiers that are not by themselves
meaningfully machine readable, which is why I lean towards including
such Trust In Advertising details in the certificate itself, where it will
be very readily visible, even at the cost of a few more bytes in the certificate.

Bob

>>> Stephen Kent <[e-mail]> 05/20/99 03:57PM >>>
Nick,

>I agree with the aim of not over-loading a certificate.  However, I don't
>want to go too far the other way and overload the policy id so that a new
>policy id is required for any minor variation on the use certificates within
>a common overall policy.

Fair comment.  One might use a new extension, as Bob Junenman suggested,
although when I look at policy qualifiers I see a ready made place to plug
in a range of values for approval authority, currency and max value for
liability, etc.

Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17312 for ietf-pkix-bks; Thu, 20 May 1999 15:05:19 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17308 for <[e-mail]>; Thu, 20 May 1999 15:05:18 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA05244; Thu, 20 May 1999 18:05:27 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a03b36a356789c1@[128.89.0.110]>
In-Reply-To: <001501bea2d5$3cb82f30$0500000a@npwork2>
References: <v04020a09b369bcd1c104@[128.33.238.64]>
Date: Thu, 20 May 1999 17:57:49 -0400
To: "Nick Pope" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nick,

>I agree with the aim of not over-loading a certificate.  However, I don't
>want to go too far the other way and overload the policy id so that a new
>policy id is required for any minor variation on the use certificates within
>a common overall policy.

Fair comment.  One might use a new extension, as Bob Junenman suggested,
although when I look at policy qualifiers I see a ready made place to plug
in a range of values for approval authority, currency and max value for
liability, etc.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17246 for ietf-pkix-bks; Thu, 20 May 1999 14:55:44 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17242 for <[e-mail]>; Thu, 20 May 1999 14:55:43 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA04478; Thu, 20 May 1999 17:55:46 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a02b36a34b6601c@[128.89.0.110]>
In-Reply-To: <51BF55C30B4FD1118B4900207812701E38F8F0@WUHER>
Date: Thu, 20 May 1999 17:54:34 -0400
To: Sarbari Gupta <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari,

PKIX has distinguished between time stamping, where only a hash is sent and
a proof of existance is the goal, vs. data certification, where one might
want the authority to make additional attestations about what is being
certified.  Som on that basis, I think Roberto's comments are in keeping
with the discussions that have transpired at PKIX meetings.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16719 for ietf-pkix-bks; Thu, 20 May 1999 14:01:40 -0700 (PDT)
Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16715 for <[e-mail]>; Thu, 20 May 1999 14:01:39 -0700 (PDT)
Received: from exccup-conn01.mis.tandem.com (exccup-conn01.mis.tandem.com [130.252.226.231]) by Tandem.com (8.9.3/2.0.1) with ESMTP id OAA00239; Thu, 20 May 1999 14:01:49 -0700 (PDT)
Received: by exccup-conn01.mis.tandem.com with Internet Mail Service (5.5.2559.0) id <JS2VYL22>; Thu, 20 May 1999 14:01:48 -0700
Message-ID: <[e-mail]>
From: "Kurn, David" <[e-mail]>
To: "Robert Zuccherato (E-mail)" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Thu, 20 May 1999 14:01:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2559.0)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks

A thought about the signed error question.

If we return unsigned error values, and sign only the "good" responses, then
the only thing the verifier can say is "not validated".  It's sort of like
the subtle difference in a jury trial between the actual verdict of "not
guilty", and the oft-claimed result of "innocent".

A signed result lets the verifier conclude something and act upon it.  An
unsigned result leaves the verifier unable to act.

I'm not sure that an "uncertain" result is that desireable, nor am I certain
that actual applications doing the verification can do anything useful from
a situation indistinguishable from "no answer".

David Kurn
Compaq Computer Corp
Cupertino CA


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16286 for ietf-pkix-bks; Thu, 20 May 1999 13:22:18 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16282 for <[e-mail]>; Thu, 20 May 1999 13:22:15 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATM4M>; Thu, 20 May 1999 16:24:11 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8FC@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "Robert Zuccherato (E-mail)" <[e-mail]>
Cc: "PKIX (E-mail)" <[e-mail]>
Subject: Do we need to authenticate error status and nonce information in  TSA responses?
Date: Thu, 20 May 1999 16:24:10 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert, 

I have been thinking some more about the actual need to authenticate the
error messages that come back from the TSA. The conclusion I came to,
is, that it buys us very little or nothing. Information is only worth
securing if there is a way for someone to profit from it when the
information is not secured. So, Denis' proposal for unsigned error
returns seems adequate.

Let's think about it from the point of view of an attacker. What happens
if we don't sign an error message from the TSA? An attacker can
substitute the actual error code with a different error code and make
the TSA client think that their request failed for a different reason.
The only gain for the attacker is thus denial-of-service against the TSA
client. Now consider the opposite scenario where signed error messages
are sent out by the TSA. Even in this case, the attacker can mount a
denial-of-service attack by simply deleting the signed error message and
not letting the TSA client receive it. 

My feeling is that the only item that a TSA can return that requires to
be authenticated is a time stamp token (TST), which, of course, needs to
be signed.

I would claim that the protocols in the timestamp I-D can be simplified
by using the SignedData structure to hold the TST (without status and
nonce) while the status and nonce are passed back (unsigned). Thus, the
response from a TSA can be defined as a TSAResponse structure as
follows. 

TSAResponse ::= SEQUENCE {
	status	PKIStatusInfo,
	nonce 	Integer OPTIONAL,
	timeStampToken 	SignedData }

In spite of the above, if someone wants to add authentication to the TSA
response, they can make use of a secure transport mechanism. 

Comments? Thoughts?

- Sarbari
	
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA15380 for ietf-pkix-bks; Thu, 20 May 1999 12:35:41 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA15376 for <[e-mail]>; Thu, 20 May 1999 12:35:41 -0700 (PDT)
Received: from mcg.org.br (pm09-23.sac.verio.net [209.162.65.136]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA16491; Thu, 20 May 1999 12:35:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 12:26:51 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
CC: Bob Jueneman <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Example with sub-attributes,was  Re: Attribute certificatelifetimes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Williams wrote:

> If one changes the axis of this argument to
> the lifetime of a directory/repository entry, does
> anything change?

No. The lifetime you mention is simply a sub-attribute
lifetime and can taken into account as another term in
the relevant equation I presented:

1/T = 1/T1 + 1/T2 + ...+ 1/TN

In other words, your example is one unseen or implict
attribute from the certificate's syntax viewpoint. But, I
can also easily include others -- for example, if I include
the expected lifetime of the business entity behind that
directory/repository.

As you may see, this is, in all formal aspects, similar to
the root CA cert case I mentioned in my quoted posting
as an example -- and which may further clarify the issue
by recall:

> The a priori decay of trust with time is what makes
> the attribute validity decay for the a priori determination
> of its lifetime. This also shows that a certificate has many
> unseen attributes, if you recall the list I used to discuss
> the topics, which will nonetheless reduce its lifetime. One
> example, of several discussed in
> http://www.mcg.org.br/cert.htm , is the validity of the CA
> signing certificate -- which is not mentioned in the
> subscriber certificate as an attribute but can render it
> invalid if the CA cert expires or is revoked before the
> subscriber's certificate lifetime expires.

> The reason I ask is that a certificate is actually
> no longer valid in many legalistic practices models when
> the "official" certificate management repository is
> modified - to reflect the change in status.
>
> A 2459 PKI is perhaps modeled as a function
> of three macro variables - the lifetime of
> a cert,  the lifetime of the repository entry, and the
> lifetime of the CRL/OCSP-Responses (if used).

All these issues can be included in the equation I
presented, as well as any explicit or implicit attribute.

To exemplify, if companies A and B certify each other's
public-key  by relying on each other's Verisign certificate
then, clearly, they are legally bound by Verisign's CPS
in relationship to each other in the reverse role of a
relying-party. However, after this X.509/PKIX step,
companies A and B can directly challenge each other's
key and increase their mutual level of reliance if the
challenges are sucessful. Further, as their relationship
progresses over one year of mutually satisfying
business they may decide that they now trust those
public-keys by themselves and not because Verisign
says that they respectively belong to a string named
A and another string named B.  Moreover, they
can so express in contract law terms at any moment
and be even more legally bound to accepting each
other's keys -- even when those two Verisign certificates
are actually no longer valid. After all, they control the
private-keys, they supplied their names and data for
the certificates, they bought the certificates, they were
the ones initially responsible both for CRL request
as well as CRL verification even when Verisign validity
was granted and, nothing that Verisign would do, or not
do, could possibly harm them after that Verisign validity
period is ended.

As exemplified above, the *same* certificate could afford
increased lifetimes in the progression of the different
contexts presented -- even legally. And, in all cases,
the same lifetime equation would apply, though with
a different number of attribute lifetimes and respective
values.

Also, as I showed before, it does not matter if legal reliance
follows a square-function time decay (for example, a CA
contract that is 100% valid for one year and then abruptly
terminates). Still, the equation I presented can be applied
piecewise, for each validity region -- so that the *same*
certificate can even offer a longer expected lifetime afer one
year (when the CA contract is expired) than before.

Your question has thus a further importance in that, IMO,
it clearly shows the broad framework of that equation --
which can encompass all issues relevant to certificate
lifetime and take them into account irrespective of
the axis of the discussion. By properly grouping the
atrributes in the equation, one can also compare classes
of attributes as I commented in reply to Bob Jueneman's
last posting -- that I insert here for completness:

 "But your last phrase is, you may realize, contradicted
 by the equation I presented for the certificate lifetime
 as the inverse of the sum of the inverses of the atttribute
 lifetimes contained in it -- because the attributes as a
 whole will very much lower the certificate lifetime even
 if  eachattribute and the key have the *same* lifetime."

Further, by using the technique of Pade' approximants,
when that equation is expanded in continued fractions,
I can build a convergent series of approximants where
attribute lifetimes are taken into account by their relative
values -- instead of just truncating the equation at some
index, which would mean an absolute cut-off with an
arbitrary reference. This illustrates a third important point
to be derived from your question -- that different argument
axis (i.e., different attribute class in focus) may be relatively
rated so that we can taken into account first those attribute
classes that have a higher relative importance for the problem
at hand -- which class may differ from relying-party to relying-
party.


Cheers,

Ed Gerck


> On Wednesday, May 19, 1999 8:50 PM, Ed Gerck [SMTP:[e-mail]] wrote:
> >
> >
> > Bob Jueneman wrote:
> >
> > > Ed,
> > >
> > > There must be a pony in here somewhere, but other than an interesting
> > > mathematical exercise, I'm not sure that I can put my finger on it yet.
> >
> > Bob:
> >
> > Well, perhaps this deserves more than just a "pony award" ;-)
> >
> > Because, in my view, it answers the fundamental question that must
> > be addressed *before* a certificate is ever issued: "What is to be
> > this certificate's stated lifetime so that its data is expectedly
> > valid during its lifetime?".



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14985 for ietf-pkix-bks; Thu, 20 May 1999 12:17:53 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14976 for <[e-mail]>; Thu, 20 May 1999 12:17:41 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id VAA32125 for <[e-mail]>; Thu, 20 May 1999 21:17:50 +0200
Received: from mega (t3o69p96.telia.com [62.20.145.96]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA62541; Thu, 20 May 1999 21:17:49 +0200
Message-ID: <007c01bea2fd$8c50be40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Bob Blakley" <[e-mail]>, <[e-mail]>
Subject: Re: Why do attr. cert. lifetimes matter?,was Example with sub-attributes
Date: Thu, 20 May 1999 21:15:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA14982
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,

<snip>
>This is one scenario, but it's certainly also plausible that you could get
>ONLY an AC, for example
>in cases involving role-based authorization where you want to authenticate the
>user and then
>assert a role but not the primary identity (this might be important for
>privacy reasons, e.g.)

Sorry, I don't understand how this works.  How do authentication with key-less certs?

>>Then (using my maybe naive thinking) there is no need for CAs, revocation,
>CRLs or OCSPs for ACs.  Only for PKCs.
>>And PKCs are typically issued by TTPs and therefore none of the listed issues
>apply.
>
>I don't get this at all!  How does the relying party know *when* the
>organization's CA fabricated the AC?

Well, maybe we should not talk about CA when it is really as signed message object in
the form of an AC?

>And why use a cert. for this at all -- after all, Public-Key
>operations are expensive compared
>to other ways of doing what is essentially first-party trust.

You are right!  You have just invented the "crippled AC" that just contains the
validity-time and attributes.  There could be some value in keeping the format
compatible with other ACs though.  

regards
Anders



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13980 for ietf-pkix-bks; Thu, 20 May 1999 11:31:53 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13976 for <[e-mail]>; Thu, 20 May 1999 11:31:52 -0700 (PDT)
From: [e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id OAA20628 for <[e-mail]>; Thu, 20 May 1999 14:41:17 -0400 (EDT)
Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id OAA22162 for <[e-mail]>; Thu, 20 May 1999 14:28:36 -0400 (EDT)
Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.5  (860.1 5-12-1999))  id 85256777.0065A31D ; Thu, 20 May 1999 14:30:08 -0400
X-Lotus-FromDomain: NOTES@ALPHABETA
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 15:32:03 -0400
Subject: Obvious typo in RFC2459
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Someone may have picked up on this already, I haven't been following the mailing
list for too long.

4.2.1.11 Name Constraints para 5 ends with the text
..... For example, ".xyz.com" indicates all the Internet mail addresses in the
domain "xyz.com", but Internet mail addresses on the host "xyz.com".

?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13971 for ietf-pkix-bks; Thu, 20 May 1999 11:31:25 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13967 for <[e-mail]>; Thu, 20 May 1999 11:31:24 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA15511; Thu, 20 May 1999 20:31:08 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 20 May 1999 20:31:08 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id UAA24317; Thu, 20 May 1999 20:31:07 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id UAA21450; Thu, 20 May 1999 20:31:07 +0200
Date: Thu, 20 May 1999 20:31:07 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 
> > I personally don't see why a timestamping standard cares what data is
> > allowed to be timestamped. As far as I know, a notary not only vouches
> > for the contents, but also vouches for the identity of the parties that
> > are signing the document (to be notarized). So, just allowing data to be
> > timestamped does not promote it to a notary service, I think.
> > 
> No, but as soon as the TSA is allowed to examine the data and must change
> it's actions based on that data, it is doing more than just providing a
> "proof-of-existence".
Doesn't the current text already asks for that; what means validation
of a hash function? 

> 
> > >Packaging things in two levels adds complexity, but does not
> > >help any practical situation I may foresee. If simplifity
> > >is an objective, a single layer is simpler.
> > 
> > I agree simplicity should be a goal. The two layer SignedData is
> > somewhat complex, but there are other ways of separating the transient
> > data (status, nonce) from the long-lived timestamp token.
> > 
> How can we do this (separate transient data from long-lived data) and still
> maintain simplicity and security?
Agree, seems difficult with ONE single signature. 

The status is NOT a transient element here. The nonce is such an element,
but you do not need it.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13756 for ietf-pkix-bks; Thu, 20 May 1999 11:22:35 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13752 for <[e-mail]>; Thu, 20 May 1999 11:22:34 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA15087; Thu, 20 May 1999 20:22:46 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 20 May 1999 20:22:46 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id UAA24046; Thu, 20 May 1999 20:22:45 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id UAA21440; Thu, 20 May 1999 20:22:45 +0200
Date: Thu, 20 May 1999 20:22:45 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> If the Extended Key Usage Extension was not critical two things may happen.
> Some clients may not check for it and therefore allow any entity to act as a
> TSA.  Also, clients may ignore the extension and accept the signature as any
> other signature.  However, it is not just a signature, it is meant to
> provide certain assurances.  The semantics of this signature are very
> important and I don't want those semantics to be lost.
> 
Right.

A client may be configured to trust all tsa certificates issued by
some trustworthy CA. Since the CA can also certify other entities,
a clear distinction is necessary. 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13650 for ietf-pkix-bks; Thu, 20 May 1999 11:15:08 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13646 for <[e-mail]>; Thu, 20 May 1999 11:15:06 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA14663; Thu, 20 May 1999 20:15:05 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 20 May 1999 20:15:04 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id UAA23683; Thu, 20 May 1999 20:15:04 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id UAA21437; Thu, 20 May 1999 20:15:03 +0200
Date: Thu, 20 May 1999 20:15:03 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 
> >         Robert.
> 
> How about "splitting the difference" and sending back a signed error
> when possible. If that is not feasible, then an unsigned error would be
> sent back. I agree with Denis that it's better to get something back
> than nothing.
> 
> Otherwise, users may get very confused by the lack of response.
> 
>                                     Rick
> 
I agree, BUT you do not necessarily need a special data element
to carry that information.

First, the ACTUAL protocol, there is NO provision at all to
use any lower layer error signaling . In case of an inability of
signing, the TSA does not try to use any mecanism (sending an http
error, or whetever) to signal that error. the ONLY means for
a requestor is to wait, to retry, and to give up.

Or, a response from the tsa front end http server telling 403,
500 or whatever can by NO means interpreted as a possible signal
of a REAL problem. A TSA based service cannot react with an
http error, the current abstract protocol simply indicates that
there is no way that a client can obtain information to stop retrying.

It seems not unwise to provide such a means in the ABSTRACT layer.
One can say thar for example the tsa would create a specific
lower layer error code.  This does NOT mean that a client
should believe unconditionally that this is true.

A reason to have an optional unsigned response like in LAAP
is to avoid to define for each lower layer transport the
mapping to some error message. In some transport layers this
might even be a little bit difficult. 

The proposition to have some sequence or choice with some status
code around the token, is one way of doing this WITHOUT a need
to map this to lower services. 

In fact having a SEQUENCE does
not make sense to me. As soon as there is a signed response,
whatever status needs to be included in the signature. The
signature validation needs to follow pkcs7 rules, thus you
either make a copy of the status that is already inide the data
or in an attribute. 

The usage for catastrophic errors has nothing to do
with the usage of a signed response. It seems that there is
a confusion because one used the same data structure. 

At least: If the status is granted, there is no need to indicate
this at all in a PKIStatus field (unless you want to add a
free text containing some publicity) ==> PKIStatus optional. 
If it is missing, the status is granted. 

It is a matter of taste to use an authenticated attribute or not.
You can put all and everything into an authenticated attribute. The
DATA provided by a time stamping authority are not arbitrarily long
data where several signers want to add different attributes, or
where you want to communicate the signatures without the data.

There is one intermediate solution that might be worth to be
considered: The data portion of the signed data would just be
the request, and all other information would be in some
authenticated attribute. In this case the TSA can even correctly
signal an error condition that the request had an invalid
encoding for exemple. 




   






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13493 for ietf-pkix-bks; Thu, 20 May 1999 11:02:49 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13489 for <[e-mail]>; Thu, 20 May 1999 11:02:49 -0700 (PDT)
Received: from mcg.org.br (pm02-08.sac.verio.net [209.162.64.27]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id LAA22438; Thu, 20 May 1999 11:02:55 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 10:54:10 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate life-cycle costs.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Jueneman wrote:

> Ed, it took me about three readings to get it -- I had to keep scrolling
> back to see what I had written, and the "s" (current time, as you
> interpreted it), was a simple typo when I was manually formatting the line.
>
> Nonetheless, I hereby award you the pony award -- three bags full. :-)

Bob:

I also award you the "pony award" for a good question that allowed me
to reply on a focused direction. This is much easier than having to do both,
question and reply ;-) Besides, I have no qualms about using "s" for time,
after all, it's just a name ;-)


> Off list, Hans Neilson and I were discussing the Novell Security
> Attributes that I had proposed as a partial solution to some of the
> issues that had been raised with the Qualified Certificates, namely
> how to identify the fact that a user was an anonymous user, that the
> CA was a licensed or otherwise qualified CA, reliance limits, etc.
>
> One of the valid concerns he expressed was the cost of "overloading"
> the certificate with such additional information.  Of course I responded
> that it wasn't overloading if that was the information you had to have, and
> if it was less costly to include it once, rather than make someone fetch it
> from somewhere else very time it was needed. In addition, I opined
> that the attributes that were contained were approximately as stable as
> the key itself, and/or the identity of the end-entity itself.

Until your last phrase, I note that what you and Hans were diverging about
is a simple instance of the paradox between accuracy and reliability for
intersubjective and objective systems. An example of it was given in my
reply to your question #1 in my former e-mail, which I believe fits and
explains the problem in your discussion above -- a compromise solution
is needed since both accuracy and reliability, though fully independent,
cannot be independently optimized in intersubjectrive and objective
systems. The mathematical reasons for this would not fit the margins of
this e-mail but I can send a draft note to whoever is interested.

But your last phrase is, you may realize, contradicted by the equation I
presented for the certificate lifetime as the inverse of the sum of the
inverses of the atttribute lifetimes contained in it -- because the attributes
as a whole will very much lower the certificate lifetime even if  each
attribute and the key have the *same* lifetime.

> With your work I think we can now model the impact of adding such
> additional parameters, and their influence on the decay of trust.

Yes, where I note that trust is fully intersubjective here, as "that which I
rely upon for my decisions" -- it is not objective trust, which is simply
an authorization or, as oftentimes expressed, a license that is being
extended.  So, in our case, the authorization is there as the certificate
itself -- but, do I trust it, do I rely on it for my decisions? To what
extent of reliance? This is the question being addressed here -- the
decay of trust for that certificate as measured by the extent of
reliance. For context on this, please see the reference
http://www.mcg.org.br/trustdef.htm

> But it would be useful to close the loop and model the cost of
> certificate reissuance and redistribution in this entire process,
> and then to boil it down to something that even the "suits"
> can understand.
>
> At first glance, it seems desirable to issue certificates that are
> relatively long lived, especially if reissuance is costly or a real
> nuisance, requiring personal appearance in front of a notary, etc.
>
> But the validity period of a certificate primarily affects one thing,
> and one thing only -- the length of time that the CA is responsible
> for issuing CRLs or otherwise accounting for a change in status of
> the certificate.

Yes -- to the CA. But not necessarily to the relying-party, nor the
r-p application that reads and processes the certificate. In fact,
today, certificates are used without much concern to CRLs -- even
by the browsers that are supposed to query them. So, in practice,
the validity period of the certificate is a welcome liability cap to the
CA and perhaps a nuisance to the user that will need to handle
multiple annoying messages that he cannot shut off for any period
of time, just to continue to use that certificate which he justifiedly
trusts.

So, the question arises -- could the r-p calculate the validy of a
certificate, a posteriori? This was positively answered in my reply
to your question #2 -- and, quantitatively.

Thus, certificate issuance in PKIX/X.509 model is CA-centric but
certificate validity does not have to be CA-centric even in the
PKIX/X.509 model -- though, I stress, it is today. But only on
paper ;-)


> So there are two competing trends -- as certificate validity periods
> increase, the cost of issuance decreases, but the cost of
> reissuance due to a change in the attributes tends to increase.
> In addition, as the validity time increases, the cost of carrying
> a revoked certificate in a CRL also increases.

The two competing trends only exist if both certificate issuance and
certificate validity are CA-centric. If one of them is not, the "loop"
is at least partially broken -- for example, if certificate validity is not
CA-centric (as above discussed) then the r-p can apply different decay
times for each attribute and calculate an instantaneous confidence limit
for each different  use of the certificate, at different times. Certificate
validity is then IMO properly centered on the r-p --  who is
the party at risk *and* knows what the certificate is being used for.
This allows the r-p to cope with  revoked but partially valid certificates
("false positives" as mentioned by Blakley as his concern), with
expired but unrevoked certificates (as I exemplified in time logic),
and other combinations of validity qualifiers.

Alternatively, to center it on the CA will introduce artificial conflicts
(as you describe above) and increase r-p risks.

> My expectation is that these competing trends are likely to
> add together, producing a classic bathtub curve that may be quite
> shallow, indicating that the total cost is relatively insensitive
> to certificate validity periods.

Agreed, but the trends can also negatively reinforce each other
so that the total cost does not decrease much as you change validity
periods in PKIX. Longer-validity certificates can and will probably
cost more than short-validity certificates because the liability cap is
higher for the CA -- the question is how much more?  And, this is
a commercially-defined question -- no longer in the r-p hands.

> If the total cost to the user only varies by say 5% from a one month
> to a three year validity period, then it probably doesn't matter.

It may vary only 0.05% -- but the real question is: how much
is being charged for a three-year validity certificate? Does it
matter if the same value is divided in 36 installments?  One way
(by dividing the payments for one certificate into 36) or another
(by dividing the certificates into 36, with one payment for each
one)?

> However, the distribution of the various pieces of the cost
> equation may differ dramatically between the various components,
> and one segment of the industry might find their particular ox
> being gored, and so it might matter a lot to the individual
> players.

Especially to r-ps.

> Care to go for a second pony?  Three gets you the brass ring,
> to switch metaphors.

As above, but the gold plate should go to you .. as you made it
to here ;-)

Thanks for the good comments and for sharing the blame of long
postings.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13446 for ietf-pkix-bks; Thu, 20 May 1999 10:59:53 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13442 for <[e-mail]>; Thu, 20 May 1999 10:59:52 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id KAA08393; Thu, 20 May 1999 10:58:42 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id KAA13080; Thu, 20 May 1999 10:59:34 -0700 (PDT)
Received: by localhost with Microsoft MAPI; Thu, 20 May 1999 11:06:19 -0500
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, Bob Jueneman <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Example with sub-attributes,was  Re: Attribute certificatelifetimes
Date: Thu, 20 May 1999 11:06:18 -0500
Organization: ValiCert Inc.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If one changes the axis of this argument to
the lifetime of a directory/repository entry, does 
anything change?

The reason I ask is that a certificate is actually
no longer valid in many legalistic practices models when
the "official" certificate management repository is
modified - to reflect the change in status.

A 2459 PKI is perhaps modeled as a function 
of three macro variables - the lifetime of
a cert,  the lifetime of the repository entry, and the 
lifetime of the CRL/OCSP-Responses (if used).

On Wednesday, May 19, 1999 8:50 PM, Ed Gerck [SMTP:[e-mail]] wrote:
> 
> 
> Bob Jueneman wrote:
> 
> > Ed,
> >
> > There must be a pony in here somewhere, but other than an interesting
> > mathematical exercise, I'm not sure that I can put my finger on it yet.
> 
> Bob:
> 
> Well, perhaps this deserves more than just a "pony award" ;-)
> 
> Because, in my view, it answers the fundamental question that must
> be addressed *before* a certificate is ever issued: "What is to be
> this certificate's stated lifetime so that its data is expectedly
> valid during its lifetime?". 
> 
> Additionally, the following list may be helpful to guide your finger ;-)
> and our discussion, where the quotes refers to text in my original 
> posting unless otherwise noted:
> 
> 
> 1. The equation
> 
> 1/T = 1/T1 + 1/T2 + ... + 1/TN               (1)
> 
> is simple enough to be quickly used. It allows one to use engineering
> where before one only had guess-work and a bad formula -- outcounting 
> Blackley's formula, which deals with a particular case but can be cast
> in the same form as Eq. (1).
> 
> 2. "Since any certificate has attributes (e.g., the date it was issued,
> the company name it was issued to, etc.) which may be invalid sooner 
> (e.g., Y2K, misspelling, CA error) than the originally intended key 
> lifetime, this discussion may be important to provide an upper bound 
> for key lifetimes for any type of certificates."
> 
> 3. "Certificate lifetime with M multiple attributes can be modeled 
> in average behavior and without imposing attribute independence, 
> by using an exponential decay formula for each effective attribute".
> 
> 4. "The number N of effective attributes can be larger than the number
> M of original multiple attributes in the certificate, which allows the 
> representation of sub-attributes that are too significant to be ignored."
> 
> 5. Attribute certification is no longer a murky situation as described
> by David, which lifetime behavior cannot be proved or disproved for 
> each calculation. An exponential decay rate can be generally assumed 
> for each attribute, which can be made as accurate as desired by 
> dividing each attribute into sub-attributes and assigning an 
> additional decay rate for each one. This allows even square-function
> and abruptly fall offs to be considered in the same certificate.
> 
> 6. Equation (1) can handle delayed attributes, piecewise exponential
> decays, square-function atrributes and any non-increasing function of
> attribute validity with time, for any number of attributes.
> 
> 7. It is irrelevant whether the mean attribute lifetime is significantly
> shorter than the mean PK lifetime or not, as David questioned.
> 
> 8. The distribution of attribute lifetimes is correctly assumed to 
> be discrete in Eq. (1), answering a concern by David.
> 
> 9. It is irrelevant whether the attributes within a single certificate 
> are mutually independent or not in order to calculate certificate 
> lifetime, answering a concern by David.
> 
> 10. It is irrelevant whether the attributes within a single certificate
> are all jointly independent or not in order to calculate certificate 
> lifetime, answering a concern by David.
> 
> 11. It rolls trippingly off the tongue: "The inverse of the certificate 
> lifetime is equal to the sum of the inverses of each effective attribute
> lifetime". (a previous good-humored requirement by David)
> 
> 12. "The lesson here is that you have to make the key lifetime VERY short 
> compared to the shortest attribute lifetime in order to get the actual 
> lifetime of an attribute certificate close to its nominal lifetime", as 
> written by Bob Blackley when showing why his formula could be useful. The
> same result applies to Eq. (1), of course.
> 
> 13. "Certificate lifetime is always shorter than the shortest lifetime".
> 
> 14. "Key lifetime should be at most 1/3 the shortest attribute's lifetime."
> 
> 15. "Two attributes with lifetime equal to the key will reduce
> certificate lifetime to only 30% of the key lifetime."
> 
> 16. "Three attributes that each have a lifetime equal to twice the key 
> lifetime will nonetheless reduce certificate lifetime to 40% of the key 
> lifetime." 
> 
> 17. "Long-lived certificates should have a least number of attributes".
> 
> 18. "Denies the usefulness of overloading public-key certificates with 
> data in an attempt to increase reliance"
> 
> 19. "Even for no key the least number of attributes will again result in 
> a much longer-lived certificate."
> 
> 20. It allows one to use the same formalism both for a priori certificate
> lifetime calculations as in Eq. (1), as well as for a posteriori 
> certificate lifetime calculations -- also called certificate validation.
> This will be discussed elsewhere but is mentioned in my answer to your 
> question (2).
> 
> 21. Because it is mathematically sound in a very general context, so
> that one can rely on it, forget the math and concentrate on using it ;-)
> 
> 
> > What I'm groping for is something that would tie the expected
> > certificate lifetime back to a useful cost measure, I.e.,
> >
> > 1.  You should use individual attribute certificates rather than
> > compound attribute identity certificates if X>Y, for suitable values of
> > X and Y??
> 
> Yes and No -- and I am not being humorous, it is a fundamental limitation
> (though one that I did not yet address here). You need to compromise:
> 
> - An individual attribute certificate will be more reliable by itself -- 
> so it is a "yes" if your objective is to increase certificate lifetime 
> (see item 17 above).
> 
> - A compound attribute certificate will be more accurate by itself -- so, 
> it is a "no" if your objective is to increase certificate "strength".
> 
> >
> > 2.  If certificate retrieval costs X, the cost of incorrectly relying on
> > an revoked certificate for some transaction is Y, and the time s
> > since the certificate was last validated by CL or OCSP checking is T,
> > then you should/should not revalidate the certificate??
> 
> Well-stated. We need cost-functions and "merit figures" (as usual in 
> engineering) in order to facilitate decisions, and what you suggest
> is one that must surely face a relying-party. I will cut some corners
> below, but hopefully not too many -- I hope it still qualifies for the
> "pony award" ;-)
> 
> Let me change your "T" for D -- to avoid confusion with the given 
> formulas. Here, T is the certificate lifetime.
> 
> Please recall the function C(t) = exp (-t/T) given in reference [1] of
> my original posting -- the a priori certificate validity function. 
> Suppose this function is correctly weighed for its components, so that
> it can also be considered as the probability distribution function for *a 
> posteriori* certificate validity (it can be, if done as in [1], but note 
> that eq. (1) deals with a priori certificate validity). Then,
> 
> Y(s) = (1 - C(s - D)) * S , for s > D,
> 
> where Y and s are as you defined and S is the value at stake.  To simplify the equation, I will forget the insurance cost, the maximum
> risk covered by your insurance policy, the number of times you may
> rely on it per month on average, capital costs and non-financial costs 
> for  failure (such as good-will), for the moment. Then, I define a
> merit-function Q as:
> 
> Q(s) = (X - Y(s))/X
> 
> and state my rule:
> 
> "If Q > 0 then proceed, otherwise validate certificate".
> 
> Note that Y(0) = 0 and Q(0) = 1 -- otherwise, Q(s) < 1 for any s.
> 
> >
> > Any thoughts as to where this can take us?
> 
> Towards a mathematical theory of certification, for which much
> help and discussions will be, undoubtably, necessary. You may
> recall some of the origins of this model of validation, when 
> we both discussed the decay of trust after certificate issuance
> with time, in list and private discussions. The a priori decay
> of trust with time is what makes the attribute validity decay
> for the a priori determination of its lifetime. This also shows
> that a certificate has many unseen attributes, if you recall
> the list I used to discuss the topics, which will nonetheless
> reduce its lifetime. One example, of several discussed in
> http://www.mcg.org.br/cert.htm , is the validity of the CA 
> signing certificate -- which is not mentioned in the subscriber certificate as an attribute but can render it invalid if the CA
> cert expires or is revoked before the subscriber's certificate
> lifetime expires.
> 
> The end objectives are to qualify, quantify and increase 
> certificate accuracy and reliance, as well as to provide support
> for all modes of certification [http://www.mcg.org.br/cie.htm]
> 
> Since this focused list has a different task, my objective here
> was primarily to show that Blackley's formula is not an YARRFS
> (Yet Another Random Result From Statistics) as David Kemp 
> correctly IMO questioned, but rooted in a more general framework
> which validates the intuition behind it and offers some good
> tips -- my list of "finger tip" points 1-21 above.
> 
> Thus, I expect that this can indeed be useful for the PKIX effort
> and for all kinds of certificates, in a simple equation (1) that 
> may accomodate all needs -- so far ;-)
> 
> Comments?
> 
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                 [e-mail]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA13022 for ietf-pkix-bks; Thu, 20 May 1999 10:26:15 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13018 for <[e-mail]>; Thu, 20 May 1999 10:26:13 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATMKG>; Thu, 20 May 1999 13:28:08 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8F4@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 13:28:06 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

> > I personally don't see why a timestamping standard cares 
> what data is
> > allowed to be timestamped. As far as I know, a notary not 
> only vouches
> > for the contents, but also vouches for the identity of the 
> parties that
> > are signing the document (to be notarized). So, just 
> allowing data to be
> > timestamped does not promote it to a notary service, I think.
> > 
> No, but as soon as the TSA is allowed to examine the data and 
> must change
> it's actions based on that data, it is doing more than just 
> providing a
> "proof-of-existence".

I don't agree that the TSA has to examine the "data" to determine if it
dealing with raw data or a hash. One simple way to do this would be to
use your existing structure for MessageImprint (I renamed the subfields
to make it more understandable):

***
MessageImprint ::= SEQUENCE {
	imprintAlgorithm	AlgorithmIdentifier,
	imprintOfMessage	OCTET STRING}

Let us say we designate an OID (let's say XYZ)that represents the
"identity transform" meaning that it does nothing to the input data.
Then your TSA Server code would do the following:

IF (MessageImprint.imprintAlgorithm == XYZ) 
	IF (length of imprintOfMessage > MAXSIZE)
		return FAILURE;
	
ELSEIF ((MessageImprint.imprintAlgorithm == SHA-1)
	IF (length of imprintOfMessage > 20)
		return FAILURE;	
... (for other acceptable imprint algorithms)

USE imprintOfMessage to generate TST
***

Thus, as you can see, when "data" comes in instead of a "hash" the TSA
does nothing substantially different in the realm of "inspecting the
data". What am I missing here?

> 
> > >Packaging things in two levels adds complexity, but does not
> > >help any practical situation I may foresee. If simplifity
> > >is an objective, a single layer is simpler.
> > 
> > I agree simplicity should be a goal. The two layer SignedData is
> > somewhat complex, but there are other ways of separating 
> the transient
> > data (status, nonce) from the long-lived timestamp token.
> > 
> How can we do this (separate transient data from long-lived 
> data) and still
> maintain simplicity and security?

While simplicity is a goal, cleanliness of design is a more important
goal. In other words, we should not sacrifice on architectural elegance
just to make coding easier. I very strongly feel that transient data
should not be included (by design) into long-term objects. 

You ask, "How can we do this ..." - one way to do this would be as
follows:

Define TSAResponse as the response from a TSA:

TSAResponse ::= CHOICE {
	errorInfo		SignedData,  
	tokenInfo		TokenInformation}

For an error information message (of type SignedData) the eContentType
is defined as:
id-ct-TSTerrorInfo	OBJECT IDENTIFIER	 ::= {id-ct 5}

and the eContent shall be of the ASN.1 type TSTErrorInfo.

TSTErrorInfo ::= SEQUENCE {
	status 	PKIStatusInfo,
	nonce 	Integer OPTIONAL}

TokenInformation is an unsigned data structure as follows.

TokenInformation ::= SEQUENCE {
	status	PKIStatusInfo,
	nonce 	Integer OPTIONAL,
	token 	SignedData }

NOTE: When a valid TST is being returned, the status and nonce need not
be signed. The only attack I can envision is possible denial-of-service
but that can't be prevented anyway. 
 	
For a token (SignedData) structure the eContentType would be as in the
I-D, namely id-ct-TSTInfo, and the eContent shall have the ASN.1 type,
TSTInfo.

TSTInfo would be the same as in the I-D except that the nonce and status
fields would be removed. 

The ASN.1 above might need some work, but this is just to give you a
flavor for how the transient info can be separated from the long-term
info without multiple signatures. 

- Sarbari


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12938 for ietf-pkix-bks; Thu, 20 May 1999 10:14:36 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA12934 for <[e-mail]>; Thu, 20 May 1999 10:14:35 -0700 (PDT)
Received: 	id NAA10987; Thu, 20 May 1999 13:10:20 -0400
Received: by gateway id <LBQBDQC8>; Thu, 20 May 1999 13:12:46 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Rick Wessman'" <[e-mail]>
Cc: Sarbari Gupta <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 13:12:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Rick;

> ----------
> From: 	Rick Wessman[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 12:16 PM
> To: 	Robert Zuccherato
> Cc: 	Sarbari Gupta; 'Denis Pinkas'; [e-mail]
> Subject: 	Re: Comments on draft-ietf-pkix-time-stamp-01.txt
> 
> How about "splitting the difference" and sending back a signed error
> when possible. If that is not feasible, then an unsigned error would be
> sent back. I agree with Denis that it's better to get something back
> than nothing.
> 
This would still allow TSAs to return unsigned error messages and everyone
would still have to deal with them.  Thus, the potential security problem
remains.  If I get one of these messages how do I know that it actually came
from the TSA?  

> Otherwise, users may get very confused by the lack of response.
> 
Users will still have to handle the case where no response is returned since
sometimes devices do lose their connectivity.  At least when I don't receive
any response, I know that a problem exists.  If I get an unsigned error
message, somebody may be impersonating the TSA, or I might have formatted my
request wrong.

	Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12922 for ietf-pkix-bks; Thu, 20 May 1999 10:13:18 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12918 for <[e-mail]>; Thu, 20 May 1999 10:13:15 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA12206; Thu, 20 May 1999 19:13:12 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Thu, 20 May 1999 19:13:12 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA22709; Thu, 20 May 1999 19:13:11 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA21424; Thu, 20 May 1999 19:13:11 +0200
Date: Thu, 20 May 1999 19:13:11 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> There is certainly no advantage to including the nonce as an authenticated
> attribute.  Doing so would add complexity and the nonce would still have to
> be included with the token in order to validate the signature.
> 
Right. If one wants to remove the nonce, then you would need at least
two signatures. If one has a messageImprint, and the requestor
does not include a nonce, the time stamp token still indicates the
existence of the data, i.e. the hash at that date. 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12798 for ietf-pkix-bks; Thu, 20 May 1999 10:04:31 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA12794 for <[e-mail]>; Thu, 20 May 1999 10:04:30 -0700 (PDT)
Received: 	id NAA07279; Thu, 20 May 1999 13:02:08 -0400
Received: by gateway id <LBQBDP07>; Thu, 20 May 1999 13:04:34 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Juan G. de la Vega'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 13:04:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juan;

> ----------
> From: 	Juan G. de la Vega[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 11:18 AM
> To: 	Robert Zuccherato; [e-mail]
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> Robert;
> 
> Please let me be more specific (comments below):
> 
> >Juan;
> >
> >Again, my comments are below.
> >
> >> ----------
> >> From: Juan G. de la Vega[SMTP:[e-mail]]
> >> Sent: Thursday, May 20, 1999 3:43 AM
> >> To: Sarbari Gupta; [e-mail]
> >> Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> >>
> >> Please let me add some further comments upon yours,
> >>
> >> >4) The current definition of the TSTInfo data structure seems to be
> >> >trying to kill two birds with a single stone. It seems that the TSA
> >> >response can potentially contain:
> >> > - the signed timestamp token
> >> > - other information related to the response such as status,
> >> >nonce, etc.
> >> >As such, it would seem logical to use a nested SignedData structure to
> >> >signify the response from the TSA. The first level SignedData would
> >> >contain the status, nonce, and (when status = SUCCESS) the timestamp
> >> >token. The timestamp token itself would use another SignedData
> structure
> >> >to hold the relevant data of the timestamp token. The actual timestamp
> >> >token is for wider distribution - I don't think it is a good design
> >> >approach to overload it with transient information such as a nonce.
> >> >
> >> As a matter of fact, it pleases me that someone addresses this issue.
> The
> >> same structure is being used to support every response from the TSA
> >> regardless whether it is a valid time stamp token (with or without
> >> transient
> >> info) or some other semantic token (i.e. "signed time", error
> report...).
> >> This rises problems not addressed in this draft, namely:
> >>
> >>     -since tstTime is mandatory, and messageImprint must match the
> similar
> >> field in the request, problems not related to the time source
> >> (non-existing
> >> TDAs) lead to ambiguous tokens; the time is correct, the messageImprint
> is
> >> there, despite the status field states that TDAs were not available,
> >> bearing
> >> in mind that the TST is signed by the TSA anyway, does not this prove
> that
> >> a
> >> given document existed at a given point in time (Time Stamping!)
> >> regardless
> >> other circumstances (charging for the service is a good example)?
> >>
> >I don't see this as a problem.  If the TDAs are not available, the TSA
> can
> >still produce a structure that has the time and message imprint included.
> >The status field would correctly indicate that an error occurred.  If a
> >token that does not contain all of the TDAs is acceptable to the
> >application, then it can use it, otherwise it doesn't.
> >
> 
> I think I do not get you right. Are you advocating that a structure with a
> PKIStatus set to error as  valid and usable?. If this is so, I disagree
> with
> you. I regard that as an error and I would not pay for that, but what I am
> saying is that it is still a "proof" and a TSA cannot charge for that
> "proof". If you regard the scenario depicted above as acceptable (which
> seems reasonable) I recommend to set the PKIStatus to "granted with mods"
> instead of  erroneous and I would remove the sentence "A valid time stamp
> token will always have value 0 (granted)..." from the I-D.
> 
I am not saying that an error message is a valid token and I am not saying
that it is necessarily usable.  I am just saying that if a TSA wants to
include the valid time and message imprint in all error messages (that it is
feasible for it to do) and this service is explicitly stated in its policy,
I have no problem with that.  In such situations the error message may have
some value as a method to prove the information it contains (but it is still
not a valid time stamp token).  Whether or not you are willing to pay for
it, or any TSA is willing to charge for such a service is beyond the scope
of this document.  

	Robert.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12672 for ietf-pkix-bks; Thu, 20 May 1999 09:54:33 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA12659 for <[e-mail]>; Thu, 20 May 1999 09:54:30 -0700 (PDT)
Received: 	id MAA01904; Thu, 20 May 1999 12:52:12 -0400
Received: by gateway id <LBQBDP7M>; Thu, 20 May 1999 12:54:38 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>, "'Sarbari Gupta'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, "'Stephen Farrell'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)
Date: Thu, 20 May 1999 12:54:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Okay, you do get that advantage.  But at the cost of increased complexity.
I don't see the trade off as being worth it.

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 10:50 AM
> To: 	'Robert Zuccherato'; Sarbari Gupta; [e-mail];
> '[e-mail]'
> Cc: 	'Denis Pinkas'; 'Peter Sylvester'; 'Stephen Farrell'
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> (Data+Status)
> 
> Robert,
> 
> The advantage is that you do not bundle up (just because it is
> convenient at the programming level) transient information into a long
> term entity such as the TST. When that TST is sent out to (let's say) a
> 1000 recipients, what utility is served these 1000 individuals by the
> nonce and the status fields?
> 
> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================
> 
> -----Original Message-----
> From: Robert Zuccherato [mailto:[e-mail]]
> Sent: Thursday, May 20, 1999 10:25 AM
> To: 'Sarbari Gupta'; [e-mail]; '[e-mail]'
> Cc: 'Denis Pinkas'; 'Peter Sylvester'; 'Stephen Farrell'
> Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)
> 
> 
> Michael;
> 
> As I stated in my previous message, I really don't see the advantage of
> having a nested structure.  You suggest here that the outer layer
> (containing the error information) be optionally unsigned and rely on
> other
> mechanisms to provide security.  I am extremely uncomfortable with this.
> If
> we are developing security standards we should make them secure, and not
> assume that people will do the right thing at the transport level.  We
> have
> never made such an assumption, and doing so would be a major change of
> focus
> for this document.
> 
> 	Robert.
> 
> > ----------
> > From: 	Michael Zolotarev[SMTP:[e-mail]]
> > Reply To: 	[e-mail]
> > Sent: 	Wednesday, May 19, 1999 9:19 PM
> > To: 	'Sarbari Gupta'; [e-mail]
> > Cc: 	'Robert Zuccherato'; 'Denis Pinkas'; 'Peter Sylvester';
> 'Stephen
> > Farrell'
> > Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> > (Data+Status)
> > 
> > Sarbari wrote:
> > ---------------------------------------------
> > 4) The current definition of the TSTInfo data structure seems to be
> > trying to kill two birds with a single stone. It seems that the TSA
> > response can potentially contain:
> > 	- the signed timestamp token
> > 	- other information related to the response such as status,
> > nonce, etc.
> > As such, it would seem logical to use a nested SignedData structure to
> > signify the response from the TSA. The first level SignedData would
> > contain the status, nonce, and (when status = SUCCESS) the timestamp
> > token. The timestamp token itself would use another SignedData
> structure
> > to hold the relevant data of the timestamp token. The actual timestamp
> > token is for wider distribution - I don't think it is a good design
> > approach to overload it with transient information such as a nonce.
> > 
> > In fact, to be a purist, a failed timestamp request is not generating
> a
> > timestamp token, so the error message and the nonce should be signed
> by
> > a key that is different from the key used to sign a good timestamp
> > token. This is further reason to support nested SignedData structures
> > each of which can be signed by a different key.
> > -------------------------------------------------
> > 
> > This is yet another voice in support of the idea we have been tossing
> > around
> > for a few days (in both private and public mails). The reasons for
> > splitting
> > the message into data and status were the same as you have come up
> with.
> > In fact, a similar approach has been proposed by the AC draft.
> > 
> > For your reference:
> > 
> > > The whole structure turns into the following:
> > >   TSResponseMessage ::= SEQUENCE {
> > >        statusInfo   PKIStatusInfo -- from [CMP]
> > >        tsoken       SignedData  OPTIONAL -- TSTInfo with NO
> statusInfo
> > inside there
> > >   }
> > 
> > and another one
> > 
> > > >  TSResponseMessage ::= CHOICE {
> > > >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo
> inside
> > there
> > > >       errorInfo [1]  ErrorMsgContent -- from [CMP]
> > > >  }
> > 
> > 
> > Sarbari actually went further, suggesting an extra signed layer around
> the
> > whole lot. Well, this may answer the argument that sending a
> non-signed
> > status is a bad thing. Making it optional (leave it to the transport?,
> > using
> > ContentType? )...
> > 
> > Do you (the Group) think that the subject MAY deserve a broader
> > discussion?
> > 
> > MichaelZ
> > 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12259 for ietf-pkix-bks; Thu, 20 May 1999 09:14:54 -0700 (PDT)
Received: from inet-user-gw-1.us.oracle.com (inet-user-gw-1.us.oracle.com [192.86.155.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12255 for <[e-mail]>; Thu, 20 May 1999 09:14:53 -0700 (PDT)
Received: from usmail04 (usmail04.us.oracle.com [144.25.88.96]) by inet-user-gw-1.us.oracle.com (8.8.5/8.8.5) with SMTP id JAA25088; Thu, 20 May 1999 09:12:18 -0700 (PDT)
Received:  from us.oracle.com by usmail04 with ESMTP (SMI-8.6/37.9) id JAA29942; Thu, 20 May 1999 09:15:03 -0700
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 12:16:20 -0400
From: Rick Wessman <[e-mail]>
Organization: Oracle Corporation
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: Sarbari Gupta <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert Zuccherato wrote:
> 
> Denis;
> 
> You wrote:
> 
> > ----------
> > From:         Denis Pinkas[SMTP:[e-mail]]
> > Sent:         Thursday, May 20, 1999 7:09 AM
> > To:   Sarbari Gupta
> > Cc:   [e-mail]
> > Subject:      Re: Comments on draft-ietf-pkix-time-stamp-01.txt
> >
> > I am advocating instead *unsigned errors* as other protocols are doing.
> > This
> > means that the status error code has to be separated from the signed
> > token.
> > I have debated this point with the other editors which are favoring to
> > sign
> > everything and thus why this is included in the current draft. There are
> > many arguments for *not* signing errors, including performances and the no
> > response case when the TSA is unable to sign. I prefer to get back an
> > unsigned error code rather than no response (as mandated today) in such a
> > situation.
> >
> The only reason we use certificates in the first place is because we don't
> trust the integrity of our networks and other system components.  That being
> the case, why would we trust an unsigned response?  It's inconsistent.  I
> want to know that every response I get from the TSA REALLY came from the
> TSA.
> 
>         Robert.

How about "splitting the difference" and sending back a signed error
when possible. If that is not feasible, then an unsigned error would be
sent back. I agree with Denis that it's better to get something back
than nothing.

Otherwise, users may get very confused by the lack of response.

                                    Rick


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12195 for ietf-pkix-bks; Thu, 20 May 1999 09:10:47 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA12190 for <[e-mail]>; Thu, 20 May 1999 09:10:43 -0700 (PDT)
Received: 	id MAA16089; Thu, 20 May 1999 12:06:16 -0400
Received: by gateway id <LBQBDPRX>; Thu, 20 May 1999 12:08:40 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Sarbari Gupta'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 12:08:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari;

I would not be opposed to changing the model and allowing the data to be
included within the time stamp token if there was a clear need for it.
However, I don't see that need.  It may provide for more elegant storage of
the token and message in some special circumstances, but it also makes the
server end more complex since it would then have to be concerned about the
length of messages it time stamps.  Note that appendix A does provide a
method to store the data and token together.

If the Extended Key Usage Extension was not critical two things may happen.
Some clients may not check for it and therefore allow any entity to act as a
TSA.  Also, clients may ignore the extension and accept the signature as any
other signature.  However, it is not just a signature, it is meant to
provide certain assurances.  The semantics of this signature are very
important and I don't want those semantics to be lost.

No, I wouldn't include nonces and status information within a certificate.
But this isn't a certificate.

	Robert.

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 10:44 AM
> To: 	'Robert Zuccherato'; [e-mail]
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> Robert:
> 
> You write:
> 
> This issue has actually been discussed quite a bit both on the list and
> at
> PKIX meetings.  A Time Stamp Authority, as we have defined it, does not
> examine or verify the data being time stamped in any way.  If it did so,
> it
> would be doing more than just providing a "proof-of-existence" for the
> data
> at a particular point in time and would become more like a "notary"
> service.
> (Although the term "notary" is not a good term to use.  Everyone has a
> different definition what an electronic notary should do.)  We also
> decided
> that it was desirable to only have a message imprint within the time
> stamp
> token and not to include the entire data.  In most circumstances this is
> what is desired, and it would prevent people from forcing the TSA to
> produce
> HUGE time stamp tokens.  If we allowed tokens to be produced using the
> actual data instead of the message imprint, the TSA would, in most
> cases,
> need to examine the data to determine, for example, if the data is too
> big
> for it to support.  As I stated, this is not allowed in this model. 
>  
> ==> I did not attend the PKIX meetings that you are referring to. If the
> majority of folks feel that data SHOULD NOT be timestamped, I am willing
> to accept that. 
> 
> ==> However, your argument sounds somewhat circular. First, you create a
> "model" where data cannot be inspected, then you come from the other
> direction and say that data cannot be allowed on the incoming request
> since the "model" does not allow it. Any "models" that are created
> should be based on business/usage requirements. First, we need to
> evaluate whether it makes sense for a "business model" where TSTs
> contain data (of maximum length to be determined by the TSA) instead of
> hashes. If so, I would argue that your "model" needs to be expanded to
> accommodate the "business model".
> 
> ==> I agree that allowing data to be fed in to the TSA implies that the
> TSA has to (at the very least) inspect the data length. I don't
> understand why this is such a big problem - doesn't the TSA inspect the
> hash OID today? Why does inspecting the data length negate the "just
> providing a "proof-of-existence" for the data" maxim?    
> 
> ==> You also write:
> Why don't we allow the actual data in the request, but just a message
> imprint in the token?  Because then the TSA would have to examine the
> request to determine if it contains the actual data (which then must be
> hashed) or a message imprint (which doesn't).  Thus, we have the message
> imprint in both the request and response.
> 
> ==> I am not advocating that you support a mode where data is sent in
> but the TST contains the imprint. I am proposing that there are business
> cases where the TST itself contains small amounts of data (of length TBD
> by TSA).
> 
> 
> ==> You also write:
> No, this isn't too restrictive.  Client's must know what entities are
> entitled to act as TSAs.  Otherwise, anyone could act as a valid TSA.
> ==> Setting the Extended Key Usage extension to not be critical can also
> have the effect you desire. Clients that care will check that the TSA's
> certificate is allowed for timestamping (even though it is
> non-critical). However, all clients can verify a TST. 
> 
> ==> You also write:
> I really don't see the advantage of adding this extra layer of
> complication.
> ==> I feel that nonces and status codes SHOULD NOT appear within a TST.
> Would you include status codes (related to the cert request) and nonces
> within a certificate?
> 
> - Sarbari
> 
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================
> 
> -----Original Message-----
> From: Robert Zuccherato [mailto:[e-mail]]
> Sent: Thursday, May 20, 1999 10:06 AM
> To: [e-mail]; 'Sarbari Gupta'
> Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> 
> Sarbari;
> 
> My responses are below.
> 
> > ----------
> > From: 	Sarbari Gupta[SMTP:[e-mail]]
> > Sent: 	Wednesday, May 19, 1999 1:56 PM
> > To: 	[e-mail]
> > Subject: 	Comments on draft-ietf-pkix-time-stamp-01.txt 
> > 
> > Please accept the following comments on the document:
> > 
> > 1) Section 2.1 item 6 states that the TSA is required "to only time
> > stamp a hash representation of the datum" 
> > Why is this so? I think in certain circumstances it may be logical to
> > allow the "messageImprint" to be the message itself (e.g., for short
> > messages), such that the Time Stamp Token could contain a time-stamped
> > version of the actual data. I understand this puts the burden of
> > liability on the TSA (since it has seen the data) but this may be
> > irrelevant based on the usage model. For example, the TSA may be owned
> > and operated by a company that sends out Reminder Messages as a
> service
> > - in this case, it may be very elegant to package a short reminder
> > message within the TST itself instead of using the hash of the
> reminder
> > message. 
> > 
> > The point is that a TSA should be allowed to support a timestamping
> > service which allows actual data to be sent as part of the request.
> The
> > perceived legal liabilities and network inefficiencies should not be
> > used to restrict the timestamping standard. The standard should allow
> > all known usage models - the legal implications and network
> efficiencies
> > of specific models should be weighed by the TSA before it makes its
> > service available. 
> > 
> This issue has actually been discussed quite a bit both on the list and
> at
> PKIX meetings.  A Time Stamp Authority, as we have defined it, does not
> examine or verify the data being time stamped in any way.  If it did so,
> it
> would be doing more than just providing a "proof-of-existence" for the
> data
> at a particular point in time and would become more like a "notary"
> service.
> (Although the term "notary" is not a good term to use.  Everyone has a
> different definition what an electronic notary should do.)  We also
> decided
> that it was desirable to only have a message imprint within the time
> stamp
> token and not to include the entire data.  In most circumstances this is
> what is desired, and it would prevent people from forcing the TSA to
> produce
> HUGE time stamp tokens.  If we allowed tokens to be produced using the
> actual data instead of the message imprint, the TSA would, in most
> cases,
> need to examine the data to determine, for example, if the data is too
> big
> for it to support.  As I stated, this is not allowed in this model. 
> 
> Why don't we allow the actual data in the request, but just a message
> imprint in the token?  Because then the TSA would have to examine the
> request to determine if it contains the actual data (which then must be
> hashed) or a message imprint (which doesn't).  Thus, we have the message
> imprint in both the request and response.
> 
> > 2) Section 2.3 states "The TSA MUST sign all time stamp messages with
> a
> > key reserved specifically for that purpose" 
> > Is there anything to prevent a TSA from using multiple signing keys
> for
> > signing time stamps - selecting a specific key based on properties of
> > the incoming request. I would recommend rewording it to say "...
> > messages with one or more keys reserved ..."
> > 
> I don't think that I meant that the TSA should only have one key.  I
> will
> change the wording.
> >  
> > 3) Section 2.3 also states that the TSA's certificate MUST have the
> > extended key usage field extension set to critical. This implies that
> > only those clients that are able to parse this extension will be able
> to
> > verify the timestamp token. Isn't this too restrictive? How about
> > changing the MUST to a SHOULD or a MAY?
> > 
> No, this isn't too restrictive.  Client's must know what entities are
> entitled to act as TSAs.  Otherwise, anyone could act as a valid TSA.
> 
> > 4) The current definition of the TSTInfo data structure seems to be
> > trying to kill two birds with a single stone. It seems that the TSA
> > response can potentially contain:
> > 	- the signed timestamp token
> > 	- other information related to the response such as status,
> > nonce, etc.
> > As such, it would seem logical to use a nested SignedData structure to
> > signify the response from the TSA. The first level SignedData would
> > contain the status, nonce, and (when status = SUCCESS) the timestamp
> > token. The timestamp token itself would use another SignedData
> structure
> > to hold the relevant data of the timestamp token. The actual timestamp
> > token is for wider distribution - I don't think it is a good design
> > approach to overload it with transient information such as a nonce. 
> > 
> I really don't see the advantage of adding this extra layer of
> complication.
> (Although I will admit that I haven't read carefully the flood of emails
> that I have received from you and others the past 24 hours about this
> topic.)
> 
> > In fact, to be a purist, a failed timestamp request is not generating
> a
> > timestamp token, so the error message and the nonce should be signed
> by
> > a key that is different from the key used to sign a good timestamp
> > token. This is further reason to support nested SignedData structures
> > each of which can be signed by a different key. 
> > 
> In security requirement number 9, the word "token" should be changed to
> "message" to be consistent with Section 2.3.  An error message is a time
> stamp message, so there is no reason to use a different key for error
> messages than for tokens.  I don't see the problem here.
> 
> 	Robert.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12040 for ietf-pkix-bks; Thu, 20 May 1999 08:56:23 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA12035 for <[e-mail]>; Thu, 20 May 1999 08:56:19 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id ta004049 for <[e-mail]>; Thu, 20 May 1999 17:56:49 +0100
Message-ID: <019401bea2d8$eb9070a0$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Sarbari Gupta" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 17:53:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

>There is certainly no advantage to including the nonce as an authenticated
>attribute.  Doing so would add complexity and the nonce would still have to
>be included with the token in order to validate the signature.
>

No, there is not. That was offered as an example of "authenticating" the
nonce whithout being "part of the structure" (TSTInfo) as well as it could
be done at transport layer.

C you,

Juan.

>> ----------
>> From: Juan G. de la Vega[SMTP:[e-mail]]
>> Sent: Thursday, May 20, 1999 9:38 AM
>> To: Denis Pinkas; Sarbari Gupta
>> Cc: [e-mail]
>> Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
>>
>> Denis Pinkas wrote:
>> >
>> >Let us separate the two birds:
>> >
>> >1) as said before the status should be separated from the token,
>> >2) the nonce is there to allow a requester that has no local time to
make
>> >sure that he got a timely reponse from the TSA. So it has to be part of
>> the
>> >signed structure.
>> >
>> >
>> Denis,
>>
>>     Even admitting that no trusted local clock were available (not even
>> auth. NTP), the messageImprint field takes account of the problem of
>> responses timeliness (use a time variant parameter within the
>> messageImprint
>> field if you do not have data to stamp). If this is still considered not
>> elegant, a nonce field may be used but that doesn't mean that it has to
be
>> "part of the signed structure", I would say that in that is has to be
>> "authenticated", this could be done as proposed by Sarbari at other layer
>> or
>> even including the nonce as an authenticated attribute of the SignedData
>> construct.
>>
>> bye,
>>
>> Juan.
>>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11957 for ietf-pkix-bks; Thu, 20 May 1999 08:51:33 -0700 (PDT)
Received: from selva.dit.upm.es (selva-gw.dit.upm.es [138.4.2.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11941 for <[e-mail]>; Thu, 20 May 1999 08:50:32 -0700 (PDT)
Received: from dit.upm.es (lukas.dit.upm.es [138.4.4.197]) by selva.dit.upm.es (8.9.1a/8.9.1) with ESMTP id RAA00668; Thu, 20 May 1999 17:49:04 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 17:51:38 +0200
From: "Jose A. Manas" <[e-mail]>
Organization: Dpt. Ingenieria Telematica
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sarbari Gupta <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
References: <51BF55C30B4FD1118B4900207812701E38F8EB@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari Gupta wrote:
> 
> Jose,
> 
> You write:
> >We have identified a business case for this service where the TSA
> >does know the contents. The issue is whether it is a time-stamping
> >service any longer or you have jumped into a notary service.
> >If I were not too purist, I think there are situations
> >We have identified a business case for this service where the TSA
> >does know the contents. The issue is whether it is a time-stamping
> >service any longer or you have jumped into a notary service.
> >If I were not too purist, I think there are situations
> >where the time certificate is something more than a separate
> >appendix, for easiness of storage, transmission, verification,
> >and so on.where the time certificate is something more than a separate
> >appendix, for easiness of storage, transmission, verification,
> >and so on.
> 
> I personally don't see why a timestamping standard cares what data is
> allowed to be timestamped. As far as I know, a notary not only vouches
> for the contents, but also vouches for the identity of the parties that
> are signing the document (to be notarized). So, just allowing data to be
> timestamped does not promote it to a notary service, I think.

I am not sure what you mean.
But let me put my point of view in other words.

When a notary makes an statement on whatever,
there are three relevant pieces of information:
  - the statement itself (the message)
  - the authentity of the originator (notary's signature)
  - the time at which the notary makes the statement
    (time-stamp)

If the time-stamp is a signature attached to known data,
there is a unique act of signing, and this may be 
confortable for handling evidence in the future.

I think I mean that it makes sense that a notary 
is (also) a time-stamp authority,
and definitely he knows the contents.

Did I make my point clear?
pp
-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11921 for ietf-pkix-bks; Thu, 20 May 1999 08:48:59 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA11917 for <[e-mail]>; Thu, 20 May 1999 08:48:58 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 20 May 1999 09:48:37 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Thu, 20 May 1999 09:45:58 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Certificate life-cycle costs.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA11918
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed, it took me about three readings to get it -- I had to keep scrolling 
back to see what I had written, and the "s" (current time, as you interpreted
it), was a simple typo when I was manually formatting the line.

Nonetheless, I hereby award you the pony award -- three bags full. :-)

Although you are the only person  know with an even worse 
reputation for lengthy messages than myself (good company, though!),
I think we are on to something here that is worth the bandwidth.

Off list, Hans Neilson and I were discussing the Novell Security 
Attributes that I had proposed as a partial solution to some of the
issues that had been raised with the Qualified Certificates, namely
how to identify the fact that a user was an anonymous user, that the CA
was a licensed or otherwise qualified CA, reliance limits, etc.

One of the valid concerns he expressed was the cost of "overloading"
the certificate with such additional information.  Of course I responded that
it wasn't overloading if that was the information you had to have, and if
it was less costly to include it once, rather than make someone fetch it 
from somewhere else very time it was needed. In addition, I opined 
that the attributes that were contained were approximately as stable as 
the key itself, and/or the identity of the end-entity itself.

With your work I think we can now model the impact of adding such 
additional parameters, and their influence on the decay of trust.

But it would be useful to close the loop and model the cost of 
certificate reissuance and redistribution in this entire process,
and then to boil it down to something that even the "suits"
can understand.

At first glance, it seems desirable to issue certificates that are
relatively long lived, especially if reissuance is costly or a real
nuisance, requiring personal appearance in front of a notary, etc.

But the validity period of a certificate primarily affects one thing, and 
one thing only -- the length of time that the CA is responsible for
issuing CRLs or otherwise accounting for a change in status of the 
certificate. 

So there are two competing trends -- as certificate validity periods
increase, the cost of issuance decreases, but the cost of
reissuance due to a change in the attributes tends to increase.
In addition, as the validity time increases, the cost of carrying
a revoked certificate in a CRL also increases.

My expectation is that these competing trends are likely to
add together, producing a classic bathtub curve that may be quite 
shallow, indicating that the total cost is relatively insensitive
to certificate validity periods. If the total cost to the user 
only varies by say 5% from a one month to a three year validity 
period, then it probably doesn't matter.

However, the distribution of the various pieces of the cost
equation may differ dramatically between the various components,
and one segment of the industry might find their particular ox
being gored, and so it might matter a lot to the individual 
players.

Care to go for a second pony?  Three gets you the brass ring,
to switch metaphors.

Bob




>>> Ed Gerck <[e-mail]> 05/19/99 07:49PM >>>


Bob Jueneman wrote:

> Ed,
>
> There must be a pony in here somewhere, but other than an interesting
> mathematical exercise, I'm not sure that I can put my finger on it yet.

Bob:

Well, perhaps this deserves more than just a "pony award" ;-)

Because, in my view, it answers the fundamental question that must
be addressed *before* a certificate is ever issued: "What is to be
this certificate's stated lifetime so that its data is expectedly
valid during its lifetime?". 

Additionally, the following list may be helpful to guide your finger ;-)
and our discussion, where the quotes refers to text in my original 
posting unless otherwise noted:


1. The equation

1/T = 1/T1 + 1/T2 + ... + 1/TN               (1)

is simple enough to be quickly used. It allows one to use engineering
where before one only had guess-work and a bad formula -- outcounting 
Blackley's formula, which deals with a particular case but can be cast
in the same form as Eq. (1).

2. "Since any certificate has attributes (e.g., the date it was issued,
the company name it was issued to, etc.) which may be invalid sooner 
(e.g., Y2K, misspelling, CA error) than the originally intended key 
lifetime, this discussion may be important to provide an upper bound 
for key lifetimes for any type of certificates."

3. "Certificate lifetime with M multiple attributes can be modeled 
in average behavior and without imposing attribute independence, 
by using an exponential decay formula for each effective attribute".

4. "The number N of effective attributes can be larger than the number
M of original multiple attributes in the certificate, which allows the 
representation of sub-attributes that are too significant to be ignored."

5. Attribute certification is no longer a murky situation as described
by David, which lifetime behavior cannot be proved or disproved for 
each calculation. An exponential decay rate can be generally assumed 
for each attribute, which can be made as accurate as desired by 
dividing each attribute into sub-attributes and assigning an 
additional decay rate for each one. This allows even square-function
and abruptly fall offs to be considered in the same certificate.

6. Equation (1) can handle delayed attributes, piecewise exponential
decays, square-function atrributes and any non-increasing function of
attribute validity with time, for any number of attributes.

7. It is irrelevant whether the mean attribute lifetime is significantly
shorter than the mean PK lifetime or not, as David questioned.

8. The distribution of attribute lifetimes is correctly assumed to 
be discrete in Eq. (1), answering a concern by David.

9. It is irrelevant whether the attributes within a single certificate 
are mutually independent or not in order to calculate certificate 
lifetime, answering a concern by David.

10. It is irrelevant whether the attributes within a single certificate
are all jointly independent or not in order to calculate certificate 
lifetime, answering a concern by David.

11. It rolls trippingly off the tongue: "The inverse of the certificate 
lifetime is equal to the sum of the inverses of each effective attribute
lifetime". (a previous good-humored requirement by David)

12. "The lesson here is that you have to make the key lifetime VERY short 
compared to the shortest attribute lifetime in order to get the actual 
lifetime of an attribute certificate close to its nominal lifetime", as 
written by Bob Blackley when showing why his formula could be useful. The
same result applies to Eq. (1), of course.

13. "Certificate lifetime is always shorter than the shortest lifetime".

14. "Key lifetime should be at most 1/3 the shortest attribute's lifetime."

15. "Two attributes with lifetime equal to the key will reduce
certificate lifetime to only 30% of the key lifetime."

16. "Three attributes that each have a lifetime equal to twice the key 
lifetime will nonetheless reduce certificate lifetime to 40% of the key 
lifetime." 

17. "Long-lived certificates should have a least number of attributes".

18. "Denies the usefulness of overloading public-key certificates with 
data in an attempt to increase reliance"

19. "Even for no key the least number of attributes will again result in 
a much longer-lived certificate."

20. It allows one to use the same formalism both for a priori certificate
lifetime calculations as in Eq. (1), as well as for a posteriori 
certificate lifetime calculations -- also called certificate validation.
This will be discussed elsewhere but is mentioned in my answer to your 
question (2).

21. Because it is mathematically sound in a very general context, so
that one can rely on it, forget the math and concentrate on using it ;-)


> What I'm groping for is something that would tie the expected
> certificate lifetime back to a useful cost measure, I.e.,
>
> 1.  You should use individual attribute certificates rather than
> compound attribute identity certificates if X>Y, for suitable values of
> X and Y??

Yes and No -- and I am not being humorous, it is a fundamental limitation
(though one that I did not yet address here). You need to compromise:

- An individual attribute certificate will be more reliable by itself -- 
so it is a "yes" if your objective is to increase certificate lifetime 
(see item 17 above).

- A compound attribute certificate will be more accurate by itself -- so, 
it is a "no" if your objective is to increase certificate "strength".

>
> 2.  If certificate retrieval costs X, the cost of incorrectly relying on
> an revoked certificate for some transaction is Y, and the time s
> since the certificate was last validated by CL or OCSP checking is T,
> then you should/should not revalidate the certificate??

Well-stated. We need cost-functions and "merit figures" (as usual in 
engineering) in order to facilitate decisions, and what you suggest
is one that must surely face a relying-party. I will cut some corners
below, but hopefully not too many -- I hope it still qualifies for the
"pony award" ;-)

Let me change your "T" for D -- to avoid confusion with the given 
formulas. Here, T is the certificate lifetime.

Please recall the function C(t) = exp (-t/T) given in reference [1] of
my original posting -- the a priori certificate validity function. 
Suppose this function is correctly weighed for its components, so that
it can also be considered as the probability distribution function for *a 
posteriori* certificate validity (it can be, if done as in [1], but note 
that eq. (1) deals with a priori certificate validity). Then,

Y(s) = (1 - C(s - D)) * S , for s > D,

where Y and s are as you defined and S is the value at stake.  To simplify the equation, I will forget the insurance cost, the maximum
risk covered by your insurance policy, the number of times you may
rely on it per month on average, capital costs and non-financial costs 
for  failure (such as good-will), for the moment. Then, I define a
merit-function Q as:

Q(s) = (X - Y(s))/X

and state my rule:

"If Q > 0 then proceed, otherwise validate certificate".

Note that Y(0) = 0 and Q(0) = 1 -- otherwise, Q(s) < 1 for any s.

>
> Any thoughts as to where this can take us?

Towards a mathematical theory of certification, for which much
help and discussions will be, undoubtably, necessary. You may
recall some of the origins of this model of validation, when 
we both discussed the decay of trust after certificate issuance
with time, in list and private discussions. The a priori decay
of trust with time is what makes the attribute validity decay
for the a priori determination of its lifetime. This also shows
that a certificate has many unseen attributes, if you recall
the list I used to discuss the topics, which will nonetheless
reduce its lifetime. One example, of several discussed in
http://www.mcg.org.br/cert.htm , is the validity of the CA 
signing certificate -- which is not mentioned in the subscriber certificate as an attribute but can render it invalid if the CA
cert expires or is revoked before the subscriber's certificate
lifetime expires.

The end objectives are to qualify, quantify and increase 
certificate accuracy and reliance, as well as to provide support
for all modes of certification [http://www.mcg.org.br/cie.htm] 

Since this focused list has a different task, my objective here
was primarily to show that Blackley's formula is not an YARRFS
(Yet Another Random Result From Statistics) as David Kemp 
correctly IMO questioned, but rooted in a more general framework
which validates the intuition behind it and offers some good
tips -- my list of "finger tip" points 1-21 above.

Thus, I expect that this can indeed be useful for the PKIX effort
and for all kinds of certificates, in a simple equation (1) that 
may accomodate all needs -- so far ;-)

Comments?


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11745 for ietf-pkix-bks; Thu, 20 May 1999 08:39:17 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA11740 for <[e-mail]>; Thu, 20 May 1999 08:39:16 -0700 (PDT)
Received: 	id LAA03599; Thu, 20 May 1999 11:32:14 -0400
Received: by gateway id <LBQBDPHJ>; Thu, 20 May 1999 11:34:39 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: Denis Pinkas <[e-mail]>, Sarbari Gupta <[e-mail]>, "'Juan G. de la Vega'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 11:34:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There is certainly no advantage to including the nonce as an authenticated
attribute.  Doing so would add complexity and the nonce would still have to
be included with the token in order to validate the signature.

> ----------
> From: 	Juan G. de la Vega[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 9:38 AM
> To: 	Denis Pinkas; Sarbari Gupta
> Cc: 	[e-mail]
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> 
> Denis Pinkas wrote:
> >
> >Let us separate the two birds:
> >
> >1) as said before the status should be separated from the token,
> >2) the nonce is there to allow a requester that has no local time to make
> >sure that he got a timely reponse from the TSA. So it has to be part of
> the
> >signed structure.
> >
> >
> Denis,
> 
>     Even admitting that no trusted local clock were available (not even
> auth. NTP), the messageImprint field takes account of the problem of
> responses timeliness (use a time variant parameter within the
> messageImprint
> field if you do not have data to stamp). If this is still considered not
> elegant, a nonce field may be used but that doesn't mean that it has to be
> "part of the signed structure", I would say that in that is has to be
> "authenticated", this could be done as proposed by Sarbari at other layer
> or
> even including the nonce as an authenticated attribute of the SignedData
> construct.
> 
> bye,
> 
> Juan.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11676 for ietf-pkix-bks; Thu, 20 May 1999 08:35:25 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA11671 for <[e-mail]>; Thu, 20 May 1999 08:35:23 -0700 (PDT)
Received: 	id LAA02474; Thu, 20 May 1999 11:30:12 -0400
Received: by gateway id <LBQBDPG7>; Thu, 20 May 1999 11:32:37 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Jose A. Manas'" <[e-mail]>, "'Sarbari Gupta'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 11:32:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari;

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 9:24 AM
> To: 	'Jose A. Manas'
> Cc: 	[e-mail]
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> 
> Jose,
> 
> You write:
> >We have identified a business case for this service where the TSA
> >does know the contents. The issue is whether it is a time-stamping
> >service any longer or you have jumped into a notary service.
> >If I were not too purist, I think there are situations
> >We have identified a business case for this service where the TSA
> >does know the contents. The issue is whether it is a time-stamping
> >service any longer or you have jumped into a notary service.
> >If I were not too purist, I think there are situations
> >where the time certificate is something more than a separate
> >appendix, for easiness of storage, transmission, verification,
> >and so on.where the time certificate is something more than a separate
> >appendix, for easiness of storage, transmission, verification,
> >and so on.
> 
> I personally don't see why a timestamping standard cares what data is
> allowed to be timestamped. As far as I know, a notary not only vouches
> for the contents, but also vouches for the identity of the parties that
> are signing the document (to be notarized). So, just allowing data to be
> timestamped does not promote it to a notary service, I think.
> 
No, but as soon as the TSA is allowed to examine the data and must change
it's actions based on that data, it is doing more than just providing a
"proof-of-existence".

> >Packaging things in two levels adds complexity, but does not
> >help any practical situation I may foresee. If simplifity
> >is an objective, a single layer is simpler.
> 
> I agree simplicity should be a goal. The two layer SignedData is
> somewhat complex, but there are other ways of separating the transient
> data (status, nonce) from the long-lived timestamp token.
> 
How can we do this (separate transient data from long-lived data) and still
maintain simplicity and security?

	Robert.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11664 for ietf-pkix-bks; Thu, 20 May 1999 08:35:07 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA11660 for <[e-mail]>; Thu, 20 May 1999 08:35:05 -0700 (PDT)
Received: 	id LAA00398; Thu, 20 May 1999 11:24:39 -0400
Received: by gateway id <LBQBDPF8>; Thu, 20 May 1999 11:27:04 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: Sarbari Gupta <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 11:27:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis;

You wrote:

> ----------
> From: 	Denis Pinkas[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 7:09 AM
> To: 	Sarbari Gupta
> Cc: 	[e-mail]
> Subject: 	Re: Comments on draft-ietf-pkix-time-stamp-01.txt
> 
> I am advocating instead *unsigned errors* as other protocols are doing.
> This
> means that the status error code has to be separated from the signed
> token.
> I have debated this point with the other editors which are favoring to
> sign
> everything and thus why this is included in the current draft. There are
> many arguments for *not* signing errors, including performances and the no
> response case when the TSA is unable to sign. I prefer to get back an
> unsigned error code rather than no response (as mandated today) in such a
> situation.
> 
The only reason we use certificates in the first place is because we don't
trust the integrity of our networks and other system components.  That being
the case, why would we trust an unsigned response?  It's inconsistent.  I
want to know that every response I get from the TSA REALLY came from the
TSA.  

	Robert.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11573 for ietf-pkix-bks; Thu, 20 May 1999 08:28:47 -0700 (PDT)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11569 for <[e-mail]>; Thu, 20 May 1999 08:28:45 -0700 (PDT)
Received: from npwork2 (e1c10p27.scotland.net [148.176.234.91]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id QAA09679; Thu, 20 May 1999 16:25:33 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Date: Thu, 20 May 1999 16:27:14 +0100
Message-ID: <001501bea2d5$3cb82f30$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <v04020a09b369bcd1c104@[128.33.238.64]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

I agree with the aim of not over-loading a certificate.  However, I don't
want to go too far the other way and overload the policy id so that a new
policy id is required for any minor variation on the use certificates within
a common overall policy.

Nick
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: 20 May 1999 14:24
> To: Nick Pope
> Cc: [e-mail]
> Subject: RE: Rename Qualified Certificates?
>
>
> Nick,
>
> I have encountered this issue of putting data of this sort directly into
> the cert or incorporating it by reference in UN e-commerce document as
> well.  Last year Warwick, Mike Baum, Hoyt Kesterson and I co-authored a
> letter to the relevant UN folks urging them to allow incorporation by
> reference.  So, I'd suggest we push for that approach in this standard, in
> an effort to display solidarity in the technical community about how this
> should be done.
>
> Steve
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11472 for ietf-pkix-bks; Thu, 20 May 1999 08:21:40 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA11467 for <[e-mail]>; Thu, 20 May 1999 08:21:39 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id ea004034 for <[e-mail]>; Thu, 20 May 1999 17:22:04 +0100
Message-ID: <013a01bea2d4$111f8f40$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 17:18:47 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert;

Please let me be more specific (comments below):

>Juan;
>
>Again, my comments are below.
>
>> ----------
>> From: Juan G. de la Vega[SMTP:[e-mail]]
>> Sent: Thursday, May 20, 1999 3:43 AM
>> To: Sarbari Gupta; [e-mail]
>> Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
>>
>> Please let me add some further comments upon yours,
>>
>> >4) The current definition of the TSTInfo data structure seems to be
>> >trying to kill two birds with a single stone. It seems that the TSA
>> >response can potentially contain:
>> > - the signed timestamp token
>> > - other information related to the response such as status,
>> >nonce, etc.
>> >As such, it would seem logical to use a nested SignedData structure to
>> >signify the response from the TSA. The first level SignedData would
>> >contain the status, nonce, and (when status = SUCCESS) the timestamp
>> >token. The timestamp token itself would use another SignedData structure
>> >to hold the relevant data of the timestamp token. The actual timestamp
>> >token is for wider distribution - I don't think it is a good design
>> >approach to overload it with transient information such as a nonce.
>> >
>> As a matter of fact, it pleases me that someone addresses this issue. The
>> same structure is being used to support every response from the TSA
>> regardless whether it is a valid time stamp token (with or without
>> transient
>> info) or some other semantic token (i.e. "signed time", error report...).
>> This rises problems not addressed in this draft, namely:
>>
>>     -since tstTime is mandatory, and messageImprint must match the
similar
>> field in the request, problems not related to the time source
>> (non-existing
>> TDAs) lead to ambiguous tokens; the time is correct, the messageImprint
is
>> there, despite the status field states that TDAs were not available,
>> bearing
>> in mind that the TST is signed by the TSA anyway, does not this prove
that
>> a
>> given document existed at a given point in time (Time Stamping!)
>> regardless
>> other circumstances (charging for the service is a good example)?
>>
>I don't see this as a problem.  If the TDAs are not available, the TSA can
>still produce a structure that has the time and message imprint included.
>The status field would correctly indicate that an error occurred.  If a
>token that does not contain all of the TDAs is acceptable to the
>application, then it can use it, otherwise it doesn't.
>

I think I do not get you right. Are you advocating that a structure with a
PKIStatus set to error as  valid and usable?. If this is so, I disagree with
you. I regard that as an error and I would not pay for that, but what I am
saying is that it is still a "proof" and a TSA cannot charge for that
"proof". If you regard the scenario depicted above as acceptable (which
seems reasonable) I recommend to set the PKIStatus to "granted with mods"
instead of  erroneous and I would remove the sentence "A valid time stamp
token will always have value 0 (granted)..." from the I-D.
By the way, I will write other mail regarding the interest for a TDA in TS
protocols.

>> This can be countered by:
>>     - Making the tstTime OPTIONAL => it is funny that a TST is defined
>> regarding time as optional but it should not appear when reporting
errors.
>>
>No.  This creates too many problems

I do not like it either, was just thinking aloud.


>
>>     - Different structures for TST and errors => more complex clients.
>>
>I really don't see a need for this.
>
>>     - Further specification of TSA's behaviour in error cases (i.e. not
>> including message digests)
>>
>Like I said above, I don't see this as a problem.
>
>>     - Using authenticated attributes to specify error status and
transient
>> information so that the TST itself would be optional (if status is
>> erroneous
>> the content of SignedData will not be present)
>>
>I don't quite understand this.  Are you arguing for unsigned error
messages?
>I will respond to that in another email.


No. Authenticated attributes are also signed and must be present since the
ContentType to be signed is not PKCS#9 Data, so it is not costly to add
attributes regarding status, and taking advantage of the OPTIONAL nature of
content field whitin SignedData; if an error ocurred then no content would
be present (i.e. TSTInfo).


>
>> Regarding transient information, I agree that it should not be there, but
>> nested signatures seems a bit of an excess to me, I believe that using
>> Auth.
>> Att. would do or yet better, since we are dealing with transient
>> information, using transient ligthweight authentication (v.g. SSL)
>> perfectly
>> suits its security requirements (what about specifying this within
>> transport
>> section?).
>>
>As I said in an earlier message, I am uncomfortable with changing some of
>the underlying assumptions.  I don't want to assume that this protocol will
>be run over SSL.


There is no need to assume that, you have a transport section in the I-D for
specification.
>
> Robert.
>
>
>

regards,

Juan.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA11019 for ietf-pkix-bks; Thu, 20 May 1999 07:50:47 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA11015 for <[e-mail]>; Thu, 20 May 1999 07:50:45 -0700 (PDT)
Received: 	id KAA15865; Thu, 20 May 1999 10:47:13 -0400
Received: by gateway id <LBQBD363>; Thu, 20 May 1999 10:49:37 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: Sarbari Gupta <[e-mail]>, [e-mail], "'Juan G. de la Vega'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 10:49:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juan;

Again, my comments are below.

> ----------
> From: 	Juan G. de la Vega[SMTP:[e-mail]]
> Sent: 	Thursday, May 20, 1999 3:43 AM
> To: 	Sarbari Gupta; [e-mail]
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> Please let me add some further comments upon yours,
> 
> >4) The current definition of the TSTInfo data structure seems to be
> >trying to kill two birds with a single stone. It seems that the TSA
> >response can potentially contain:
> > - the signed timestamp token
> > - other information related to the response such as status,
> >nonce, etc.
> >As such, it would seem logical to use a nested SignedData structure to
> >signify the response from the TSA. The first level SignedData would
> >contain the status, nonce, and (when status = SUCCESS) the timestamp
> >token. The timestamp token itself would use another SignedData structure
> >to hold the relevant data of the timestamp token. The actual timestamp
> >token is for wider distribution - I don't think it is a good design
> >approach to overload it with transient information such as a nonce.
> >
> As a matter of fact, it pleases me that someone addresses this issue. The
> same structure is being used to support every response from the TSA
> regardless whether it is a valid time stamp token (with or without
> transient
> info) or some other semantic token (i.e. "signed time", error report...).
> This rises problems not addressed in this draft, namely:
> 
>     -since tstTime is mandatory, and messageImprint must match the similar
> field in the request, problems not related to the time source
> (non-existing
> TDAs) lead to ambiguous tokens; the time is correct, the messageImprint is
> there, despite the status field states that TDAs were not available,
> bearing
> in mind that the TST is signed by the TSA anyway, does not this prove that
> a
> given document existed at a given point in time (Time Stamping!)
> regardless
> other circumstances (charging for the service is a good example)?
> 
I don't see this as a problem.  If the TDAs are not available, the TSA can
still produce a structure that has the time and message imprint included.
The status field would correctly indicate that an error occurred.  If a
token that does not contain all of the TDAs is acceptable to the
application, then it can use it, otherwise it doesn't.

> This can be countered by:
>     - Making the tstTime OPTIONAL => it is funny that a TST is defined
> regarding time as optional but it should not appear when reporting errors.
> 
No.  This creates too many problems

>     - Different structures for TST and errors => more complex clients.
> 
I really don't see a need for this.

>     - Further specification of TSA's behaviour in error cases (i.e. not
> including message digests)
> 
Like I said above, I don't see this as a problem.

>     - Using authenticated attributes to specify error status and transient
> information so that the TST itself would be optional (if status is
> erroneous
> the content of SignedData will not be present)
> 
I don't quite understand this.  Are you arguing for unsigned error messages?
I will respond to that in another email.

> Regarding transient information, I agree that it should not be there, but
> nested signatures seems a bit of an excess to me, I believe that using
> Auth.
> Att. would do or yet better, since we are dealing with transient
> information, using transient ligthweight authentication (v.g. SSL)
> perfectly
> suits its security requirements (what about specifying this within
> transport
> section?).
> 
As I said in an earlier message, I am uncomfortable with changing some of
the underlying assumptions.  I don't want to assume that this protocol will
be run over SSL.

	Robert.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10984 for ietf-pkix-bks; Thu, 20 May 1999 07:48:33 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10980 for <[e-mail]>; Thu, 20 May 1999 07:48:29 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATL8C>; Thu, 20 May 1999 10:50:22 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8F1@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, Sarbari Gupta <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, "'Stephen Farrell'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)
Date: Thu, 20 May 1999 10:50:20 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

The advantage is that you do not bundle up (just because it is
convenient at the programming level) transient information into a long
term entity such as the TST. When that TST is sent out to (let's say) a
1000 recipients, what utility is served these 1000 individuals by the
nonce and the status fields?

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Robert Zuccherato [mailto:[e-mail]]
Sent: Thursday, May 20, 1999 10:25 AM
To: 'Sarbari Gupta'; [e-mail]; '[e-mail]'
Cc: 'Denis Pinkas'; 'Peter Sylvester'; 'Stephen Farrell'
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)


Michael;

As I stated in my previous message, I really don't see the advantage of
having a nested structure.  You suggest here that the outer layer
(containing the error information) be optionally unsigned and rely on
other
mechanisms to provide security.  I am extremely uncomfortable with this.
If
we are developing security standards we should make them secure, and not
assume that people will do the right thing at the transport level.  We
have
never made such an assumption, and doing so would be a major change of
focus
for this document.

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, May 19, 1999 9:19 PM
> To: 	'Sarbari Gupta'; [e-mail]
> Cc: 	'Robert Zuccherato'; 'Denis Pinkas'; 'Peter Sylvester'; 'Stephen
> Farrell'
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> (Data+Status)
> 
> Sarbari wrote:
> ---------------------------------------------
> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
> 	- the signed timestamp token
> 	- other information related to the response such as status,
> nonce, etc.
> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData
structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce.
> 
> In fact, to be a purist, a failed timestamp request is not generating
a
> timestamp token, so the error message and the nonce should be signed
by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key.
> -------------------------------------------------
> 
> This is yet another voice in support of the idea we have been tossing
> around
> for a few days (in both private and public mails). The reasons for
> splitting
> the message into data and status were the same as you have come up
with.
> In fact, a similar approach has been proposed by the AC draft.
> 
> For your reference:
> 
> > The whole structure turns into the following:
> >   TSResponseMessage ::= SEQUENCE {
> >        statusInfo   PKIStatusInfo -- from [CMP]
> >        tsoken       SignedData  OPTIONAL -- TSTInfo with NO
statusInfo
> inside there
> >   }
> 
> and another one
> 
> > >  TSResponseMessage ::= CHOICE {
> > >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo
inside
> there
> > >       errorInfo [1]  ErrorMsgContent -- from [CMP]
> > >  }
> 
> 
> Sarbari actually went further, suggesting an extra signed layer around
the
> whole lot. Well, this may answer the argument that sending a
non-signed
> status is a bad thing. Making it optional (leave it to the transport?,
> using
> ContentType? )...
> 
> Do you (the Group) think that the subject MAY deserve a broader
> discussion?
> 
> MichaelZ
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10925 for ietf-pkix-bks; Thu, 20 May 1999 07:42:43 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10918 for <[e-mail]>; Thu, 20 May 1999 07:42:39 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATL75>; Thu, 20 May 1999 10:44:32 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8F0@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 10:44:31 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert:

You write:

This issue has actually been discussed quite a bit both on the list and
at
PKIX meetings.  A Time Stamp Authority, as we have defined it, does not
examine or verify the data being time stamped in any way.  If it did so,
it
would be doing more than just providing a "proof-of-existence" for the
data
at a particular point in time and would become more like a "notary"
service.
(Although the term "notary" is not a good term to use.  Everyone has a
different definition what an electronic notary should do.)  We also
decided
that it was desirable to only have a message imprint within the time
stamp
token and not to include the entire data.  In most circumstances this is
what is desired, and it would prevent people from forcing the TSA to
produce
HUGE time stamp tokens.  If we allowed tokens to be produced using the
actual data instead of the message imprint, the TSA would, in most
cases,
need to examine the data to determine, for example, if the data is too
big
for it to support.  As I stated, this is not allowed in this model. 
 
==> I did not attend the PKIX meetings that you are referring to. If the
majority of folks feel that data SHOULD NOT be timestamped, I am willing
to accept that. 

==> However, your argument sounds somewhat circular. First, you create a
"model" where data cannot be inspected, then you come from the other
direction and say that data cannot be allowed on the incoming request
since the "model" does not allow it. Any "models" that are created
should be based on business/usage requirements. First, we need to
evaluate whether it makes sense for a "business model" where TSTs
contain data (of maximum length to be determined by the TSA) instead of
hashes. If so, I would argue that your "model" needs to be expanded to
accommodate the "business model".

==> I agree that allowing data to be fed in to the TSA implies that the
TSA has to (at the very least) inspect the data length. I don't
understand why this is such a big problem - doesn't the TSA inspect the
hash OID today? Why does inspecting the data length negate the "just
providing a "proof-of-existence" for the data" maxim?    

==> You also write:
Why don't we allow the actual data in the request, but just a message
imprint in the token?  Because then the TSA would have to examine the
request to determine if it contains the actual data (which then must be
hashed) or a message imprint (which doesn't).  Thus, we have the message
imprint in both the request and response.

==> I am not advocating that you support a mode where data is sent in
but the TST contains the imprint. I am proposing that there are business
cases where the TST itself contains small amounts of data (of length TBD
by TSA).


==> You also write:
No, this isn't too restrictive.  Client's must know what entities are
entitled to act as TSAs.  Otherwise, anyone could act as a valid TSA.
==> Setting the Extended Key Usage extension to not be critical can also
have the effect you desire. Clients that care will check that the TSA's
certificate is allowed for timestamping (even though it is
non-critical). However, all clients can verify a TST. 

==> You also write:
I really don't see the advantage of adding this extra layer of
complication.
==> I feel that nonces and status codes SHOULD NOT appear within a TST.
Would you include status codes (related to the cert request) and nonces
within a certificate?

- Sarbari

=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Robert Zuccherato [mailto:[e-mail]]
Sent: Thursday, May 20, 1999 10:06 AM
To: [e-mail]; 'Sarbari Gupta'
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 


Sarbari;

My responses are below.

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Wednesday, May 19, 1999 1:56 PM
> To: 	[e-mail]
> Subject: 	Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> Please accept the following comments on the document:
> 
> 1) Section 2.1 item 6 states that the TSA is required "to only time
> stamp a hash representation of the datum" 
> Why is this so? I think in certain circumstances it may be logical to
> allow the "messageImprint" to be the message itself (e.g., for short
> messages), such that the Time Stamp Token could contain a time-stamped
> version of the actual data. I understand this puts the burden of
> liability on the TSA (since it has seen the data) but this may be
> irrelevant based on the usage model. For example, the TSA may be owned
> and operated by a company that sends out Reminder Messages as a
service
> - in this case, it may be very elegant to package a short reminder
> message within the TST itself instead of using the hash of the
reminder
> message. 
> 
> The point is that a TSA should be allowed to support a timestamping
> service which allows actual data to be sent as part of the request.
The
> perceived legal liabilities and network inefficiencies should not be
> used to restrict the timestamping standard. The standard should allow
> all known usage models - the legal implications and network
efficiencies
> of specific models should be weighed by the TSA before it makes its
> service available. 
> 
This issue has actually been discussed quite a bit both on the list and
at
PKIX meetings.  A Time Stamp Authority, as we have defined it, does not
examine or verify the data being time stamped in any way.  If it did so,
it
would be doing more than just providing a "proof-of-existence" for the
data
at a particular point in time and would become more like a "notary"
service.
(Although the term "notary" is not a good term to use.  Everyone has a
different definition what an electronic notary should do.)  We also
decided
that it was desirable to only have a message imprint within the time
stamp
token and not to include the entire data.  In most circumstances this is
what is desired, and it would prevent people from forcing the TSA to
produce
HUGE time stamp tokens.  If we allowed tokens to be produced using the
actual data instead of the message imprint, the TSA would, in most
cases,
need to examine the data to determine, for example, if the data is too
big
for it to support.  As I stated, this is not allowed in this model. 

Why don't we allow the actual data in the request, but just a message
imprint in the token?  Because then the TSA would have to examine the
request to determine if it contains the actual data (which then must be
hashed) or a message imprint (which doesn't).  Thus, we have the message
imprint in both the request and response.

> 2) Section 2.3 states "The TSA MUST sign all time stamp messages with
a
> key reserved specifically for that purpose" 
> Is there anything to prevent a TSA from using multiple signing keys
for
> signing time stamps - selecting a specific key based on properties of
> the incoming request. I would recommend rewording it to say "...
> messages with one or more keys reserved ..."
> 
I don't think that I meant that the TSA should only have one key.  I
will
change the wording.
>  
> 3) Section 2.3 also states that the TSA's certificate MUST have the
> extended key usage field extension set to critical. This implies that
> only those clients that are able to parse this extension will be able
to
> verify the timestamp token. Isn't this too restrictive? How about
> changing the MUST to a SHOULD or a MAY?
> 
No, this isn't too restrictive.  Client's must know what entities are
entitled to act as TSAs.  Otherwise, anyone could act as a valid TSA.

> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
> 	- the signed timestamp token
> 	- other information related to the response such as status,
> nonce, etc.
> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData
structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce. 
> 
I really don't see the advantage of adding this extra layer of
complication.
(Although I will admit that I haven't read carefully the flood of emails
that I have received from you and others the past 24 hours about this
topic.)

> In fact, to be a purist, a failed timestamp request is not generating
a
> timestamp token, so the error message and the nonce should be signed
by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key. 
> 
In security requirement number 9, the word "token" should be changed to
"message" to be consistent with Section 2.3.  An error message is a time
stamp message, so there is no reason to use a different key for error
messages than for tokens.  I don't see the problem here.

	Robert.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10738 for ietf-pkix-bks; Thu, 20 May 1999 07:26:42 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10734 for <[e-mail]>; Thu, 20 May 1999 07:26:40 -0700 (PDT)
Received: 	id KAA05807; Thu, 20 May 1999 10:22:46 -0400
Received: by gateway id <LBQBD3VF>; Thu, 20 May 1999 10:25:11 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Sarbari Gupta'" <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, "'Stephen Farrell'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)
Date: Thu, 20 May 1999 10:25:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael;

As I stated in my previous message, I really don't see the advantage of
having a nested structure.  You suggest here that the outer layer
(containing the error information) be optionally unsigned and rely on other
mechanisms to provide security.  I am extremely uncomfortable with this.  If
we are developing security standards we should make them secure, and not
assume that people will do the right thing at the transport level.  We have
never made such an assumption, and doing so would be a major change of focus
for this document.

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, May 19, 1999 9:19 PM
> To: 	'Sarbari Gupta'; [e-mail]
> Cc: 	'Robert Zuccherato'; 'Denis Pinkas'; 'Peter Sylvester'; 'Stephen
> Farrell'
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt
> (Data+Status)
> 
> Sarbari wrote:
> ---------------------------------------------
> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
> 	- the signed timestamp token
> 	- other information related to the response such as status,
> nonce, etc.
> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce.
> 
> In fact, to be a purist, a failed timestamp request is not generating a
> timestamp token, so the error message and the nonce should be signed by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key.
> -------------------------------------------------
> 
> This is yet another voice in support of the idea we have been tossing
> around
> for a few days (in both private and public mails). The reasons for
> splitting
> the message into data and status were the same as you have come up with.
> In fact, a similar approach has been proposed by the AC draft.
> 
> For your reference:
> 
> > The whole structure turns into the following:
> >   TSResponseMessage ::= SEQUENCE {
> >        statusInfo   PKIStatusInfo -- from [CMP]
> >        tsoken       SignedData  OPTIONAL -- TSTInfo with NO statusInfo
> inside there
> >   }
> 
> and another one
> 
> > >  TSResponseMessage ::= CHOICE {
> > >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo inside
> there
> > >       errorInfo [1]  ErrorMsgContent -- from [CMP]
> > >  }
> 
> 
> Sarbari actually went further, suggesting an extra signed layer around the
> whole lot. Well, this may answer the argument that sending a non-signed
> status is a bad thing. Making it optional (leave it to the transport?,
> using
> ContentType? )...
> 
> Do you (the Group) think that the subject MAY deserve a broader
> discussion?
> 
> MichaelZ
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10717 for ietf-pkix-bks; Thu, 20 May 1999 07:24:05 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10713 for <[e-mail]>; Thu, 20 May 1999 07:24:02 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id ca004006 for <[e-mail]>; Thu, 20 May 1999 16:24:24 +0100
Message-ID: <00c101bea2cc$025b0460$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Sarbari Gupta" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 16:21:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>This can be countered by:
>>    - Making the tstTime OPTIONAL => it is funny that a TST is defined
>>regarding time as optional but it should not appear when reporting
>errors.
>>    - Different structures for TST and errors => more complex clients.
>>    - Further specification of TSA's behaviour in error cases (i.e. not
>>including message digests)
>>    - Using authenticated attributes to specify error status and
>transient
>>information so that the TST itself would be optional (if status is
>erroneous
>>the content of SignedData will not be present)
>
>Making tstTime OPTIONAL seems to be counter-intuitive. Either the second
>or the third approach sounds fine.

_____________________________________________________
I don´t like the first either ;-) but auth. attrib is also a clean solution.
why don´t you like it? do you regard them as the TST structure?
_____________________________________________________

>Sounds good, too! Are the same credentials used to sign the
>"error-signed" message as well as the "TST-signed" message?
_____________________________________________________
Good question. My first impulse is to answer "yes" but if you think in
what you are protecting I would say that the "service key" should be
replaced much more often and the "error-signing" or notificatión key
should be valid for a much larger period of time. Policies I guess...



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10514 for ietf-pkix-bks; Thu, 20 May 1999 07:07:23 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA10510 for <[e-mail]>; Thu, 20 May 1999 07:07:22 -0700 (PDT)
Received: 	id KAA28876; Thu, 20 May 1999 10:04:08 -0400
Received: by gateway id <LBQBD3PX>; Thu, 20 May 1999 10:06:31 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Sarbari Gupta'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 10:06:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari;

My responses are below.

> ----------
> From: 	Sarbari Gupta[SMTP:[e-mail]]
> Sent: 	Wednesday, May 19, 1999 1:56 PM
> To: 	[e-mail]
> Subject: 	Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> Please accept the following comments on the document:
> 
> 1) Section 2.1 item 6 states that the TSA is required "to only time
> stamp a hash representation of the datum" 
> Why is this so? I think in certain circumstances it may be logical to
> allow the "messageImprint" to be the message itself (e.g., for short
> messages), such that the Time Stamp Token could contain a time-stamped
> version of the actual data. I understand this puts the burden of
> liability on the TSA (since it has seen the data) but this may be
> irrelevant based on the usage model. For example, the TSA may be owned
> and operated by a company that sends out Reminder Messages as a service
> - in this case, it may be very elegant to package a short reminder
> message within the TST itself instead of using the hash of the reminder
> message. 
> 
> The point is that a TSA should be allowed to support a timestamping
> service which allows actual data to be sent as part of the request. The
> perceived legal liabilities and network inefficiencies should not be
> used to restrict the timestamping standard. The standard should allow
> all known usage models - the legal implications and network efficiencies
> of specific models should be weighed by the TSA before it makes its
> service available. 
> 
This issue has actually been discussed quite a bit both on the list and at
PKIX meetings.  A Time Stamp Authority, as we have defined it, does not
examine or verify the data being time stamped in any way.  If it did so, it
would be doing more than just providing a "proof-of-existence" for the data
at a particular point in time and would become more like a "notary" service.
(Although the term "notary" is not a good term to use.  Everyone has a
different definition what an electronic notary should do.)  We also decided
that it was desirable to only have a message imprint within the time stamp
token and not to include the entire data.  In most circumstances this is
what is desired, and it would prevent people from forcing the TSA to produce
HUGE time stamp tokens.  If we allowed tokens to be produced using the
actual data instead of the message imprint, the TSA would, in most cases,
need to examine the data to determine, for example, if the data is too big
for it to support.  As I stated, this is not allowed in this model. 

Why don't we allow the actual data in the request, but just a message
imprint in the token?  Because then the TSA would have to examine the
request to determine if it contains the actual data (which then must be
hashed) or a message imprint (which doesn't).  Thus, we have the message
imprint in both the request and response.

> 2) Section 2.3 states "The TSA MUST sign all time stamp messages with a
> key reserved specifically for that purpose" 
> Is there anything to prevent a TSA from using multiple signing keys for
> signing time stamps - selecting a specific key based on properties of
> the incoming request. I would recommend rewording it to say "...
> messages with one or more keys reserved ..."
> 
I don't think that I meant that the TSA should only have one key.  I will
change the wording.
>  
> 3) Section 2.3 also states that the TSA's certificate MUST have the
> extended key usage field extension set to critical. This implies that
> only those clients that are able to parse this extension will be able to
> verify the timestamp token. Isn't this too restrictive? How about
> changing the MUST to a SHOULD or a MAY?
> 
No, this isn't too restrictive.  Client's must know what entities are
entitled to act as TSAs.  Otherwise, anyone could act as a valid TSA.

> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
> 	- the signed timestamp token
> 	- other information related to the response such as status,
> nonce, etc.
> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce. 
> 
I really don't see the advantage of adding this extra layer of complication.
(Although I will admit that I haven't read carefully the flood of emails
that I have received from you and others the past 24 hours about this
topic.)

> In fact, to be a purist, a failed timestamp request is not generating a
> timestamp token, so the error message and the nonce should be signed by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key. 
> 
In security requirement number 9, the word "token" should be changed to
"message" to be consistent with Section 2.3.  An error message is a time
stamp message, so there is no reason to use a different key for error
messages than for tokens.  I don't see the problem here.

	Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10342 for ietf-pkix-bks; Thu, 20 May 1999 06:53:29 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10338 for <[e-mail]>; Thu, 20 May 1999 06:53:28 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id IAA05422; Thu, 20 May 1999 08:51:21 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id IAA07076; Thu, 20 May 1999 08:51:21 -0500 (CDT)
Message-ID: <003a01bea2c8$2a20bca0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Why do attr. cert. lifetimes matter?,was Example with sub-attributes
Date: Thu, 20 May 1999 08:53:39 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0037_01BEA29E.41185A00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01BEA29E.41185A00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Anders,

>Did you present an AC without the corresponding authenticated PKC?
>If so I wonder if the scenario is valid at all as the AC could be stolen.

No; I just left out the PKC discussion (took it as assumed) in the interest of
focusing on the main point.

>In my vision ACs of this kind (organization-oriented), should only be used in
conjunction
>with an authenticated organization PKC and the AC should be fabricated
on-the-fly by the former.


This is one scenario, but it's certainly also plausible that you could get
ONLY an AC, for example
in cases involving role-based authorization where you want to authenticate the
user and then
assert a role but not the primary identity (this might be important for
privacy reasons, e.g.)

>Then (using my maybe naive thinking) there is no need for CAs, revocation,
CRLs or OCSPs for ACs.  Only for PKCs.
>And PKCs are typically issued by TTPs and therefore none of the listed issues
apply.

I don't get this at all!  How does the relying party know *when* the
organization's CA fabricated
the AC?  And why use a cert. for this at all -- after all, Public-Key
operations are expensive compared
to other ways of doing what is essentially first-party trust.


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_0037_01BEA29E.41185A00
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990520T135339Z
END:VCARD

------=_NextPart_000_0037_01BEA29E.41185A00--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10280 for ietf-pkix-bks; Thu, 20 May 1999 06:45:52 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10276 for <[e-mail]>; Thu, 20 May 1999 06:45:50 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATL54>; Thu, 20 May 1999 09:47:44 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8ED@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 09:47:41 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments embedded below (preceded by ==>)

- Sarbari

=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Thursday, May 20, 1999 7:09 AM
To: Sarbari Gupta
Cc: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt


Sarbari,

My comments are along your text.


> Please accept the following comments on the document:
>
> 1) Section 2.1 item 6 states that the TSA is required "to only time
> stamp a hash representation of the datum"
> Why is this so? I think in certain circumstances it may be logical to
> allow the "messageImprint" to be the message itself (e.g., for short
> messages), such that the Time Stamp Token could contain a time-stamped
> version of the actual data. I understand this puts the burden of
> liability on the TSA (since it has seen the data) but this may be
> irrelevant based on the usage model.

So you have the answer to your question.   :-)
This topic has already been extensively debated and I do not want to
reopen
this thread again.

==> I am still missing the answer that you are alluding to. I seem to
remember that in a previous note on a similar thread, Russ Housley
wrote:
	"I suggest that a one-way hash value of the document or the
document itself
	be used." 
Since nobody countered Russ's note, I was expecting to see the
suggestion implemented in the current draft.  

> For example, the TSA may be owned
> and operated by a company that sends out Reminder Messages as a
service
> - in this case, it may be very elegant to package a short reminder
> message within the TST itself instead of using the hash of the
reminder
> message.
>
> The point is that a TSA should be allowed to support a timestamping
> service which allows actual data to be sent as part of the request.
The
> perceived legal liabilities and network inefficiencies should not be
> used to restrict the timestamping standard. The standard should allow
> all known usage models - the legal implications and network
efficiencies
> of specific models should be weighed by the TSA before it makes its
> service available.
>
> 2) Section 2.3 states "The TSA MUST sign all time stamp messages with
a
> key reserved specifically for that purpose"
> Is there anything to prevent a TSA from using multiple signing keys
for
> signing time stamps - selecting a specific key based on properties of
> the incoming request. I would recommend rewording it to say "...
> messages with one or more keys reserved ..."

I am advocating instead *unsigned errors* as other protocols are doing.
This
means that the status error code has to be separated from the signed
token.
I have debated this point with the other editors which are favoring to
sign
everything and thus why this is included in the current draft. There are
many arguments for *not* signing errors, including performances and the
no
response case when the TSA is unable to sign. I prefer to get back an
unsigned error code rather than no response (as mandated today) in such
a
situation.

In that situation there is no need for multiple signing keys and that
makes
life (and implementations) easier. :-)

==> Unsigned errors may not be acceptable in certain usage domains. The
provision for authenticated error messages (whether through an explicit
protocol or secure transport) should be made in this I-D. 


> 3) Section 2.3 also states that the TSA's certificate MUST have the
> extended key usage field extension set to critical. This implies that
> only those clients that are able to parse this extension will be able
to
> verify the timestamp token. Isn't this too restrictive? How about
> changing the MUST to a SHOULD or a MAY?

I have no strong opinion on that topic. I could live with a MAY.


> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
>         - the signed timestamp token
>         - other information related to the response such as status,
> nonce, etc.

Let us separate the two birds:

1) as said before the status should be separated from the token,
2) the nonce is there to allow a requester that has no local time to
make
sure that he got a timely reponse from the TSA. So it has to be part of
the
signed structure.


> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData
structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce.
>
> In fact, to be a purist, a failed timestamp request is not generating
a
> timestamp token, so the error message and the nonce should be signed
by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key.

This means that nesting is not needed.
==> Logically speaking you are right that the TSA response will either
be an error message or the TST. Depending on the syntax specified for
the response message, a successful response may comprise a signed
message that carries a SUCCESS status, a nonce, and the signed TST (in
which case there is nesting).  

Please let us keep things simple!

==> Agreed.

Regards,

Denis

PS: Do not expect any response from me soon: I will be away from my
office
during a week (without with PC).


>
> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10231 for ietf-pkix-bks; Thu, 20 May 1999 06:41:23 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA10227 for <[e-mail]>; Thu, 20 May 1999 06:41:21 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id fa003983 for <[e-mail]>; Thu, 20 May 1999 15:41:47 +0100
Message-ID: <008b01bea2c6$0da516e0$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Sarbari Gupta" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 15:38:28 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas wrote:
>
>Let us separate the two birds:
>
>1) as said before the status should be separated from the token,
>2) the nonce is there to allow a requester that has no local time to make
>sure that he got a timely reponse from the TSA. So it has to be part of the
>signed structure.
>
>
Denis,

    Even admitting that no trusted local clock were available (not even
auth. NTP), the messageImprint field takes account of the problem of
responses timeliness (use a time variant parameter within the messageImprint
field if you do not have data to stamp). If this is still considered not
elegant, a nonce field may be used but that doesn't mean that it has to be
"part of the signed structure", I would say that in that is has to be
"authenticated", this could be done as proposed by Sarbari at other layer or
even including the nonce as an authenticated attribute of the SignedData
construct.

bye,

Juan.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10173 for ietf-pkix-bks; Thu, 20 May 1999 06:34:10 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10169 for <[e-mail]>; Thu, 20 May 1999 06:34:09 -0700 (PDT)
Received: from [128.33.238.64] (TC033.BBN.COM [128.33.238.33]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA01801; Thu, 20 May 1999 09:34:16 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04020a09b369bcd1c104@[128.33.238.64]>
In-Reply-To: <001001bea2bb$4b66e090$0500000a@npwork2>
References: <[e-mail]>
Date: Thu, 20 May 1999 09:24:16 -0400
To: "Nick Pope" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nick,

I have encountered this issue of putting data of this sort directly into
the cert or incorporating it by reference in UN e-commerce document as
well.  Last year Warwick, Mike Baum, Hoyt Kesterson and I co-authored a
letter to the relevant UN folks urging them to allow incorporation by
reference.  So, I'd suggest we push for that approach in this standard, in
an effort to display solidarity in the technical community about how this
should be done.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10149 for ietf-pkix-bks; Thu, 20 May 1999 06:32:41 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10145 for <[e-mail]>; Thu, 20 May 1999 06:32:39 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATL5H>; Thu, 20 May 1999 09:34:35 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8EC@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Juan G. de la Vega'" <[e-mail]>, [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 09:34:34 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>This can be countered by:
>    - Making the tstTime OPTIONAL => it is funny that a TST is defined
>regarding time as optional but it should not appear when reporting
errors.
>    - Different structures for TST and errors => more complex clients.
>    - Further specification of TSA's behaviour in error cases (i.e. not
>including message digests)
>    - Using authenticated attributes to specify error status and
transient
>information so that the TST itself would be optional (if status is
erroneous
>the content of SignedData will not be present)

Making tstTime OPTIONAL seems to be counter-intuitive. Either the second
or the third approach sounds fine.  

>Regarding transient information, I agree that it should not be there,
but
>nested signatures seems a bit of an excess to me, I believe that using
Auth.
>Att. would do or yet better, since we are dealing with transient
>information, using transient ligthweight authentication (v.g. SSL)
perfectly
>suits its security requirements (what about specifying this within
transport
>section?).

Using transport level security is acceptable to me.

>>In fact, to be a purist, a failed timestamp request is not generating
a
>>timestamp token, so the error message and the nonce should be signed
by
>>a key that is different from the key used to sign a good timestamp
>>token. This is further reason to support nested SignedData structures
>>each of which can be signed by a different key.
>>
>
>I agree with the former but not with the later. In case of error,  an
>"error-signed" message would be issued. Otherwise a "TST-signed" would
do.
>There is no nesting here.

Sounds good, too! Are the same credentials used to sign the
"error-signed" message as well as the "TST-signed" message? 

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Juan G. de la Vega [mailto:[e-mail]]
Sent: Thursday, May 20, 1999 3:44 AM
To: Sarbari Gupta; [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 


Please let me add some further comments upon yours,

>4) The current definition of the TSTInfo data structure seems to be
>trying to kill two birds with a single stone. It seems that the TSA
>response can potentially contain:
> - the signed timestamp token
> - other information related to the response such as status,
>nonce, etc.
>As such, it would seem logical to use a nested SignedData structure to
>signify the response from the TSA. The first level SignedData would
>contain the status, nonce, and (when status = SUCCESS) the timestamp
>token. The timestamp token itself would use another SignedData
structure
>to hold the relevant data of the timestamp token. The actual timestamp
>token is for wider distribution - I don't think it is a good design
>approach to overload it with transient information such as a nonce.
>
As a matter of fact, it pleases me that someone addresses this issue.
The
same structure is being used to support every response from the TSA
regardless whether it is a valid time stamp token (with or without
transient
info) or some other semantic token (i.e. "signed time", error
report...).
This rises problems not addressed in this draft, namely:

    -since tstTime is mandatory, and messageImprint must match the
similar
field in the request, problems not related to the time source
(non-existing
TDAs) lead to ambiguous tokens; the time is correct, the messageImprint
is
there, despite the status field states that TDAs were not available,
bearing
in mind that the TST is signed by the TSA anyway, does not this prove
that a
given document existed at a given point in time (Time Stamping!)
regardless
other circumstances (charging for the service is a good example)?

This can be countered by:
    - Making the tstTime OPTIONAL => it is funny that a TST is defined
regarding time as optional but it should not appear when reporting
errors.
    - Different structures for TST and errors => more complex clients.
    - Further specification of TSA's behaviour in error cases (i.e. not
including message digests)
    - Using authenticated attributes to specify error status and
transient
information so that the TST itself would be optional (if status is
erroneous
the content of SignedData will not be present)

Regarding transient information, I agree that it should not be there,
but
nested signatures seems a bit of an excess to me, I believe that using
Auth.
Att. would do or yet better, since we are dealing with transient
information, using transient ligthweight authentication (v.g. SSL)
perfectly
suits its security requirements (what about specifying this within
transport
section?).


>In fact, to be a purist, a failed timestamp request is not generating a
>timestamp token, so the error message and the nonce should be signed by
>a key that is different from the key used to sign a good timestamp
>token. This is further reason to support nested SignedData structures
>each of which can be signed by a different key.
>

I agree with the former but not with the later. In case of error,  an
"error-signed" message would be issued. Otherwise a "TST-signed" would
do.
There is no nesting here.

kind regards,

Juan.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10074 for ietf-pkix-bks; Thu, 20 May 1999 06:22:56 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10070 for <[e-mail]>; Thu, 20 May 1999 06:22:53 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATLZ0>; Thu, 20 May 1999 09:24:43 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8EB@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'Jose A. Manas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 20 May 1999 09:24:41 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jose,

You write:
>We have identified a business case for this service where the TSA
>does know the contents. The issue is whether it is a time-stamping
>service any longer or you have jumped into a notary service.
>If I were not too purist, I think there are situations
>We have identified a business case for this service where the TSA
>does know the contents. The issue is whether it is a time-stamping
>service any longer or you have jumped into a notary service.
>If I were not too purist, I think there are situations
>where the time certificate is something more than a separate
>appendix, for easiness of storage, transmission, verification,
>and so on.where the time certificate is something more than a separate
>appendix, for easiness of storage, transmission, verification,
>and so on.

I personally don't see why a timestamping standard cares what data is
allowed to be timestamped. As far as I know, a notary not only vouches
for the contents, but also vouches for the identity of the parties that
are signing the document (to be notarized). So, just allowing data to be
timestamped does not promote it to a notary service, I think.

>Packaging things in two levels adds complexity, but does not
>help any practical situation I may foresee. If simplifity
>is an objective, a single layer is simpler.

I agree simplicity should be a goal. The two layer SignedData is
somewhat complex, but there are other ways of separating the transient
data (status, nonce) from the long-lived timestamp token.

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Jose A. Manas [mailto:[e-mail]]
Sent: Thursday, May 20, 1999 2:41 AM
To: Sarbari Gupta
Cc: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt


Sarbari Gupta wrote:
> 
> Please accept the following comments on the document:
> 
> 1) Section 2.1 item 6 states that the TSA is required "to only time
> stamp a hash representation of the datum"
> Why is this so? I think in certain circumstances it may be logical to
> allow the "messageImprint" to be the message itself (e.g., for short
> messages), such that the Time Stamp Token could contain a time-stamped
> version of the actual data. I understand this puts the burden of
> liability on the TSA (since it has seen the data) but this may be
> irrelevant based on the usage model. For example, the TSA may be owned
> and operated by a company that sends out Reminder Messages as a
service
> - in this case, it may be very elegant to package a short reminder
> message within the TST itself instead of using the hash of the
reminder
> message.
> 
> The point is that a TSA should be allowed to support a timestamping
> service which allows actual data to be sent as part of the request.
The
> perceived legal liabilities and network inefficiencies should not be
> used to restrict the timestamping standard. The standard should allow
> all known usage models - the legal implications and network
efficiencies
> of specific models should be weighed by the TSA before it makes its
> service available.

We have identified a business case for this service where the TSA
does know the contents. The issue is whether it is a time-stamping
service any longer or you have jumped into a notary service.
If I were not too purist, I think there are situations
where the time certificate is something more than a separate
appendix, for easiness of storage, transmission, verification,
and so on.

Some cases where I find it makes sense are: certificates,
CRLs, notary statements, ...

> 2) Section 2.3 states "The TSA MUST sign all time stamp messages with
a
> key reserved specifically for that purpose"
> Is there anything to prevent a TSA from using multiple signing keys
for
> signing time stamps - selecting a specific key based on properties of
> the incoming request. I would recommend rewording it to say "...
> messages with one or more keys reserved ..."

I think that quite neat!

> 3) Section 2.3 also states that the TSA's certificate MUST have the
> extended key usage field extension set to critical. This implies that
> only those clients that are able to parse this extension will be able
to
> verify the timestamp token. Isn't this too restrictive? How about
> changing the MUST to a SHOULD or a MAY?

I am not sure about this. I foresee a time stamping verification
client to be a very specific piece of software, that may well
take care of this criticality; so I do not see you are excluding
any one. An asking for this extension may enforce TSA role.

> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
>         - the signed timestamp token
>         - other information related to the response such as status,
> nonce, etc.
> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData
structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce.
> 
> In fact, to be a purist, a failed timestamp request is not generating
a
> timestamp token, so the error message and the nonce should be signed
by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key.

This is right, but too academic for me. If the time-stamping
service goes ok, you get a time certificate that is OK as soon
as it exists. If the service goes wrong, the response is not 
good anyhow.

Packaging things in two levels adds complexity, but does not
help any practical situation I may foresee. If simplifity
is an objective, a single layer is simpler.

> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================

Best,
pepe

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA09911 for ietf-pkix-bks; Thu, 20 May 1999 06:08:39 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA09907 for <[e-mail]>; Thu, 20 May 1999 06:08:37 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATLZP>; Thu, 20 May 1999 09:10:33 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8EA@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: "'Robert Zuccherato'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, "'Stephen Farrell'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)
Date: Thu, 20 May 1999 09:10:32 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would be willing to accept a two-layer scheme where the timestamp
token (without nonce and status) uses the SignedData structure, and the
other information (nonce, status, etc.) passes unsigned with the
assumption that (when necessary) there exists a secure transport
mechanism (such as SSL/TLS). 

This scheme does make the I-D a bit simpler. However, this still implies
the use of separate certificates (one for timestamp token signing and
the other for authentication,) unless the same certificate/key can be
used for authentication as well as timestamping.  

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================

-----Original Message-----
From: Michael Zolotarev [mailto:[e-mail]]
Sent: Wednesday, May 19, 1999 9:19 PM
To: 'Sarbari Gupta'; [e-mail]
Cc: 'Robert Zuccherato'; 'Denis Pinkas'; 'Peter Sylvester'; 'Stephen
Farrell'
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)


Sarbari wrote:
---------------------------------------------
4) The current definition of the TSTInfo data structure seems to be
trying to kill two birds with a single stone. It seems that the TSA
response can potentially contain:
	- the signed timestamp token
	- other information related to the response such as status,
nonce, etc.
As such, it would seem logical to use a nested SignedData structure to
signify the response from the TSA. The first level SignedData would
contain the status, nonce, and (when status = SUCCESS) the timestamp
token. The timestamp token itself would use another SignedData structure
to hold the relevant data of the timestamp token. The actual timestamp
token is for wider distribution - I don't think it is a good design
approach to overload it with transient information such as a nonce.

In fact, to be a purist, a failed timestamp request is not generating a
timestamp token, so the error message and the nonce should be signed by
a key that is different from the key used to sign a good timestamp
token. This is further reason to support nested SignedData structures
each of which can be signed by a different key.
-------------------------------------------------

This is yet another voice in support of the idea we have been tossing
around
for a few days (in both private and public mails). The reasons for
splitting
the message into data and status were the same as you have come up with.
In fact, a similar approach has been proposed by the AC draft.

For your reference:

> The whole structure turns into the following:
>   TSResponseMessage ::= SEQUENCE {
>        statusInfo   PKIStatusInfo -- from [CMP]
>        tsoken       SignedData  OPTIONAL -- TSTInfo with NO statusInfo
inside there
>   }

and another one

> >  TSResponseMessage ::= CHOICE {
> >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo
inside
there
> >       errorInfo [1]  ErrorMsgContent -- from [CMP]
> >  }


Sarbari actually went further, suggesting an extra signed layer around
the
whole lot. Well, this may answer the argument that sending a non-signed
status is a bad thing. Making it optional (leave it to the transport?,
using
ContentType? )...

Do you (the Group) think that the subject MAY deserve a broader
discussion?

MichaelZ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA09033 for ietf-pkix-bks; Thu, 20 May 1999 05:20:25 -0700 (PDT)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA09029 for <[e-mail]>; Thu, 20 May 1999 05:20:23 -0700 (PDT)
Received: from npwork2 (e1c6p50.scotland.net [148.176.233.114]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id NAA12549; Thu, 20 May 1999 13:19:52 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Hans Nilsson" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Date: Thu, 20 May 1999 13:21:32 +0100
Message-ID: <001001bea2bb$4b66e090$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Thanks for your explanation.

I think the main issue is whether this can be indicated by reference to the
CPS or whether it has to be explicit in the certificate.  My understanding
is that the statement "Qualified certificates must contain" implies that it
should be explicit.

Hans, has suggested that we sort out the details of the implication on the
QC draft from the European perspective, outside this list, and then come
back once with have an agreed European understanding.   I'll put together
inital detailed thoughts.

Nick

> -----Original Message-----
> From: Stefan Santesson [mailto:[e-mail]]
> Sent: 20 May 1999 12:00
> To: Nick Pope; Hans Nilsson; Stephen Kent
> Cc: [e-mail]
> Subject: RE: Rename Qualified Certificates?
>
>
> Nick,
>
> I'll be happy to explain how the PKIX-QC profile can be used.
>
> Comments in-line.
>
> At 10:01 AM 5/19/99 +0100, Nick Pope wrote:
> >Stefan,
> >
> >To expand further on my comment regarding the Directive requirements for
> >Qualified Certificates not being met by the current QC draft.
> The specific
> >requirements which I believe ar not met are:
> >
> >(x)	an indication that the certificate is issued as a qualified
> certificate;
> >
> >I consider this include the fact that the certificate is issued
> by a CA (CSP
> >in directive terms) which meets the (annex II) requirement of
> the directive.
> >Hence, I recognize that this is may be outside the scope of the
> PKIX work.
> >
>
> This is solved by including a policy OID in the policy extension, defining
> this property.
>
> The QC-profile says in 3.2.2:
>    A statement by the issuer stating the purpose of the certificate as
>    discussed in 2.3 SHOULD be evident through an indicated policy or
>    through its associated CPS.
>
> And section 2.3 says:
>    For a certificate to serve the purpose of supporting digital signa-
>    tures that are legally compatible with handwritten signatures, it is
>    assumed that the CA will have to make a public statement which states
>    this purpose, presumably published in a CPS.
>
>    The shape of this statement may depend on the governing law under
>    which the CA is operating but in general it is assumed that the CA at
>    least will have to include in its statement that the certificate:
>
>    - is aimed to be used for verification of digital signatures in a
>    context where they are considered "functional equivalent" to hand
>    written signatures and;
>    - meets all requirements, according to the law under which the CA is
>    operating, necessary to support this "functional equivalence".
>
>
> We have given this much thought, and my original proposal was to
> include an
> extension including a "qualified statement". This is however impossible to
> do on an international level. No one will know exactly what such statement
> means unless this is connected to a very specific legal framework.
>
> I guess that this "incorporation by reference" is the best thing we can do
> in an international standard, An the way I read the EU directive, there is
> nothing that forbid this type information to be indicated by the
> policy OID.
>
> I must say that I personally have dedicated myself a lot to have this
> specific requirement added to the directive. I have personally met Mr
> Schlechter at the Commission, talked to him by telephone and sent text
> proposals by mail in order to have this very requirement included in the
> directive, so I am very much aware of the need for this information which
> was forgotten in the first draft.
>
> I just see no other general way to handle this. If you have any
> suggestions
> I'll be happy to hear them.
>
>
> >(b)	the name of the holder or a pseudonym which shall be
> identified as such;
> >
> >I agree that the QC says that it supports pseudonyms.  However,
> it doesn't
> >define how it "shall be identified as such".
>
> Yes it does.
>
> Section 3.2.1 explicitly defines an attribute for pseudonym names. In fact
> the QC-profile give 2 solutions to the problem and any certificate may use
> one or both of these.
>
> 1) The first possibility is to include the pseudonym in the commonName
> attribute in the subject field. In this case the "identified as such" has
> to be taken care of by the policy OID (with the same logic as
> discussed above).
>
> 2) The second and more direct possibility is (as mentioned above) to use
> the pseudonym attribute in the personalData field (defined in 3.2.1) as
> part of the subjects "unmistakable identity"
>
>
> >
> >(i)	limitations on the value of transactions for which the
> certificate can
> >be used if applicable.
> >
> >>From discussions with members of the Commission they require this to be
> >explicit, not through reference to a practice statement.  Hence this
> >requires a specific extension.
> >
>
> Well, this is not how I have interpreted the text in the
> directive, and not
> the impression I have got through my discussions with several "involved"
> people, but I may very well be wrong here.
>
> I'm not sure wether is wise to include such policy information in the
> certificate. I would rather not see that kind of information there and I
> know that Stephen Kent and Warwick have opposed against this type of
> "policy" information.
>
> However, this is something that would be technically possible to
> include if
> required by the European community. This is what the PKIX list is for, to
> have this kind of debates.
>
> >I may have got this wrong, and would very much welcome your views on how
> >these requirements are met.  However, I do not see how a CSP
> wanting to meet
> >these requirements can do the above in a standard way based on
> the QC draft.
> >I would not expect the QC draft to require that fields
> supporting all these
> >functions are always present, but if it is to claim the title of
> "qualified"
> >from the European viewpoint it should define how these functions can be
> >supported.
> >
>
> Since Hans Nilsson, leader of the expert team at EESSI (European
> Electronic
> Signature Standardization Initiative) also have joined the editorial team
> of this work, I have hopes that the European community will take
> the chance
> to make this PKIX profile good and successful for all parties involved.
>
>
> >I would very happy to see the QC document did define ways of
> meeting these
> >requirements.  However, if it doesn't then I would object to the word
> >"qualified" appearing in the title.  Whether followed by the
> word "Profile"
> >or "identity" or whatever.
> >
>
> It is my hope that we will earn the right to carry the name "Qualified"
> according to your standards. Anyway, we have to find a name that most
> people can agree on.
>
> >
> >Independent of the what we call it I would like to know whether
> it is your
> >aim to meet the requirements of the Directive in this document, from the
> >point of view of interoperability as you describe below.
> >
>
> Definitely, as long as the requirements can be met by mechanisms that make
> sense in an international context. If you need specific European
> solutions,
> specifically tailored for the European community, then that may have to be
> solved by some European amendments or in a European profile.
>
> It is my hope though, that such work should not be necessary, but that's
> not for me to decide.
>
> >
> >> Thank you for sharing your thoughts, but I think you got i a
> >> little bit wrong.
> >>
> >What do I have wrong.  That the QC document aims to meet the
> requirements of
> >the Directive to support an equivalent to hand-written signatures, or my
> >understanding of what is supported by the QC document.
> >
>
> The later. I hope I can convince you that you CAN use the PKIX-QC profile
> to form a certificate that meets the requirements from Annex I. If not, I
> would like to see through that is does.
>
> >...
> >>
> >> The PKIX specification is a technical standard for
> interoperability. It's
> >> purpose it so supply you with tools to understand the information
> >> stored in
> >> such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE
> "QUALIFIED" OR
> >> NOT.
> >>
> >I would hope that it facilitates interoperability between
> systems conforming
> >to the Directive.  I agree, from the European viewpoint the definition of
> >what is "qualified" comes from the Directive.
> >
> >> >
> >> >Also, unless it is issued by a CA which also meets the annex
> II it cannot
> >> >claim to meet the full requirements of qualified electronic
> >> signatures which
> >> >are equivalent to hand-written signatures under clause 5.1 of
> >> the directive.
> >> >
> >>
> >> Again the PKIX profile is a TECHNICAL profile FOR Qualified
> Certificates.
> >> It's purpose is NOT to state any functional or other requirements. It's
> >> purpose is only to provide technical interoperability between
> "Qualified
> >> Certificates". E.g. so that the information put into an
> Italian "Qualified
> >> Certificate", can be displayed and understood by a German, English or
> >> American software.
> >>
> >That would be my aim also.  Where the Italian qualfied
> certificate conforms
> >to the Directive and the American software follows the QC document.
>
> That is two different things that can't be compared. The directive is no
> technical standard and the QC document is no legal document. I would say
> that the Italian certificate has to comply with the directive AND the QC
> document in order to achieve full functionality and technical
> interoperability.
>
> >
> >...
> >
> >Hope this helps to clarify my concerns.
> >
> >Nick
>
> Yes id does. Thank you for your views and I hope that we can agree on good
> solutions.
>
> /Stefan
>
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB      http://www.accurata.se
> Slagthuset                      Tel. [phone]
> 211 20  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA08534 for ietf-pkix-bks; Thu, 20 May 1999 04:09:13 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA08530 for <[e-mail]>; Thu, 20 May 1999 04:09:09 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id NAA41082; Thu, 20 May 1999 13:07:27 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA21770; Thu, 20 May 1999 13:07:26 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 13:09:15 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Sarbari Gupta <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
References: <51BF55C30B4FD1118B4900207812701E38F8DE@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari,

My comments are along your text.


> Please accept the following comments on the document:
>
> 1) Section 2.1 item 6 states that the TSA is required "to only time
> stamp a hash representation of the datum"
> Why is this so? I think in certain circumstances it may be logical to
> allow the "messageImprint" to be the message itself (e.g., for short
> messages), such that the Time Stamp Token could contain a time-stamped
> version of the actual data. I understand this puts the burden of
> liability on the TSA (since it has seen the data) but this may be
> irrelevant based on the usage model.

So you have the answer to your question.   :-)
This topic has already been extensively debated and I do not want to reopen
this thread again.


> For example, the TSA may be owned
> and operated by a company that sends out Reminder Messages as a service
> - in this case, it may be very elegant to package a short reminder
> message within the TST itself instead of using the hash of the reminder
> message.
>
> The point is that a TSA should be allowed to support a timestamping
> service which allows actual data to be sent as part of the request. The
> perceived legal liabilities and network inefficiencies should not be
> used to restrict the timestamping standard. The standard should allow
> all known usage models - the legal implications and network efficiencies
> of specific models should be weighed by the TSA before it makes its
> service available.
>
> 2) Section 2.3 states "The TSA MUST sign all time stamp messages with a
> key reserved specifically for that purpose"
> Is there anything to prevent a TSA from using multiple signing keys for
> signing time stamps - selecting a specific key based on properties of
> the incoming request. I would recommend rewording it to say "...
> messages with one or more keys reserved ..."

I am advocating instead *unsigned errors* as other protocols are doing. This
means that the status error code has to be separated from the signed token.
I have debated this point with the other editors which are favoring to sign
everything and thus why this is included in the current draft. There are
many arguments for *not* signing errors, including performances and the no
response case when the TSA is unable to sign. I prefer to get back an
unsigned error code rather than no response (as mandated today) in such a
situation.

In that situation there is no need for multiple signing keys and that makes
life (and implementations) easier. :-)


> 3) Section 2.3 also states that the TSA's certificate MUST have the
> extended key usage field extension set to critical. This implies that
> only those clients that are able to parse this extension will be able to
> verify the timestamp token. Isn't this too restrictive? How about
> changing the MUST to a SHOULD or a MAY?

I have no strong opinion on that topic. I could live with a MAY.


> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
>         - the signed timestamp token
>         - other information related to the response such as status,
> nonce, etc.

Let us separate the two birds:

1) as said before the status should be separated from the token,
2) the nonce is there to allow a requester that has no local time to make
sure that he got a timely reponse from the TSA. So it has to be part of the
signed structure.


> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce.
>
> In fact, to be a purist, a failed timestamp request is not generating a
> timestamp token, so the error message and the nonce should be signed by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key.

This means that nesting is not needed.

Please let us keep things simple!

Regards,

Denis

PS: Do not expect any response from me soon: I will be away from my office
during a week (without with PC).


>
> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA08466 for ietf-pkix-bks; Thu, 20 May 1999 03:59:56 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA08461 for <[e-mail]>; Thu, 20 May 1999 03:59:54 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA08382; Thu, 20 May 1999 13:00:19 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 20 May 1999 12:59:35 +0200
To: "Nick Pope" <[e-mail]>, "Hans Nilsson" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Cc: <[e-mail]>
In-Reply-To: <003301bea1d6$301c31e0$0500000a@npwork2>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA08462
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nick,

I'll be happy to explain how the PKIX-QC profile can be used.

Comments in-line.

At 10:01 AM 5/19/99 +0100, Nick Pope wrote:
>Stefan,
>
>To expand further on my comment regarding the Directive requirements for
>Qualified Certificates not being met by the current QC draft. The specific
>requirements which I believe ar not met are:
>
>(x)	an indication that the certificate is issued as a qualified certificate;
>
>I consider this include the fact that the certificate is issued by a CA (CSP
>in directive terms) which meets the (annex II) requirement of the directive.
>Hence, I recognize that this is may be outside the scope of the PKIX work.
>

This is solved by including a policy OID in the policy extension, defining
this property.

The QC-profile says in 3.2.2:
   A statement by the issuer stating the purpose of the certificate as
   discussed in 2.3 SHOULD be evident through an indicated policy or
   through its associated CPS.

And section 2.3 says:
   For a certificate to serve the purpose of supporting digital signa-
   tures that are legally compatible with handwritten signatures, it is
   assumed that the CA will have to make a public statement which states
   this purpose, presumably published in a CPS.

   The shape of this statement may depend on the governing law under
   which the CA is operating but in general it is assumed that the CA at
   least will have to include in its statement that the certificate:

   - is aimed to be used for verification of digital signatures in a
   context where they are considered "functional equivalent" to hand
   written signatures and;
   - meets all requirements, according to the law under which the CA is
   operating, necessary to support this "functional equivalence".


We have given this much thought, and my original proposal was to include an
extension including a "qualified statement". This is however impossible to
do on an international level. No one will know exactly what such statement
means unless this is connected to a very specific legal framework.

I guess that this "incorporation by reference" is the best thing we can do
in an international standard, An the way I read the EU directive, there is
nothing that forbid this type information to be indicated by the policy OID.

I must say that I personally have dedicated myself a lot to have this
specific requirement added to the directive. I have personally met Mr
Schlechter at the Commission, talked to him by telephone and sent text
proposals by mail in order to have this very requirement included in the
directive, so I am very much aware of the need for this information which
was forgotten in the first draft.

I just see no other general way to handle this. If you have any suggestions
I'll be happy to hear them.


>(b)	the name of the holder or a pseudonym which shall be identified as such;
>
>I agree that the QC says that it supports pseudonyms.  However, it doesn't
>define how it "shall be identified as such".

Yes it does.

Section 3.2.1 explicitly defines an attribute for pseudonym names. In fact
the QC-profile give 2 solutions to the problem and any certificate may use
one or both of these.

1) The first possibility is to include the pseudonym in the commonName
attribute in the subject field. In this case the "identified as such" has
to be taken care of by the policy OID (with the same logic as discussed above).

2) The second and more direct possibility is (as mentioned above) to use
the pseudonym attribute in the personalData field (defined in 3.2.1) as
part of the subjects "unmistakable identity"


>
>(i)	limitations on the value of transactions for which the certificate can
>be used if applicable.
>
>>From discussions with members of the Commission they require this to be
>explicit, not through reference to a practice statement.  Hence this
>requires a specific extension.
>

Well, this is not how I have interpreted the text in the directive, and not
the impression I have got through my discussions with several "involved"
people, but I may very well be wrong here.

I'm not sure wether is wise to include such policy information in the
certificate. I would rather not see that kind of information there and I
know that Stephen Kent and Warwick have opposed against this type of
"policy" information.

However, this is something that would be technically possible to include if
required by the European community. This is what the PKIX list is for, to
have this kind of debates.

>I may have got this wrong, and would very much welcome your views on how
>these requirements are met.  However, I do not see how a CSP wanting to meet
>these requirements can do the above in a standard way based on the QC draft.
>I would not expect the QC draft to require that fields supporting all these
>functions are always present, but if it is to claim the title of "qualified"
>from the European viewpoint it should define how these functions can be
>supported.
>

Since Hans Nilsson, leader of the expert team at EESSI (European Electronic
Signature Standardization Initiative) also have joined the editorial team
of this work, I have hopes that the European community will take the chance
to make this PKIX profile good and successful for all parties involved.   


>I would very happy to see the QC document did define ways of meeting these
>requirements.  However, if it doesn't then I would object to the word
>"qualified" appearing in the title.  Whether followed by the word "Profile"
>or "identity" or whatever.
>

It is my hope that we will earn the right to carry the name "Qualified"
according to your standards. Anyway, we have to find a name that most
people can agree on.

>
>Independent of the what we call it I would like to know whether it is your
>aim to meet the requirements of the Directive in this document, from the
>point of view of interoperability as you describe below.
>

Definitely, as long as the requirements can be met by mechanisms that make
sense in an international context. If you need specific European solutions,
specifically tailored for the European community, then that may have to be
solved by some European amendments or in a European profile.

It is my hope though, that such work should not be necessary, but that's
not for me to decide.

>
>> Thank you for sharing your thoughts, but I think you got i a
>> little bit wrong.
>>
>What do I have wrong.  That the QC document aims to meet the requirements of
>the Directive to support an equivalent to hand-written signatures, or my
>understanding of what is supported by the QC document.
>

The later. I hope I can convince you that you CAN use the PKIX-QC profile
to form a certificate that meets the requirements from Annex I. If not, I
would like to see through that is does.

>...
>>
>> The PKIX specification is a technical standard for interoperability. It's
>> purpose it so supply you with tools to understand the information
>> stored in
>> such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE "QUALIFIED" OR
>> NOT.
>>
>I would hope that it facilitates interoperability between systems conforming
>to the Directive.  I agree, from the European viewpoint the definition of
>what is "qualified" comes from the Directive.
>
>> >
>> >Also, unless it is issued by a CA which also meets the annex II it cannot
>> >claim to meet the full requirements of qualified electronic
>> signatures which
>> >are equivalent to hand-written signatures under clause 5.1 of
>> the directive.
>> >
>>
>> Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
>> It's purpose is NOT to state any functional or other requirements. It's
>> purpose is only to provide technical interoperability between "Qualified
>> Certificates". E.g. so that the information put into an Italian "Qualified
>> Certificate", can be displayed and understood by a German, English or
>> American software.
>>
>That would be my aim also.  Where the Italian qualfied certificate conforms
>to the Directive and the American software follows the QC document.

That is two different things that can't be compared. The directive is no
technical standard and the QC document is no legal document. I would say
that the Italian certificate has to comply with the directive AND the QC
document in order to achieve full functionality and technical interoperability.

>
>...
>
>Hope this helps to clarify my concerns.
>
>Nick

Yes id does. Thank you for your views and I hope that we can agree on good
solutions.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA27535 for ietf-pkix-bks; Thu, 20 May 1999 00:46:52 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA27530 for <[e-mail]>; Thu, 20 May 1999 00:46:51 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id la003807 for <[e-mail]>; Thu, 20 May 1999 09:47:13 +0100
Message-ID: <00c601bea294$859a6420$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Sarbari Gupta" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Thu, 20 May 1999 09:43:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please let me add some further comments upon yours,

>4) The current definition of the TSTInfo data structure seems to be
>trying to kill two birds with a single stone. It seems that the TSA
>response can potentially contain:
> - the signed timestamp token
> - other information related to the response such as status,
>nonce, etc.
>As such, it would seem logical to use a nested SignedData structure to
>signify the response from the TSA. The first level SignedData would
>contain the status, nonce, and (when status = SUCCESS) the timestamp
>token. The timestamp token itself would use another SignedData structure
>to hold the relevant data of the timestamp token. The actual timestamp
>token is for wider distribution - I don't think it is a good design
>approach to overload it with transient information such as a nonce.
>
As a matter of fact, it pleases me that someone addresses this issue. The
same structure is being used to support every response from the TSA
regardless whether it is a valid time stamp token (with or without transient
info) or some other semantic token (i.e. "signed time", error report...).
This rises problems not addressed in this draft, namely:

    -since tstTime is mandatory, and messageImprint must match the similar
field in the request, problems not related to the time source (non-existing
TDAs) lead to ambiguous tokens; the time is correct, the messageImprint is
there, despite the status field states that TDAs were not available, bearing
in mind that the TST is signed by the TSA anyway, does not this prove that a
given document existed at a given point in time (Time Stamping!) regardless
other circumstances (charging for the service is a good example)?

This can be countered by:
    - Making the tstTime OPTIONAL => it is funny that a TST is defined
regarding time as optional but it should not appear when reporting errors.
    - Different structures for TST and errors => more complex clients.
    - Further specification of TSA's behaviour in error cases (i.e. not
including message digests)
    - Using authenticated attributes to specify error status and transient
information so that the TST itself would be optional (if status is erroneous
the content of SignedData will not be present)

Regarding transient information, I agree that it should not be there, but
nested signatures seems a bit of an excess to me, I believe that using Auth.
Att. would do or yet better, since we are dealing with transient
information, using transient ligthweight authentication (v.g. SSL) perfectly
suits its security requirements (what about specifying this within transport
section?).


>In fact, to be a purist, a failed timestamp request is not generating a
>timestamp token, so the error message and the nonce should be signed by
>a key that is different from the key used to sign a good timestamp
>token. This is further reason to support nested SignedData structures
>each of which can be signed by a different key.
>

I agree with the former but not with the later. In case of error,  an
"error-signed" message would be issued. Otherwise a "TST-signed" would do.
There is no nesting here.

kind regards,

Juan.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA23955 for ietf-pkix-bks; Wed, 19 May 1999 23:35:16 -0700 (PDT)
Received: from selva.dit.upm.es (selva-gw.dit.upm.es [138.4.2.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA23943 for <[e-mail]>; Wed, 19 May 1999 23:35:11 -0700 (PDT)
Received: from dit.upm.es (toro-3.dit.upm.es [138.4.21.3]) by selva.dit.upm.es (8.9.1a/8.9.1) with ESMTP id IAA23863; Thu, 20 May 1999 08:34:49 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 20 May 1999 08:41:22 +0200
From: "Jose A. Manas" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sarbari Gupta <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt
References: <51BF55C30B4FD1118B4900207812701E38F8DE@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari Gupta wrote:
> 
> Please accept the following comments on the document:
> 
> 1) Section 2.1 item 6 states that the TSA is required "to only time
> stamp a hash representation of the datum"
> Why is this so? I think in certain circumstances it may be logical to
> allow the "messageImprint" to be the message itself (e.g., for short
> messages), such that the Time Stamp Token could contain a time-stamped
> version of the actual data. I understand this puts the burden of
> liability on the TSA (since it has seen the data) but this may be
> irrelevant based on the usage model. For example, the TSA may be owned
> and operated by a company that sends out Reminder Messages as a service
> - in this case, it may be very elegant to package a short reminder
> message within the TST itself instead of using the hash of the reminder
> message.
> 
> The point is that a TSA should be allowed to support a timestamping
> service which allows actual data to be sent as part of the request. The
> perceived legal liabilities and network inefficiencies should not be
> used to restrict the timestamping standard. The standard should allow
> all known usage models - the legal implications and network efficiencies
> of specific models should be weighed by the TSA before it makes its
> service available.

We have identified a business case for this service where the TSA
does know the contents. The issue is whether it is a time-stamping
service any longer or you have jumped into a notary service.
If I were not too purist, I think there are situations
where the time certificate is something more than a separate
appendix, for easiness of storage, transmission, verification,
and so on.

Some cases where I find it makes sense are: certificates,
CRLs, notary statements, ...

> 2) Section 2.3 states "The TSA MUST sign all time stamp messages with a
> key reserved specifically for that purpose"
> Is there anything to prevent a TSA from using multiple signing keys for
> signing time stamps - selecting a specific key based on properties of
> the incoming request. I would recommend rewording it to say "...
> messages with one or more keys reserved ..."

I think that quite neat!

> 3) Section 2.3 also states that the TSA's certificate MUST have the
> extended key usage field extension set to critical. This implies that
> only those clients that are able to parse this extension will be able to
> verify the timestamp token. Isn't this too restrictive? How about
> changing the MUST to a SHOULD or a MAY?

I am not sure about this. I foresee a time stamping verification
client to be a very specific piece of software, that may well
take care of this criticality; so I do not see you are excluding
any one. An asking for this extension may enforce TSA role.

> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
>         - the signed timestamp token
>         - other information related to the response such as status,
> nonce, etc.
> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce.
> 
> In fact, to be a purist, a failed timestamp request is not generating a
> timestamp token, so the error message and the nonce should be signed by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key.

This is right, but too academic for me. If the time-stamping
service goes ok, you get a time certificate that is OK as soon
as it exists. If the service goes wrong, the response is not 
good anyhow.

Packaging things in two levels adds complexity, but does not
help any practical situation I may foresee. If simplifity
is an objective, a single layer is simpler.

> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> [phone] (voice)
> [phone](FAX)
> [e-mail]
> =================================

Best,
pepe

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA18659 for ietf-pkix-bks; Wed, 19 May 1999 22:04:49 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA18655 for <[e-mail]>; Wed, 19 May 1999 22:04:48 -0700 (PDT)
Received: from mcg.org.br (pm04-32.sac.verio.net [209.162.64.145]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id WAA27521; Wed, 19 May 1999 22:04:55 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 19 May 1999 22:01:31 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Blakley <[e-mail]>
CC: [e-mail]
Subject: Re: Why do attr. cert. lifetimes matter?,was Example with sub-attributes
References: <009001bea22d$90a7d9e0$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Blakley wrote:

> Thanks to Ed for the dialog; nice to lurk a bit & have the flag still flying.

I think we have exceeded the math limit on lists, but what is claim
without proof?

> My initial motivation in looking at this statistic was to figure out what
> percentage of the time attribute certificates would be revoked for reasons
> having nothing to do with the validity of the attributes on the basis of which
> an authorization decision would be made.

Yes, in general any certificate (ie, even an identity certificate) is revoked not
because *everything* in it is wrong but because at least *one* item is wrong.
Thus, the question applies to any certificate -- but especially to attribute
certificates because the probability for at least one item to be wrong should
expectedly increase with the number of items.

....

> None of these has any bearing on whether I'm presenting a valid domain
> name for the purposes of authorization, so a rejection for most of these
> reasons certainly counts as a "false positive".

Yes. The certificate was revoked for a "false" reason -- since that reason was
not relevant to the revocation need for the case at hand.

I note that one of the strong reasons for certificate rejection is when it is
expired, but this can also be a "false positive" -- and expired certificates
can still be useful and valid for all information they contain. An example
I like to use is that an expired driver's license should still allow you to
be identified when cashing a cheque. Another example is that an expired
CA certificate is the only way to allow a new CA certificate to be certified
if it was not introduced before the expiration. There are other examples
of this time logic -- as when you sent a message before your certificate
expires but it is only read after it expires. And yet, the case "expired but
not revoked" is usually not properly handled by certification applications.


> I want to know how often false positives are going to come up if we put
> attribute certificates into use in operational authorization systems, which is
> why the mean useful lifetime of attribute certificates is of interest to me.

Yes, but even if you expect no false positives (suppose, *all* information
is needed, not only that which may cause a revocation), it is useful to estimate
the lifetime of certificates in order to properly manage them and their revocation
needs.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA13663 for ietf-pkix-bks; Wed, 19 May 1999 20:57:42 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA13648 for <[e-mail]>; Wed, 19 May 1999 20:57:36 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id FAA12816 for <[e-mail]>; Thu, 20 May 1999 05:57:45 +0200
Received: from mega (t4o69p39.telia.com [62.20.145.159]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id FAA24544; Thu, 20 May 1999 05:57:43 +0200
Message-ID: <000801bea27d$02c35500$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Bob Blakley" <[e-mail]>, "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Why do attr. cert. lifetimes matter?,was Example with sub-attributes
Date: Thu, 20 May 1999 05:55:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id UAA13657
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob,
comments in line

<snip>

>Hmmm... since that sentence is too long, how about an example?  Let's say my
>attribute
>certificate is my business card (I use this example in talks...).  Let's say
>furthermore that
>what I'm trying to do is download a copy of the Kerberos source code (with
>crypto) from MIT.
>The server is going to check my domain name to make sure I'm a "real
>American".
>But when it looks at my attribute certificate, it might reject it for a number
>of extraneous
>reasons:
>
>        1.         It's been revoked because my department number changed
>        2.         It's been revoked because my name changed
>        3..n.     etc...
>        n+1.    The server doesn't trust my CA
>        n+2.     My CA didn't pay its bill with a cross-certifying agent, so
>it's cert has been revoked
>        ...         (anyone think of any others?)
>


I have a few questions and comments to this.

Did you present an AC without the corresponding authenticated PKC?
If so I wonder if the scenario is valid at all as the AC could be stolen.

In my vision ACs of this kind (organization-oriented), should only be used in conjunction
with an authenticated organization PKC and the AC should be fabricated on-the-fly by the former.

Then (using my maybe naive thinking) there is no need for CAs, revocation, CRLs or OCSPs for ACs.  Only for PKCs. 
And PKCs are typically issued by TTPs and therefore none of the listed issues apply.

<snip>

http://www.mobilephones-tng.com/v100/dynamiccerts.html


Regards
Anders Rundgren




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02832 for ietf-pkix-bks; Wed, 19 May 1999 18:53:21 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02828 for <[e-mail]>; Wed, 19 May 1999 18:53:20 -0700 (PDT)
Received: from mcg.org.br (pm04-19.sac.verio.net [209.162.64.132]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id SAA23107; Wed, 19 May 1999 18:53:22 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 19 May 1999 18:49:59 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail]
Subject: Re: Example with sub-attributes,was  Re: Attribute certificatelifetimes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bob Jueneman wrote:

> Ed,
>
> There must be a pony in here somewhere, but other than an interesting
> mathematical exercise, I'm not sure that I can put my finger on it yet.

Bob:

Well, perhaps this deserves more than just a "pony award" ;-)

Because, in my view, it answers the fundamental question that must
be addressed *before* a certificate is ever issued: "What is to be
this certificate's stated lifetime so that its data is expectedly
valid during its lifetime?". 

Additionally, the following list may be helpful to guide your finger ;-)
and our discussion, where the quotes refers to text in my original 
posting unless otherwise noted:


1. The equation

1/T = 1/T1 + 1/T2 + ... + 1/TN               (1)

is simple enough to be quickly used. It allows one to use engineering
where before one only had guess-work and a bad formula -- outcounting 
Blackley's formula, which deals with a particular case but can be cast
in the same form as Eq. (1).

2. "Since any certificate has attributes (e.g., the date it was issued,
the company name it was issued to, etc.) which may be invalid sooner 
(e.g., Y2K, misspelling, CA error) than the originally intended key 
lifetime, this discussion may be important to provide an upper bound 
for key lifetimes for any type of certificates."

3. "Certificate lifetime with M multiple attributes can be modeled 
in average behavior and without imposing attribute independence, 
by using an exponential decay formula for each effective attribute".

4. "The number N of effective attributes can be larger than the number
M of original multiple attributes in the certificate, which allows the 
representation of sub-attributes that are too significant to be ignored."

5. Attribute certification is no longer a murky situation as described
by David, which lifetime behavior cannot be proved or disproved for 
each calculation. An exponential decay rate can be generally assumed 
for each attribute, which can be made as accurate as desired by 
dividing each attribute into sub-attributes and assigning an 
additional decay rate for each one. This allows even square-function
and abruptly fall offs to be considered in the same certificate.

6. Equation (1) can handle delayed attributes, piecewise exponential
decays, square-function atrributes and any non-increasing function of
attribute validity with time, for any number of attributes.

7. It is irrelevant whether the mean attribute lifetime is significantly
shorter than the mean PK lifetime or not, as David questioned.

8. The distribution of attribute lifetimes is correctly assumed to 
be discrete in Eq. (1), answering a concern by David.

9. It is irrelevant whether the attributes within a single certificate 
are mutually independent or not in order to calculate certificate 
lifetime, answering a concern by David.

10. It is irrelevant whether the attributes within a single certificate
are all jointly independent or not in order to calculate certificate 
lifetime, answering a concern by David.

11. It rolls trippingly off the tongue: "The inverse of the certificate 
lifetime is equal to the sum of the inverses of each effective attribute
lifetime". (a previous good-humored requirement by David)

12. "The lesson here is that you have to make the key lifetime VERY short 
compared to the shortest attribute lifetime in order to get the actual 
lifetime of an attribute certificate close to its nominal lifetime", as 
written by Bob Blackley when showing why his formula could be useful. The
same result applies to Eq. (1), of course.

13. "Certificate lifetime is always shorter than the shortest lifetime".

14. "Key lifetime should be at most 1/3 the shortest attribute's lifetime."

15. "Two attributes with lifetime equal to the key will reduce
certificate lifetime to only 30% of the key lifetime."

16. "Three attributes that each have a lifetime equal to twice the key 
lifetime will nonetheless reduce certificate lifetime to 40% of the key 
lifetime." 

17. "Long-lived certificates should have a least number of attributes".

18. "Denies the usefulness of overloading public-key certificates with 
data in an attempt to increase reliance"

19. "Even for no key the least number of attributes will again result in 
a much longer-lived certificate."

20. It allows one to use the same formalism both for a priori certificate
lifetime calculations as in Eq. (1), as well as for a posteriori 
certificate lifetime calculations -- also called certificate validation.
This will be discussed elsewhere but is mentioned in my answer to your 
question (2).

21. Because it is mathematically sound in a very general context, so
that one can rely on it, forget the math and concentrate on using it ;-)


> What I'm groping for is something that would tie the expected
> certificate lifetime back to a useful cost measure, I.e.,
>
> 1.  You should use individual attribute certificates rather than
> compound attribute identity certificates if X>Y, for suitable values of
> X and Y??

Yes and No -- and I am not being humorous, it is a fundamental limitation
(though one that I did not yet address here). You need to compromise:

- An individual attribute certificate will be more reliable by itself -- 
so it is a "yes" if your objective is to increase certificate lifetime 
(see item 17 above).

- A compound attribute certificate will be more accurate by itself -- so, 
it is a "no" if your objective is to increase certificate "strength".

>
> 2.  If certificate retrieval costs X, the cost of incorrectly relying on
> an revoked certificate for some transaction is Y, and the time s
> since the certificate was last validated by CL or OCSP checking is T,
> then you should/should not revalidate the certificate??

Well-stated. We need cost-functions and "merit figures" (as usual in 
engineering) in order to facilitate decisions, and what you suggest
is one that must surely face a relying-party. I will cut some corners
below, but hopefully not too many -- I hope it still qualifies for the
"pony award" ;-)

Let me change your "T" for D -- to avoid confusion with the given 
formulas. Here, T is the certificate lifetime.

Please recall the function C(t) = exp (-t/T) given in reference [1] of
my original posting -- the a priori certificate validity function. 
Suppose this function is correctly weighed for its components, so that
it can also be considered as the probability distribution function for *a 
posteriori* certificate validity (it can be, if done as in [1], but note 
that eq. (1) deals with a priori certificate validity). Then,

Y(s) = (1 - C(s - D)) * S , for s > D,

where Y and s are as you defined and S is the value at stake.  To simplify the equation, I will forget the insurance cost, the maximum
risk covered by your insurance policy, the number of times you may
rely on it per month on average, capital costs and non-financial costs 
for  failure (such as good-will), for the moment. Then, I define a
merit-function Q as:

Q(s) = (X - Y(s))/X

and state my rule:

"If Q > 0 then proceed, otherwise validate certificate".

Note that Y(0) = 0 and Q(0) = 1 -- otherwise, Q(s) < 1 for any s.

>
> Any thoughts as to where this can take us?

Towards a mathematical theory of certification, for which much
help and discussions will be, undoubtably, necessary. You may
recall some of the origins of this model of validation, when 
we both discussed the decay of trust after certificate issuance
with time, in list and private discussions. The a priori decay
of trust with time is what makes the attribute validity decay
for the a priori determination of its lifetime. This also shows
that a certificate has many unseen attributes, if you recall
the list I used to discuss the topics, which will nonetheless
reduce its lifetime. One example, of several discussed in
http://www.mcg.org.br/cert.htm , is the validity of the CA 
signing certificate -- which is not mentioned in the subscriber certificate as an attribute but can render it invalid if the CA
cert expires or is revoked before the subscriber's certificate
lifetime expires.

The end objectives are to qualify, quantify and increase 
certificate accuracy and reliance, as well as to provide support
for all modes of certification [http://www.mcg.org.br/cie.htm]

Since this focused list has a different task, my objective here
was primarily to show that Blackley's formula is not an YARRFS
(Yet Another Random Result From Statistics) as David Kemp 
correctly IMO questioned, but rooted in a more general framework
which validates the intuition behind it and offers some good
tips -- my list of "finger tip" points 1-21 above.

Thus, I expect that this can indeed be useful for the PKIX effort
and for all kinds of certificates, in a simple equation (1) that 
may accomodate all needs -- so far ;-)

Comments?


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02579 for ietf-pkix-bks; Wed, 19 May 1999 18:21:13 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02575 for <[e-mail]>; Wed, 19 May 1999 18:21:10 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id LAA08014; Thu, 20 May 1999 11:22:53 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Sarbari Gupta'" <[e-mail]>, <[e-mail]>
Cc: "'Robert Zuccherato'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, "'Stephen Farrell'" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt (Data+Status)
Date: Thu, 20 May 1999 11:19:16 +1000
Message-ID: <000101bea25e$c9d493d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <51BF55C30B4FD1118B4900207812701E38F8DE@WUHER>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sarbari wrote:
---------------------------------------------
4) The current definition of the TSTInfo data structure seems to be
trying to kill two birds with a single stone. It seems that the TSA
response can potentially contain:
	- the signed timestamp token
	- other information related to the response such as status,
nonce, etc.
As such, it would seem logical to use a nested SignedData structure to
signify the response from the TSA. The first level SignedData would
contain the status, nonce, and (when status = SUCCESS) the timestamp
token. The timestamp token itself would use another SignedData structure
to hold the relevant data of the timestamp token. The actual timestamp
token is for wider distribution - I don't think it is a good design
approach to overload it with transient information such as a nonce.

In fact, to be a purist, a failed timestamp request is not generating a
timestamp token, so the error message and the nonce should be signed by
a key that is different from the key used to sign a good timestamp
token. This is further reason to support nested SignedData structures
each of which can be signed by a different key.
-------------------------------------------------

This is yet another voice in support of the idea we have been tossing around
for a few days (in both private and public mails). The reasons for splitting
the message into data and status were the same as you have come up with.
In fact, a similar approach has been proposed by the AC draft.

For your reference:

> The whole structure turns into the following:
>   TSResponseMessage ::= SEQUENCE {
>        statusInfo   PKIStatusInfo -- from [CMP]
>        tsoken       SignedData  OPTIONAL -- TSTInfo with NO statusInfo
inside there
>   }

and another one

> >  TSResponseMessage ::= CHOICE {
> >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo inside
there
> >       errorInfo [1]  ErrorMsgContent -- from [CMP]
> >  }


Sarbari actually went further, suggesting an extra signed layer around the
whole lot. Well, this may answer the argument that sending a non-signed
status is a bad thing. Making it optional (leave it to the transport?, using
ContentType? )...

Do you (the Group) think that the subject MAY deserve a broader discussion?

MichaelZ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28376 for ietf-pkix-bks; Wed, 19 May 1999 12:27:57 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28372 for <[e-mail]>; Wed, 19 May 1999 12:27:56 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id OAA03956; Wed, 19 May 1999 14:24:43 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id OAA05348; Wed, 19 May 1999 14:24:38 -0500 (CDT)
Message-ID: <009001bea22d$90a7d9e0$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Why do attr. cert. lifetimes matter?,was Example with sub-attributes
Date: Wed, 19 May 1999 14:26:55 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_008D_01BEA203.A7D1D1E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_008D_01BEA203.A7D1D1E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks to Ed for the dialog; nice to lurk a bit & have the flag still flying.

Bob,


>Ed,
>
>There must be a pony in here somewhere, but other than an interesting
>mathematical exercise, I'm not sure that I can put my finger on it yet.
>
>What I'm groping for is something that would tie the expected
>certificate lifetime back to a useful cost measure, I.e.,

My initial motivation in looking at this statistic was to figure out what
percentage
of the time attribute certificates would be revoked for reasons having nothing
to do with the validity of the attributes on the basis of which an
authorization decision
would be made.

Hmmm... since that sentence is too long, how about an example?  Let's say my
attribute
certificate is my business card (I use this example in talks...).  Let's say
furthermore that
what I'm trying to do is download a copy of the Kerberos source code (with
crypto) from MIT.
The server is going to check my domain name to make sure I'm a "real
American".
But when it looks at my attribute certificate, it might reject it for a number
of extraneous
reasons:

        1.         It's been revoked because my department number changed
        2.         It's been revoked because my name changed
        3..n.     etc...
        n+1.    The server doesn't trust my CA
        n+2.     My CA didn't pay its bill with a cross-certifying agent, so
it's cert has been revoked
        ...         (anyone think of any others?)

None of these has any bearing on whether I'm presenting a valid domain name
for the purposes
of authorization, so a rejection for most of these reasons certainly counts as
a "false positive".
I want to know how often false positives are going to come up if we put
attribute certificates
into use in operational authorization systems, which is why the mean useful
lifetime of
attribute certificates is of interest to me.

>1.  You should use individual attribute certificates rather than
>compound attribute identity certificates if X>Y, for suitable values of
>X and Y??


Essentially this is what I'm getting at in the narrative above.

>2.  If certificate retrieval costs X, the cost of incorrectly relying on
>an revoked certificate for some transaction is Y, and the time s
>since the certificate was last validated by CL or OCSP checking is T,
>then you should/should not revalidate the certificate??


Interesting, but not what I had in mind.

>Any thoughts as to where this can take us?




--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom


------=_NextPart_000_008D_01BEA203.A7D1D1E0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990519T192655Z
END:VCARD

------=_NextPart_000_008D_01BEA203.A7D1D1E0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24892 for ietf-pkix-bks; Wed, 19 May 1999 10:55:02 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24887 for <[e-mail]>; Wed, 19 May 1999 10:55:01 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <K51ATLN7>; Wed, 19 May 1999 13:56:50 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E38F8DE@WUHER>
From: Sarbari Gupta <[e-mail]>
To: [e-mail]
Subject: Comments on draft-ietf-pkix-time-stamp-01.txt 
Date: Wed, 19 May 1999 13:56:49 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please accept the following comments on the document:

1) Section 2.1 item 6 states that the TSA is required "to only time
stamp a hash representation of the datum" 
Why is this so? I think in certain circumstances it may be logical to
allow the "messageImprint" to be the message itself (e.g., for short
messages), such that the Time Stamp Token could contain a time-stamped
version of the actual data. I understand this puts the burden of
liability on the TSA (since it has seen the data) but this may be
irrelevant based on the usage model. For example, the TSA may be owned
and operated by a company that sends out Reminder Messages as a service
- in this case, it may be very elegant to package a short reminder
message within the TST itself instead of using the hash of the reminder
message. 

The point is that a TSA should be allowed to support a timestamping
service which allows actual data to be sent as part of the request. The
perceived legal liabilities and network inefficiencies should not be
used to restrict the timestamping standard. The standard should allow
all known usage models - the legal implications and network efficiencies
of specific models should be weighed by the TSA before it makes its
service available. 

2) Section 2.3 states "The TSA MUST sign all time stamp messages with a
key reserved specifically for that purpose" 
Is there anything to prevent a TSA from using multiple signing keys for
signing time stamps - selecting a specific key based on properties of
the incoming request. I would recommend rewording it to say "...
messages with one or more keys reserved ..."
 
3) Section 2.3 also states that the TSA's certificate MUST have the
extended key usage field extension set to critical. This implies that
only those clients that are able to parse this extension will be able to
verify the timestamp token. Isn't this too restrictive? How about
changing the MUST to a SHOULD or a MAY?

4) The current definition of the TSTInfo data structure seems to be
trying to kill two birds with a single stone. It seems that the TSA
response can potentially contain:
	- the signed timestamp token
	- other information related to the response such as status,
nonce, etc.
As such, it would seem logical to use a nested SignedData structure to
signify the response from the TSA. The first level SignedData would
contain the status, nonce, and (when status = SUCCESS) the timestamp
token. The timestamp token itself would use another SignedData structure
to hold the relevant data of the timestamp token. The actual timestamp
token is for wider distribution - I don't think it is a good design
approach to overload it with transient information such as a nonce. 

In fact, to be a purist, a failed timestamp request is not generating a
timestamp token, so the error message and the nonce should be signed by
a key that is different from the key used to sign a good timestamp
token. This is further reason to support nested SignedData structures
each of which can be signed by a different key. 

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24729 for ietf-pkix-bks; Wed, 19 May 1999 10:51:51 -0700 (PDT)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24724 for <[e-mail]>; Wed, 19 May 1999 10:51:45 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp4.ny.us.ibm.COM (8.8.8/8.8.7) with ESMTP id NAA65574 for <[e-mail]>; Wed, 19 May 1999 13:50:14 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id NAA230788 for <[e-mail]>; Wed, 19 May 1999 13:51:16 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 85256776.006212F0 ; Wed, 19 May 1999 13:51:13 -0400
X-Lotus-FromDomain: IBMUS
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 19 May 1999 13:51:05 -0400
Subject: CRL retrieval 
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am currently writing some code that will be using CRLs to validate
Certificates.  The Certificate portion without CRLs is complete.  I have been
looking for a way to retrieve CRLs from any CA, but especially Verisign and have
been unable to find a repository or any other means to retrive a CRL.  I did
find a page on the Verisign web site that allowed you to enter a certificate on
the web site itself but I need an actual CRL to verify my certificate.  Does
anyone know how to retrieve CRLs or how to retrieve a CRL from Verisign in
particular?

Matthew DeRuyter
bldg 256-2  J006
ext:  x6927
tie-line: 855-6927





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24470 for ietf-pkix-bks; Wed, 19 May 1999 10:35:32 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24466 for <[e-mail]>; Wed, 19 May 1999 10:35:31 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 19 May 1999 11:35:09 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 19 May 1999 11:34:54 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA24467
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nick,

In this connection, you might want to take a look at the certificate quality 
attributes that are contained in Novell Security Attributes extension
that we include in all certificates generated by Novell and/or Novell's
Public Key Infrastructure Services (PKIS) CA, a no charge component
of NetWare 5 , and available very soon on NT and Solaris. See
http://developer.novell.com/repository/attributes/certattrs_v10.htm. 

In particular, the type of CA (whether it is licensed or not) is indicated in 
the Certificate Class (due diligence) subattribute of the CA's certificate -- 
see Appendix D, code values 220=Accredited CA, 225=Governmentally licensed 
or accredited CA, and 240=Government CA.  If those definitions don't
quite fit the specific requirements, I'd be more than happy to add new
ones in that range, or tod discuss minor semantic changes.

Likewise, the same Certificate Class subattribute defines the type
of individual entity, which can range from completely anonymous
(the subject ore gloves to avoid leaving any fingerprints on the knob
of the vending machine where he bought his cert), up through
various locally known unambiguous names, globally unambiguous 
names, electronic pseudonyms, disambiguated names, organizational
persons, registered legal name, publically traded enterprise, chartered 
institutions, quasi-governmental organizations, tribal (semi-autonomous)
authorities, etc.  Again, I think that virtually all of the problems you are
facing have already been addressed, but if not, I'd be happy to 
wok with you to refine the definitions as might be required.

Finally, a Reliance Limit is defined in the same document that 
can be applied on a per transaction or an aggregate, per certificate 
basis (perhaps using something like an extended OCSP which would
accumulate reliance limits per validation), or both.  The Reliance Limit
is coded in such a way to permit denomination in any of the world's
officially recognized currencies, including the Euro, plus gold, silver, 
platinum, and palladium, and various special bond market units, 
special settlement currencies, the multi-national currencies used in
Africa -- CFA Franc BCEAO, operated by the Banque Centrale des 
Etats de l'Afrique de l'Ouest, CFA Franc BEAC, operated by Banque 
des Etats de l'Afrique Centrale, and a code that is specifically
reserved for test purposes. The country codes conform to ISO 4217, 
currency and funds code list, at least as of August, 1998.

BTW, the referred-to document has been circulated within the ECC
and several European countries, and may have helped to define some
of the capabilities they are currently seeking.

Regards,

Bob


Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[e-mail]
1-801-861-7387

>>> "Nick Pope" <[e-mail]> 05/19/99 03:01AM >>>
Stefan,

To expand further on my comment regarding the Directive requirements for
Qualified Certificates not being met by the current QC draft. The specific
requirements which I believe ar not met are:

(x)	an indication that the certificate is issued as a qualified certificate;

I consider this include the fact that the certificate is issued by a CA (CSP
in directive terms) which meets the (annex II) requirement of the directive.
Hence, I recognize that this is may be outside the scope of the PKIX work.

(b)	the name of the holder or a pseudonym which shall be identified as such;

I agree that the QC says that it supports pseudonyms.  However, it doesn't
define how it "shall be identified as such".

(i)	limitations on the value of transactions for which the certificate can
be used if applicable.

>From discussions with members of the Commission they require this to be
explicit, not through reference to a practice statement.  Hence this
requires a specific extension.

I may have got this wrong, and would very much welcome your views on how
these requirements are met.  However, I do not see how a CSP wanting to meet
these requirements can do the above in a standard way based on the QC draft.
I would not expect the QC draft to require that fields supporting all these
functions are always present, but if it is to claim the title of "qualified"
from the European viewpoint it should define how these functions can be
supported.

I would very happy to see the QC document did define ways of meeting these
requirements.  However, if it doesn't then I would object to the word
"qualified" appearing in the title.  Whether followed by the word "Profile"
or "identity" or whatever.


Independent of the what we call it I would like to know whether it is your
aim to meet the requirements of the Directive in this document, from the
point of view of interoperability as you describe below.


> Thank you for sharing your thoughts, but I think you got i a
> little bit wrong.
>
What do I have wrong.  That the QC document aims to meet the requirements of
the Directive to support an equivalent to hand-written signatures, or my
understanding of what is supported by the QC document.

..
>
> The PKIX specification is a technical standard for interoperability. It's
> purpose it so supply you with tools to understand the information
> stored in
> such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE "QUALIFIED" OR
> NOT.
>
I would hope that it facilitates interoperability between systems conforming
to the Directive.  I agree, from the European viewpoint the definition of
what is "qualified" comes from the Directive.

> >
> >Also, unless it is issued by a CA which also meets the annex II it cannot
> >claim to meet the full requirements of qualified electronic
> signatures which
> >are equivalent to hand-written signatures under clause 5.1 of
> the directive.
> >
>
> Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
> It's purpose is NOT to state any functional or other requirements. It's
> purpose is only to provide technical interoperability between "Qualified
> Certificates". E.g. so that the information put into an Italian "Qualified
> Certificate", can be displayed and understood by a German, English or
> American software.
>
That would be my aim also.  Where the Italian qualfied certificate conforms
to the Directive and the American software follows the QC document.

..

Hope this helps to clarify my concerns.

Nick



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24301 for ietf-pkix-bks; Wed, 19 May 1999 10:21:44 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24297 for <[e-mail]>; Wed, 19 May 1999 10:21:42 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id TAA41762; Wed, 19 May 1999 19:19:18 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id TAA21968; Wed, 19 May 1999 19:19:18 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Wed, 19 May 1999 19:21:00 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: "'PKIX mailing group'" <[e-mail]>
Subject: Re: AC509prof-00. LACResponseMessage
References: <000d01bea044$69d9bc10$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

I support your proposal.

Denis


> LACResponseMessage is defined as
>
> LACResponseMessage ::= CHOICE {
>         ac        [0]  AttributeCertificate,
>         errorInfo [1]  ErrorMsgContent -- from [CMP]
>    }
>
> 1. CHOICE makes it impossible to communicate both the AC and non-critical
> errors/warnings. grantedWithMods -do you think it will never be a case with
> AC?  Should it be just a SEQUENCE?
>
> 2. Using ErrorMsgContent is probably not necessary. PKIStatusInfo [CMP] will
> do just fine, and it can communicate both success and failure information.
> The application should attempt parsing the AC data only after checking the
> PKIStatusInfo ::PKIStatus first.
>
> So, my proposal would be:
>
> LACResponseMessage ::= SEQUENCE {
>         errorInfo   PKIStatusInfo -- from [CMP],
>         ac          AttributeCertificate OPTIONAL -- may not be present if a
> critical error occurred
>    }
>
> Michael Zolotarev
> Technical Architect, Baltimore Technologies Limited (Australia)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23088 for ietf-pkix-bks; Wed, 19 May 1999 08:32:31 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA23084 for <[e-mail]>; Wed, 19 May 1999 08:32:30 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 19 May 1999 09:31:25 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5
Date: Wed, 19 May 1999 09:31:07 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Example with sub-attributes,was  Re: Attribute certificate lifetimes
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA23085
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed,

There must be a pony in here somewhere, but other than an interesting
mathematical exercise, I'm not sure that I can put my finger on it yet.

What I'm groping for is something that would tie the expected
certificate lifetime back to a useful cost measure, I.e., 

1.  You should use individual attribute certificates rather than 
compound attribute identity certificates if X>Y, for suitable values of 
X and Y??

2.  If certificate retrieval costs X, the cost of incorrectly relying on 
an revoked certificate for some transaction is Y, and the time s
since the certificate was last validated by CL or OCSP checking is T, 
then you should/should not revalidate the certificate??

Any thoughts as to where this can take us?

Bob

>>> Ed Gerck <[e-mail]> 05/18/99 11:06PM >>>

List:

I received some private requests to work out the example provided
by David Kemp, using sub-attributes to calculate the certificate lifetime.

The example, regrouped for its parts, is:

>Assume that a company has a policy of reassigning its employees
> every three years.  A certificate might have the following
> collection of attributes:
>
>    eye color (lifetime = 72 years)
>    department (lifetime = 3 years)
>    telephone  (lifetime = 3 years)
>    manager    (lifetime = 3 years)
>
> Assume that everyone is happy at this company, so that turnover is very
> low (<1%) and unexpected changes in assignment are rare.
..
> The probability that the phone number remains valid does not decay
> exponentially with time, it remains nearly constant (perhaps decaying
> slightly) for three years, at which point it falls abruptly to near zero.


The lifetime calculation has the following steps:

1. Modelling of effective attributes

1.1 eye color (lifetime = 72 years), single exponential decay
      Te = 1/72

1.2 department (lifetime = 3 years), single exponential decay
       Td = 1/3

1.3 telephone  (lifetime = 3 years), nearly constant for 3 years, then falls
      abruptly to zero. The "telephone" attribute has then two sub-attributes,
      ts and tf:

ts. a very slow decay for three years, which corresponds to a very large
    lifetime, so that Tts >> 1 and 1/Tts ~ 0

tf. a very fast decay if the certificate is more than three years old, which
    corresponds to a very short lifetime, so that Ttf ~ 0 and 1/Ttf >> 1

1.4 manager    (lifetime = 3 years), single exponential decay
      Tm = 3

1.5 certificate holder turnover of < 1% is neglected in period, Th >> 1
      and 1/Th ~ 0.

There are then 7 effective attributes (N = 7) and 5 original attributes (M =  5).


2. Lifetime calculation:

The average certificate lifetime, with calculation valid before three years are
passed from issuance, is:

1/T =  1/72 + 1/3 + 0 + 1/3 + 0 =  1/1.47

So, the average certificate lifetime is 1.47 years. Since the limit of three years
has not been exceeded, the fast Ttf rate is not used. The certificate should
be invalid due to the other reasons before the telephone changes.

This result can now be compared with the two answers tentatively supplied by
David:

- "I contend that the expected lifetime of this certificate is closer to the minimum
    attribute lifetime (3 years)". This is not so -- the expected lifetime of 1.47 years
    is nearly 50% the minimum attribute lifetime of 3 years.

- "the value indicated by your formula (1/3+1/3+1/3+1/72 = .986 years)". This
   is not so, since the value indicated by the formula is actually 1.47 years when
   Ttf is correctly taken into account.


Comments?


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail] 






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22003 for ietf-pkix-bks; Wed, 19 May 1999 07:03:59 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA21999; Wed, 19 May 1999 07:03:57 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 07256776.004D06F8 ; Wed, 19 May 1999 07:01:20 -0700
X-Lotus-FromDomain: BULL
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 19 May 1999 07:00:10 -0700
Subject: the directory documents for ballot are on the server
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello all



I have sent the revised texts into the secretariat for ballot and I have
placed all the texts up on the server at:



    ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/



Each is in both Office 97/98 (.doc) and .pdf formats. The documents are as
follows:



UTF8DAM - final version - awaiting only yes/no votes in ISO/IEC and ITU-T



CertExtFPDAM - the certificate extensions document



Fpdam510 - the F.510 support document



IDMPfpdam - the IDMP (TCP/IP mapping) document



RelatedEntriesPDAM - the Related Entries (to solve the multiple service
providers problem) document



I have placed the disposition of comments at
ftp://ftp.bull.com/pub/OSIdirectory/Orlando99Output/DispositionOfComment/



The dispositions are only in Office 97/98 format.



The documents will be distributed by the SC6 Secretariat, Jean Shidneck.
There is a procedural problem with two documents, Certificate Extensions
and IDMP, that could cause them to be delayed but we are working to correct
that problem. I hoping we can still meet our planned meeting schedule.



Please study them and prepare your comments for this last ballot round. We
plan to have the editing meeing in October in Copenhagen. Vote early and
often.



I'm off to see the Phantom Menace for now



     hoyt





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20773 for ietf-pkix-bks; Wed, 19 May 1999 05:17:39 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20769 for <[e-mail]>; Wed, 19 May 1999 05:17:38 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA13291; Wed, 19 May 1999 14:17:43 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 19 May 1999 14:17:43 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id OAA02106; Wed, 19 May 1999 14:17:42 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id OAA20906; Wed, 19 May 1999 14:17:41 +0200
Date: Wed, 19 May 1999 14:17:41 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Agreed, this is a simple way to include multiple message imprints for those
> applications that really must.  I therefore see no reason to include a
> SEQUENCE OF MessageImprint within the time stamp request and tokens.
> 
IMHO the proposed solution is a dirty hack.

It assumes that you can always determine the length of a hash either by
looking at the OID, or by inspection the CONTENT of some data.  

You can never include a hash function that requires a parameter
in it algorithmIdentifier. 

Well, if you want to be general, you can always fix that by defining all
this in a more complex parameters section. (instead of a sequence of
oid, you would need at sequence of sequence {algorithmidentifier, length}

Or, this second algoritm one can include the other Peter's proposed algorithm
as a value, but not the other way around. 

A somewhat complex solution for a simple problem. 

Peter





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA20707 for ietf-pkix-bks; Wed, 19 May 1999 05:10:45 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA20703 for <[e-mail]>; Wed, 19 May 1999 05:10:44 -0700 (PDT)
Received: from mcg.org.br (pm02-45.sac.verio.net [209.162.64.64]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id FAA15078; Wed, 19 May 1999 05:10:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 19 May 1999 05:06:39 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ron Ramsay <[e-mail]>
CC: [e-mail]
Subject: Re: Example with sub-attributes,was  Re: Attribute certificate lifetimes
References: <D1A949D4508DD1119C8100400533BEDC0CE8EB@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ron Ramsay wrote:

> David's reasoning still seems to represent the real world.

What you apparently miss is that what you call the "real-world" is defined
by you in this case because it all depends what you assume the "real-world"
to be -- you are the design engineer. You must choose the decay rates as
well as the validity periods -- and, as I wrote in my original posting, they can
be empirically defined (by experience), they can be defined using heuristics
(for example, from some simulation you have performed) or by using theory
(for example, from a failure model). This is the first step in enginering: design.

Then, afterwards, you do the second step: calculate the expected average
certificate lifetime using your design and ...deploy your design.

Later on, you verify your design in practice -- how it rates in the real-world
"out there". Which is the third step in engineering, but just prior to the fourth:
feedback -- you may need to change your design according to how it
actually performs.

But, I am sure I am not saying anything new -- just saying that engineering
can now be applied to an area where before you only had guesss-work
and a bad formula ;-)

> I have some
> trouble with your 'nominal' rates. Only two values are really relevant,
> Td and Tm. I don't see that Td is 1/3. If everyone changes positions at
> 3 years, Td should be handled as for phone and effectively ignored.
> Hence
>
> 1/T ~ Td
>
> That is,
>
> T ~ 3 years.

Fine and good -- I meant to exemplify and followed David's example without
adding anything to it. Where he wrote "lifetime" I supposed *one* exponential
decay; where he wrote that two decay rates were used I consistently used
*two* exponential decay rates. You may note that, efffectively, the telephone
validity function was modeled as a square function -- both by David as well as
so represented by myself. Thus, if David was careful enough (that is, as careful
as a loose example may allow)  to point out that the telephone validity function
had two decay rates and was actually very close to a square function, then this
implies by a logical construct called negative pregnant that he did NOT intend to
make the same distinction for the other rates -- so, I justifiedly, employed just
one rate for each one of them.

But, if you read more information between the lines, please use it ;-) the
tool is there to allow it.

Cheers,

Ed Gerck




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA16112 for ietf-pkix-bks; Wed, 19 May 1999 02:00:02 -0700 (PDT)
Received: from gnasher.sol.co.uk (gnasher.sol.co.uk [194.247.65.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA16105 for <[e-mail]>; Wed, 19 May 1999 02:00:00 -0700 (PDT)
Received: from npwork2 (e2c6p32.scotland.net [148.176.237.96]) by gnasher.sol.co.uk (8.8.5/8.8.5) with SMTP id JAA15329; Wed, 19 May 1999 09:59:53 +0100 (BST)
From: "Nick Pope" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Hans Nilsson" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Date: Wed, 19 May 1999 10:01:31 +0100
Message-ID: <003301bea1d6$301c31e0$0500000a@npwork2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

To expand further on my comment regarding the Directive requirements for
Qualified Certificates not being met by the current QC draft. The specific
requirements which I believe ar not met are:

(x)	an indication that the certificate is issued as a qualified certificate;

I consider this include the fact that the certificate is issued by a CA (CSP
in directive terms) which meets the (annex II) requirement of the directive.
Hence, I recognize that this is may be outside the scope of the PKIX work.

(b)	the name of the holder or a pseudonym which shall be identified as such;

I agree that the QC says that it supports pseudonyms.  However, it doesn't
define how it "shall be identified as such".

(i)	limitations on the value of transactions for which the certificate can
be used if applicable.

>From discussions with members of the Commission they require this to be
explicit, not through reference to a practice statement.  Hence this
requires a specific extension.

I may have got this wrong, and would very much welcome your views on how
these requirements are met.  However, I do not see how a CSP wanting to meet
these requirements can do the above in a standard way based on the QC draft.
I would not expect the QC draft to require that fields supporting all these
functions are always present, but if it is to claim the title of "qualified"
from the European viewpoint it should define how these functions can be
supported.

I would very happy to see the QC document did define ways of meeting these
requirements.  However, if it doesn't then I would object to the word
"qualified" appearing in the title.  Whether followed by the word "Profile"
or "identity" or whatever.


Independent of the what we call it I would like to know whether it is your
aim to meet the requirements of the Directive in this document, from the
point of view of interoperability as you describe below.


> Thank you for sharing your thoughts, but I think you got i a
> little bit wrong.
>
What do I have wrong.  That the QC document aims to meet the requirements of
the Directive to support an equivalent to hand-written signatures, or my
understanding of what is supported by the QC document.

...
>
> The PKIX specification is a technical standard for interoperability. It's
> purpose it so supply you with tools to understand the information
> stored in
> such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE "QUALIFIED" OR
> NOT.
>
I would hope that it facilitates interoperability between systems conforming
to the Directive.  I agree, from the European viewpoint the definition of
what is "qualified" comes from the Directive.

> >
> >Also, unless it is issued by a CA which also meets the annex II it cannot
> >claim to meet the full requirements of qualified electronic
> signatures which
> >are equivalent to hand-written signatures under clause 5.1 of
> the directive.
> >
>
> Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
> It's purpose is NOT to state any functional or other requirements. It's
> purpose is only to provide technical interoperability between "Qualified
> Certificates". E.g. so that the information put into an Italian "Qualified
> Certificate", can be displayed and understood by a German, English or
> American software.
>
That would be my aim also.  Where the Italian qualfied certificate conforms
to the Directive and the American software follows the QC document.

...

Hope this helps to clarify my concerns.

Nick



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA09713 for ietf-pkix-bks; Tue, 18 May 1999 23:30:39 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA09613 for <[e-mail]>; Tue, 18 May 1999 23:30:27 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <LFRD3YFN>; Wed, 19 May 1999 16:30:22 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0CE8EB@DSG1>
From: Ron Ramsay <[e-mail]>
To: "'Ed Gerck'" <[e-mail]>, [e-mail]
Subject: RE: Example with sub-attributes,was  Re: Attribute certificate li fetimes
Date: Wed, 19 May 1999 16:30:22 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David's reasoning still seems to represent the real world. I have some
trouble with your 'nominal' rates. Only two values are really relevant,
Td and Tm. I don't see that Td is 1/3. If everyone changes positions at
3 years, Td should be handled as for phone and effectively ignored.
Hence

1/T ~ Td

That is,

T ~ 3 years.

> -----Original Message-----
> From:	Ed Gerck [SMTP:[e-mail]]
> Sent:	Wednesday, May 19, 1999 3:07 PM
> To:	[e-mail]
> Subject:	Example with sub-attributes,was  Re: Attribute
> certificate lifetimes
> 
> 
> List:
> 
> I received some private requests to work out the example provided
> by David Kemp, using sub-attributes to calculate the certificate
> lifetime.
> 
> The example, regrouped for its parts, is:
> 
> >Assume that a company has a policy of reassigning its employees
> > every three years.  A certificate might have the following
> > collection of attributes:
> >
> >    eye color (lifetime = 72 years)
> >    department (lifetime = 3 years)
> >    telephone  (lifetime = 3 years)
> >    manager    (lifetime = 3 years)
> >
> > Assume that everyone is happy at this company, so that turnover is
> very
> > low (<1%) and unexpected changes in assignment are rare.
> ...
> > The probability that the phone number remains valid does not decay
> > exponentially with time, it remains nearly constant (perhaps
> decaying
> > slightly) for three years, at which point it falls abruptly to near
> zero.
> 
> 
> The lifetime calculation has the following steps:
> 
> 1. Modelling of effective attributes
> 
> 1.1 eye color (lifetime = 72 years), single exponential decay
>       Te = 1/72
> 
> 1.2 department (lifetime = 3 years), single exponential decay
>        Td = 1/3
> 
> 1.3 telephone  (lifetime = 3 years), nearly constant for 3 years, then
> falls
>       abruptly to zero. The "telephone" attribute has then two
> sub-attributes,
>       ts and tf:
> 
> ts. a very slow decay for three years, which corresponds to a very
> large
>     lifetime, so that Tts >> 1 and 1/Tts ~ 0
> 
> tf. a very fast decay if the certificate is more than three years old,
> which
>     corresponds to a very short lifetime, so that Ttf ~ 0 and 1/Ttf >>
> 1
> 
> 1.4 manager    (lifetime = 3 years), single exponential decay
>       Tm = 3
> 
> 1.5 certificate holder turnover of < 1% is neglected in period, Th >>
> 1
>       and 1/Th ~ 0.
> 
> There are then 7 effective attributes (N = 7) and 5 original
> attributes (M =  5).
> 
> 
> 2. Lifetime calculation:
> 
> The average certificate lifetime, with calculation valid before three
> years are
> passed from issuance, is:
> 
> 1/T =  1/72 + 1/3 + 0 + 1/3 + 0 =  1/1.47
> 
> So, the average certificate lifetime is 1.47 years. Since the limit of
> three years
> has not been exceeded, the fast Ttf rate is not used. The certificate
> should
> be invalid due to the other reasons before the telephone changes.
> 
> This result can now be compared with the two answers tentatively
> supplied by
> David:
> 
> - "I contend that the expected lifetime of this certificate is closer
> to the minimum
>     attribute lifetime (3 years)". This is not so -- the expected
> lifetime of 1.47 years
>     is nearly 50% the minimum attribute lifetime of 3 years.
> 
> - "the value indicated by your formula (1/3+1/3+1/3+1/72 = .986
> years)". This
>    is not so, since the value indicated by the formula is actually
> 1.47 years when
>    Ttf is correctly taken into account.
> 
> 
> Comments?
> 
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                 [e-mail]
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA06051 for ietf-pkix-bks; Tue, 18 May 1999 22:38:28 -0700 (PDT)
Received: from earth.softforum.co.kr ([210.124.178.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA06041 for <[e-mail]>; Tue, 18 May 1999 22:38:26 -0700 (PDT)
Received: from softforum.co.kr (p-dhlee.softforum.co.kr [210.124.178.87]) by earth.softforum.co.kr (8.9.3/8.8.7) with ESMTP id OAA06845 for <[e-mail]>; Wed, 19 May 1999 14:32:49 +0900 (KST)
Message-ID: <[e-mail]>
Date: Wed, 19 May 1999 14:42:35 +0900
From: =?iso-8859-1?Q?=C0=CC=B5=BF=C8=A3?= <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ieft <[e-mail]>
Subject: Some comments on PKI toolkit
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If you have some comments on PKI toolkit,
please advise me.

I wanna make PIK toolkit library including
cryptographic algorithms, DER encoding compiler, path validator,
POPer...

When you develpe PKI,  you may need some functions which make you
convinient. please tell me such things~

Have a good day..


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02437 for ietf-pkix-bks; Tue, 18 May 1999 22:09:54 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02432 for <[e-mail]>; Tue, 18 May 1999 22:09:53 -0700 (PDT)
Received: from mcg.org.br (pm09-13.sac.verio.net [209.162.65.126]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id WAA05430 for <[e-mail]>; Tue, 18 May 1999 22:09:56 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 18 May 1999 22:06:37 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Example with sub-attributes,was  Re: Attribute certificate lifetimes
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

List:

I received some private requests to work out the example provided
by David Kemp, using sub-attributes to calculate the certificate lifetime.

The example, regrouped for its parts, is:

>Assume that a company has a policy of reassigning its employees
> every three years.  A certificate might have the following
> collection of attributes:
>
>    eye color (lifetime = 72 years)
>    department (lifetime = 3 years)
>    telephone  (lifetime = 3 years)
>    manager    (lifetime = 3 years)
>
> Assume that everyone is happy at this company, so that turnover is very
> low (<1%) and unexpected changes in assignment are rare.
...
> The probability that the phone number remains valid does not decay
> exponentially with time, it remains nearly constant (perhaps decaying
> slightly) for three years, at which point it falls abruptly to near zero.


The lifetime calculation has the following steps:

1. Modelling of effective attributes

1.1 eye color (lifetime = 72 years), single exponential decay
      Te = 1/72

1.2 department (lifetime = 3 years), single exponential decay
       Td = 1/3

1.3 telephone  (lifetime = 3 years), nearly constant for 3 years, then falls
      abruptly to zero. The "telephone" attribute has then two sub-attributes,
      ts and tf:

ts. a very slow decay for three years, which corresponds to a very large
    lifetime, so that Tts >> 1 and 1/Tts ~ 0

tf. a very fast decay if the certificate is more than three years old, which
    corresponds to a very short lifetime, so that Ttf ~ 0 and 1/Ttf >> 1

1.4 manager    (lifetime = 3 years), single exponential decay
      Tm = 3

1.5 certificate holder turnover of < 1% is neglected in period, Th >> 1
      and 1/Th ~ 0.

There are then 7 effective attributes (N = 7) and 5 original attributes (M =  5).


2. Lifetime calculation:

The average certificate lifetime, with calculation valid before three years are
passed from issuance, is:

1/T =  1/72 + 1/3 + 0 + 1/3 + 0 =  1/1.47

So, the average certificate lifetime is 1.47 years. Since the limit of three years
has not been exceeded, the fast Ttf rate is not used. The certificate should
be invalid due to the other reasons before the telephone changes.

This result can now be compared with the two answers tentatively supplied by
David:

- "I contend that the expected lifetime of this certificate is closer to the minimum
    attribute lifetime (3 years)". This is not so -- the expected lifetime of 1.47 years
    is nearly 50% the minimum attribute lifetime of 3 years.

- "the value indicated by your formula (1/3+1/3+1/3+1/72 = .986 years)". This
   is not so, since the value indicated by the formula is actually 1.47 years when
   Ttf is correctly taken into account.


Comments?


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA29187 for ietf-pkix-bks; Tue, 18 May 1999 21:32:39 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA29178 for <[e-mail]>; Tue, 18 May 1999 21:32:37 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id GAA19354 for <[e-mail]>; Wed, 19 May 1999 06:32:40 +0200
Received: from mega (t4o69p63.telia.com [62.20.145.183]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id GAA110035; Wed, 19 May 1999 06:32:38 +0200
Message-ID: <002601bea1b8$b9ddfc60$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "'SEIS-List'" <[e-mail]>, <[e-mail]>
Subject: Re: QC Interoperability     Was: Rename Qualified Certificates?
Date: Wed, 19 May 1999 06:30:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id VAA29181
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

>Anders,
>
>The profile being discussed here addresses syntax for a specicial class of
>certificates in the same way that RFC 2459 addresses syntax for a broader
>class of X.509 certs.  None of the documents specifies how an application
>will employ the raneg of data that can be represented in certs, especially
>in light of the large number of optional extensions that are available.

Exactly.  That was why I questioned Stefan's statement that QCs would support technical 
interoperability.  I sure does NOT.

The only thing that QC provides is a framework for creating ID-certificates.
It CAN speedup the process to create an actual implementation a bit, but only very
marginally.

IMO the value of that is [unfortunately] EXTREMELY limted as X509.v3 already is a framework itself.

<snip>

Anders




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA06498 for ietf-pkix-bks; Tue, 18 May 1999 19:06:56 -0700 (PDT)
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.120.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA06492 for <[e-mail]>; Tue, 18 May 1999 19:06:55 -0700 (PDT)
Received: from brick (dialup-209.245.137.204.SanJose1.Level3.net [209.245.137.204]) by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id TAA25413; Tue, 18 May 1999 19:06:58 -0700 (PDT)
Message-ID: <006e01bea19c$42088fa0$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Todd S. Glassey - ELN" <[e-mail]>, "IETF PKIX" <[e-mail]>
References: <03a901bea16b$cc52bea0$930aff0c@brick>
Subject: Re: I-D ACTION:draft-ietf-pkix-bert1-00.txt
Date: Tue, 18 May 1999 19:06:48 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry Steve, it was just the posting notice.

----- Original Message -----
From: Todd S. Glassey - ELN <[e-mail]>
To: IETF PKIX <[e-mail]>
Sent: Tuesday, May 18, 1999 1:19 PM
Subject: Fw: I-D ACTION:draft-ietf-pkix-bert1-00.txt


> Friends,
> this BERT draft is intended to create a consciousness that one of the more
> valuable things we as a standards team can do is to create a suite of
> specific "token structures" that other standards groups can use to
represent
> data elements and events within their transaction models.
>
> BERT is intended to give us a  FSF/GNU-style token architecture that we
can
> all interoperate through with regard to document processing.
>
> BERT then is more than it seems, it is an agreement between a number of
key
> market participants to make and create a timestamping marketplace. BERT is
> both technical and political then, but lets address the technical side of
> BERT here.
>
> The ASN issue
> ----------------
> Michael and I are fully aware that we will need to create an ASN variant
of
> the BERT and also to allow for several use-specific intentions. We have a
> variant of this structure that would contain a document
>
> For the first effort, we needed to provide a mechanism that can be used
from
> within existing legacy apps to add timestamping and nonrepudiation thereof
> to. This meant that the timestamp token had to fit comfortably inside a
> DBMS.
>
> The key intent was to create the binary format for the timestamp so that
it
> could easily fit into existing database systems for authenticating OLTP
> events and the like. Also, that by coupling this system with technologies
> like Counterpane's mindset for secure logging, you would potentially have
a
> legally credible logging system for event processing.
>
> This structure we are proposing for the BERT v1 was the best compromise
when
> we checked with the end users, but it can be changed as needed.
>
> Todd
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA05712 for ietf-pkix-bks; Tue, 18 May 1999 19:05:14 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA05699 for <[e-mail]>; Tue, 18 May 1999 19:05:13 -0700 (PDT)
Received: from mcg.org.br (pm06-25.sac.verio.net [209.162.64.232]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id TAA01757; Tue, 18 May 1999 19:05:11 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 18 May 1999 19:01:53 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Attribute certificate lifetimes: still way too much math
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"David P. Kemp" wrote:

> > From: Ed Gerck <[e-mail]>
> >
> > REPLY:  Try equation (1) : "The inverse of the certificate lifetime is equal
> > to the sum of the inverses of each effective attribute lifetime".
>
> That is true as long as your assumption holds.  But if the assumption
> does not hold, the equation fails.  Garbage in, garbage out.

My assumption is very unassuming ;-)  -- it is simply that any attribute validity
in a X.509/PKIX cert is an non-increasing function of time. If you find a
X.509/PKIX attribute that increases its validity with time then you have found
an exception where my formula (and Blackley's, buy extension) is not valid.

That exception would be trust, of course, since trust can indeed increase with time
and increase reliance, thus validity (so we hope, usually).   Trust is earned and can
benefit from learning. But since trust is not contained in a X.509/PKIX
certificate's attributes, then this exception does not apply where my formula applies
here -- for PKIX certificates.


> For a counterexample, assume that a company has a policy of reassigning
> its employees every three years.  A certificate might have the following
> collection of attributes:
>
>    eye color (lifetime = 72 years)
>    department (lifetime = 3 years)
>    telephone  (lifetime = 3 years)
>    manager    (lifetime = 3 years)
>
> Assume that everyone is happy at this company, so that turnover is very
> low (<1%) and unexpected changes in assignment are rare.  I contend that
> the expected lifetime of this certificate is closer to the minimum attribute
> lifetime (3 years) than the value indicated by your formula
> (1/3+1/3+1/3+1/72 = .986 years).

No. Please realize that you are simply applying the formula and then denying
its very parameters that *you* defined -- since nowhere above you say
what you assume below in order to "contend" that the certificate lifetime
is close to 3 years. Indeed,  garbage in, garbage out -- one must be
consistent in problem formulation. What I mean is that it is OK for you
to assume that the phone number remains valid for three years with an
almost flat validity and then abruptly falls to zero -- but why in heavens
don't you use *this* information in the formula above?

Please, see below how this can be used -- and, indeed, you MUST if this is
what you rely on (please see reference [1] of my posting). Otherwise, the
problem is just being inconsistently formulated -- not inconsistently solved.

> The probability that the phone number remains valid does not decay
> exponentially with time, it remains nearly constant (perhaps decaying
> slightly) for three years, at which point it falls abruptly to near zero.

If you say so ;-) -- but still my model applies. Let me explain.

As you say -- but this simply means that you need two lifetimes (as I called
them, two sub-attributes). One lifetime is very long and just leads to that
slight decay you mention for three years. Then, another lifetime is triggered
by a delayed sub-attribute, but this lifetime is very short. But, you may ask, how
can I take delayed sub-attributes into account? Simple, by considering the
certitficate lifetime to be given by a piecewise function. It does NOT include
the short-lifetime delayed attribute until its maturation period (that you say is
3 years), and then adds it as 1/Ts. But, since Ts is small, 1/Ts is large and its
effect on the certificate lifetime T is large. So, a small Ts strongly
*decreases*  certificate lifetime T, since 1/T = (1/T1 + ..1/Tm) + 1/Ts and
(1/T1 + ...+ 1/Tm) is constant. Clear?


> You could argue that the three attributes above are correlated and should
> be lumped together, but I could come up with a counterexample with three
> non-correlated step-functions that would confound the use of a simple,
> generally applicable formula.

No, that is not what I argued :-)  I simply argue that if you withhold information
when you apply the formula then you can't expect the formula to represent what
you don't say.

> The content of my message to Bob was 86% a failed attempt at humor, and
> 14% a general observation that correct statistical calculations (and I
> agree that your math and his is correct) will not help if the model does
> not fit the data.

The model I presented can fit any cert data (as above, for your example) as
long as the attributes' validities are monotonically decreasing functions of
time -- which is a very general assumption. The difficulty I see with your
example was that your later data did not fit the problem you initially described
-- not that the model could not fit the data once that data was decloaked ;-)

Your example was though excellent in that it allowed this to be discussed and
exemplified -- and, even though sub-attributes and their need as well as why
N >= M are mentioned several times in my previous posting, the issue was not
exemplified.

One application of a similar theory is in fluorescent studies of excited atoms,
where a particular forbidden (ie, very long lifetime) radiative transition lifetime
is changed by collisions to a strongly allowed (ie, very short lifetime) exciplex
emission and gives rise to a very large but delayed emission effect. Believe me,
that problem is much more complicated than certitficate attribute lifetimes but
I solved it 17 years ago with the same method. You can check it at:

E. Gerck and E. Fill, "1.3 u m excimer emission with I(2p1/2)", Proc.  XII Int. Quantum Electron. Conf.-Munich, Appl. Phys. B, vol. B 28, p. 285, 1982.

E. Gerck and E. Fill, "Infrarot Fluoreszenz von Jod-Exzimeren" in Verhandlungen DPG (VI) 17, p. 448, Germany, 1982.

E. Gerck and E. Fill, "XeI excimer emission at 1.3 um", Opt. Lett, vol. 7, p. 25, 1982.

 E. Gerck, "Collisional enhancing of the I(2p ½) infrared emission by parent molecules CF3I, C2F5I, i-C3F7I and n-C3F7I", Opt. Commun., vol 4l, p. 102, 1982.

E. Gerck, "Quantenausbeute von 1(2p ½) von Jodlasermedien bei 308 und 248 nm", in Verhandlungen DPG (VI) 18, p. 438, Germany, 1983.

E. Gerck. "Spektral aufgeloeste Emission von I(2p ½) - Puffergas-Exziplexen bei 1,3um", in Verhandlungen DPG (VI) 18. p. 447, Germany, 1983.

E. Gerck, "Quantum yields of I(2p ½) for CF3I, C2F5I, i-C3F7I, n-C3F7I, n-C6F13I and 1,2-C2F4I2 at 308 nm and 248 nm", J. Chem. Phys., vol. 79, p. 311, 1983.


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02908 for ietf-pkix-bks; Tue, 18 May 1999 18:13:09 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02904 for <[e-mail]>; Tue, 18 May 1999 18:13:08 -0700 (PDT)
Received: from [128.33.238.79] (TC098.BBN.COM [128.33.238.98]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id VAA04008; Tue, 18 May 1999 21:13:01 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1285046039==_ma============"
Message-Id: <v04020a14b367c07b4947@[128.33.238.79]>
In-Reply-To: <03a901bea16b$cc52bea0$930aff0c@brick>
Date: Tue, 18 May 1999 21:13:52 -0400
To: "Todd S. Glassey - ELN" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fw: I-D ACTION:draft-ietf-pkix-bert1-00.txt
Cc: "IETF PKIX" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1285046039==_ma============
Content-Type: text/plain; charset="us-ascii"

Todd,

The attachments contained no text, other than

Content-Type: text/plain
Content-ID:	<[e-mail]>


and

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-bert1-00.txt


Presumably there is more to the proposal than that/

Steve
--============_-1285046039==_ma============
Content-Type: text/enriched; charset="us-ascii"

Todd,


The attachments contained no text, other than 


<fontfamily><param>Courier_New</param><bigger>Content-Type: text/plain

Content-ID:	<<[e-mail]>



</bigger></fontfamily>and


<fontfamily><param>Courier_New</param><bigger>Content-Type: text/plain

Content-ID:	<<[e-mail]>


ENCODING mime

FILE /internet-drafts/draft-ietf-pkix-bert1-00.txt



</bigger></fontfamily>Presumably there is more to the proposal than
that/


Steve

--============_-1285046039==_ma============--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02217 for ietf-pkix-bks; Tue, 18 May 1999 17:57:38 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02213 for <[e-mail]>; Tue, 18 May 1999 17:57:36 -0700 (PDT)
Received: from [128.33.238.79] (TC079.BBN.COM [128.33.238.79]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA03302; Tue, 18 May 1999 20:57:34 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a10b3678c719401@[128.89.0.111]>
In-Reply-To: <062001be9c81$5b8db380$930aff0c@brick>
References: <[e-mail]>
Date: Tue, 18 May 1999 17:34:40 -0400
To: "Todd S. Glassey - ELN" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-01.txt comments
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

>If you are trying to create a postal processing system, wherein you only see
>(or contact) the postal agent once a day, then the issue of the
>date/timestamp may be OK. But by the way, the actuality of when you deposit
>mail with the post office and when it is stamped is also a mystery in most
>instances, except to say, that the mail will be cancled when it is
>processed, and that is the time that it will have stamped on it. So in
>reality, unless the mail is hand canceled, what you get stamped on the mail,
>is the "when they got around to it" time which in most instance is within 24
>hrs of depositing the mail with "them".
>
>All in all, the 200+ year old postal process is changing and since
>Electronic Mail and Document Processing systems are moving into digital and
>operating 7x24 hrs and your comment doesn't seem to make sense to me in
>light of this.

The last time I sent a piece of certified mail, I received a printed
receipt from the postal clerk, generated by a PC, containing a time stamp,
the zip code of the destination, the post office ID, and the cost of the
postage.  Sounds a bit more high tech than what you describe, and this was
a limited service postal station in a small town.  certified mail, which is
an example of a postal service where time of sending is consider important,
has always involved direct interaction with a person, vs. dropping
something in a mailbox. i think your example, abovem, is a poor one, re the
context of our discussions.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02211 for ietf-pkix-bks; Tue, 18 May 1999 17:57:31 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02207 for <[e-mail]>; Tue, 18 May 1999 17:57:29 -0700 (PDT)
Received: from [128.33.238.79] (TC079.BBN.COM [128.33.238.79]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA03287; Tue, 18 May 1999 20:57:28 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a0fb36789b4ef82@[128.89.0.111]>
In-Reply-To: <01a101bea089$ae44c9e0$930aff0c@brick>
References: <000301bea010$a12526c0$[e-mail]>
Date: Tue, 18 May 1999 17:28:07 -0400
To: "Todd S. Glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Cc: "IETF PKIX" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

>1)    The Token Structures - lets come to standards for representing events
>before we define how you get access to the event representation mechanisms,
>because one without the other is what we have right now and it seems to be
>to be commercially speaking - of limited value at this time.n This would
>constitute a standard for representing events in space-time (we, Meridianus,
>call this GeoSpatial or GeoPositional Timestamping) and it should including
>recursive stamping to manage the "Chain of Custody" issues - See our new ID
>for details on this (it was filed this AM).

We're doing time stamping.  We are not necessarily adopting the time
stamping architecture of your current employer.  Since there are various
ways that a time stamp authority may establish its credentials, I don't
think we should assume the recursive structure you are proposing.  I'd like
to see a concise and focused characterization of the "chain of custody"
issues before we consider anything along those lines.  When I say "concise
and focused" I mean something with a lot more credibility than typical,
high level marketing text.


>2)   The API and distributed access services for validating the timestamps;
>that is some technically approved methods of using them - here then is where
>Z-C-A-P team's routines are given the once over by the Auditors, so the API
>spec is important and fits here. AFTER the TOKENS and their use models are
>defined though.

In general, the IETF does not standardize APIs.  I am not yet persuaded
that this is one of the rare occaisons where we should violate this general
rule.  Look at RFC 2459 (PKIX Part 1). We don't sp[ecify an API for cert
and CRL processing.  For exmaple, one may choose to employ CDSA as na API,
but that's not a requirement.

>3)   And maybe a standard Document Encapsulation Format for archiving
>(long-term document) storage and authentication.

This is almost certainly too general to be addressed by this PKIX work
item.  Different applications adopts different formats for documents.  We
have not IETF-wide standard for document representation.  Thus it seems
unlikely that we would create a standard format for archiving documents.  I
think the basic model here is that we time stamp a hash of something, and
return a token that can be used to validate the existance of the hashed
thing at some time in the future.  The format of the thing represented by
the hash is outside the scope of this work.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02182 for ietf-pkix-bks; Tue, 18 May 1999 17:56:05 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02177 for <[e-mail]>; Tue, 18 May 1999 17:56:04 -0700 (PDT)
Received: from [128.33.238.79] (TC079.BBN.COM [128.33.238.79]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA02982; Tue, 18 May 1999 20:55:56 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a03b36767dc4620@[128.89.0.111]>
In-Reply-To: <01BEA07B.F6E29AA0@HYDRA>
Date: Tue, 18 May 1999 14:59:33 -0400
To: Anders Rundgren <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: QC Interoperability     Was: Rename Qualified Certificates?
Cc: "[e-mail]" <[e-mail]>, "'SEIS-List'" 	 <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

The profile being discussed here addresses syntax for a specicial class of
certificates in the same way that RFC 2459 addresses syntax for a broader
class of X.509 certs.  None of the documents specifies how an application
will employ the raneg of data that can be represented in certs, especially
in light of the large number of optional extensions that are available.
Each application defines how certs are to be employed in the context of the
application.  S/MIME is doing this, as is IPsec.  The details of such
processing are the responsibility of the cognizant application WGs, not of
PKIX.

A valid question here is whether qualified certs need a single IETF WG to
represent them in this respect, or whether they will be used by several
different applications that the model described above for other
applications is still appropriate. My guess would be the latter.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02174 for ietf-pkix-bks; Tue, 18 May 1999 17:55:58 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02170 for <[e-mail]>; Tue, 18 May 1999 17:55:56 -0700 (PDT)
Received: from [128.33.238.79] (TC079.BBN.COM [128.33.238.79]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA02961; Tue, 18 May 1999 20:55:51 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04020a02b36765a8c1a3@[128.89.0.111]>
In-Reply-To: <[e-mail]>
Date: Tue, 18 May 1999 14:53:49 -0400
To: Hans Nilsson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SV: Rename Qualified Certificates?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hans,

I think the use of "qualified" here can be clarified adequately by
providing a pointer to the EU documents motivating this profile.  I think
that such language has been included, and thus don;t see this as a major
problem.  Also, changing the name of the document to "Qualified Identity
Certificate Profile" has been suggested, and that's fine with me too.  I'll
rely on Stefan to make sure appropriate langauge is contained in the
abstract of the I-D to minimize confusion.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21139 for ietf-pkix-bks; Tue, 18 May 1999 13:37:27 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA21135 for <[e-mail]>; Tue, 18 May 1999 13:37:26 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA11152 for <[e-mail]>; Tue, 18 May 1999 16:37:25 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA11148 for <[e-mail]>; Tue, 18 May 1999 16:37:24 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id QAA21484 for <[e-mail]>; Tue, 18 May 1999 16:37:31 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id QAA06964 for <[e-mail]>; Tue, 18 May 1999 16:35:35 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 18 May 1999 16:35:35 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Attribute certificate lifetimes: still way too much math
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: pSknnxvBJZbgU3MI7yINUA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: Ed Gerck <[e-mail]>
>
> REPLY:  Try equation (1) : "The inverse of the certificate lifetime is equal
> to the sum of the inverses of each effective attribute lifetime".

That is true as long as your assumption holds.  But if the assumption
does not hold, the equation fails.  Garbage in, garbage out.

For a counterexample, assume that a company has a policy of reassigning
its employees every three years.  A certificate might have the following
collection of attributes:

   eye color (lifetime = 72 years)
   department (lifetime = 3 years)
   telephone  (lifetime = 3 years)
   manager    (lifetime = 3 years)
   
Assume that everyone is happy at this company, so that turnover is very
low (<1%) and unexpected changes in assignment are rare.  I contend that
the expected lifetime of this certificate is closer to the minimum attribute
lifetime (3 years) than the value indicated by your formula
(1/3+1/3+1/3+1/72 = .986 years).

The probability that the phone number remains valid does not decay
exponentially with time, it remains nearly constant (perhaps decaying
slightly) for three years, at which point it falls abruptly to near zero.

You could argue that the three attributes above are correlated and should
be lumped together, but I could come up with a counterexample with three
non-correlated step-functions that would confound the use of a simple,
generally applicable formula.

The content of my message to Bob was 86% a failed attempt at humor, and
14% a general observation that correct statistical calculations (and I
agree that your math and his is correct) will not help if the model does
not fit the data.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20458 for ietf-pkix-bks; Tue, 18 May 1999 13:20:07 -0700 (PDT)
Received: from avocet.prod.itd.earthlink.net (avocet.prod.itd.earthlink.net [207.217.120.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20454 for <[e-mail]>; Tue, 18 May 1999 13:20:05 -0700 (PDT)
Received: from brick (dialup-209.245.137.67.SanJose1.Level3.net [209.245.137.67]) by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id NAA00248 for <[e-mail]>; Tue, 18 May 1999 13:20:03 -0700 (PDT)
Message-ID: <03a901bea16b$cc52bea0$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "IETF PKIX" <[e-mail]>
Subject: Fw: I-D ACTION:draft-ietf-pkix-bert1-00.txt
Date: Tue, 18 May 1999 13:19:55 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_03A6_01BEA131.1E9456A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_03A6_01BEA131.1E9456A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Friends,
this BERT draft is intended to create a consciousness that one of the more
valuable things we as a standards team can do is to create a suite of
specific "token structures" that other standards groups can use to represent
data elements and events within their transaction models.

BERT is intended to give us a  FSF/GNU-style token architecture that we can
all interoperate through with regard to document processing.

BERT then is more than it seems, it is an agreement between a number of key
market participants to make and create a timestamping marketplace. BERT is
both technical and political then, but lets address the technical side of
BERT here.

The ASN issue
----------------
Michael and I are fully aware that we will need to create an ASN variant of
the BERT and also to allow for several use-specific intentions. We have a
variant of this structure that would contain a document

For the first effort, we needed to provide a mechanism that can be used from
within existing legacy apps to add timestamping and nonrepudiation thereof
to. This meant that the timestamp token had to fit comfortably inside a
DBMS.

The key intent was to create the binary format for the timestamp so that it
could easily fit into existing database systems for authenticating OLTP
events and the like. Also, that by coupling this system with technologies
like Counterpane's mindset for secure logging, you would potentially have a
legally credible logging system for event processing.

This structure we are proposing for the BERT v1 was the best compromise when
we checked with the end users, but it can be changed as needed.

Todd



------=_NextPart_000_03A6_01BEA131.1E9456A0
Content-Type: application/octet-stream;
	name="ATT00524.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00524.dat"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-bert1-00.txt

------=_NextPart_000_03A6_01BEA131.1E9456A0
Content-Type: text/plain;
	name="draft-ietf-pkix-bert1-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-ietf-pkix-bert1-00.txt"

Content-Type: text/plain
Content-ID:	<[e-mail]>

------=_NextPart_000_03A6_01BEA131.1E9456A0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20280 for ietf-pkix-bks; Tue, 18 May 1999 13:12:33 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA20276 for <[e-mail]>; Tue, 18 May 1999 13:12:30 -0700 (PDT)
Received: 	id QAB13467; Tue, 18 May 1999 16:07:15 -0400
Received: by gateway id <LBQBDF27>; Tue, 18 May 1999 16:09:40 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: IETF PKIX <[e-mail]>, "'Todd S. Glassey'" <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Tue, 18 May 1999 16:09:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd;

As I have stated repeatedly, the purpose of standardizing time stamp
protocols within the PKIX working group is to help support non-repudiation
of digital signatures.  As we state in the document "to verify that a
digital signature was applied to a message before the corresponding
certificate was revoked thus allowing a revoked public key certificate to be
used for verifying signatures created prior to the time of revocation."
This is the publicly stated end-use model.

If we can easily add functionality that makes the protocol useful in other
environments, then we will.  However, that is not the goal.  Thus, much of
what you describe below seems to be a bit more elaborate that what is
required (given that CRLs only represent time with one second granularity).
But I haven't read your draft yet.

	Robert.

> ----------
> From: 	Todd S. Glassey[SMTP:[e-mail]]
> Sent: 	Monday, May 17, 1999 1:21 PM
> To: 	IETF PKIX
> Subject: 	Re: draft-ietf-pkix-time-stamp-01.txt comments ( Re:
> serialNumber )
> 
> All,
> I want to really de-rail this conversation before any issues on the
> precision or the type of timing infrastructure needed are decided without
> a
> publicly stated end-use model, since without this, we cannot erect any
> specific solution and the effort becomes, commercially speaking, IMHO, a
> waste of time.
> 
> To that end,  I suggest that we look at the legal and commercial
> requirements for timestamping *before* consuming anymore of PKIX's
> precious
> time here, because it really seems to me that what is needed here is a set
> of standards to represent:
> 
> 1)    The Token Structures - lets come to standards for representing
> events
> before we define how you get access to the event representation
> mechanisms,
> because one without the other is what we have right now and it seems to be
> to be commercially speaking - of limited value at this time.n This would
> constitute a standard for representing events in space-time (we,
> Meridianus,
> call this GeoSpatial or GeoPositional Timestamping) and it should
> including
> recursive stamping to manage the "Chain of Custody" issues - See our new
> ID
> for details on this (it was filed this AM).
> 
> 2)   The API and distributed access services for validating the
> timestamps;
> that is some technically approved methods of using them - here then is
> where
> Z-C-A-P team's routines are given the once over by the Auditors, so the
> API
> spec is important and fits here. AFTER the TOKENS and their use models are
> defined though.
> 
> 3)   And maybe a standard Document Encapsulation Format for archiving
> (long-term document) storage and authentication.
> 
> This last item, #3, is more important than people know now.  The issues
> going on in XML based document filing system and event management
> processed
> based thereon (see www.receipts.org for one example) are opening new
> opportunities for document processing and control systems. These provide
> mechanism for segmenting content and providing embedded parsing services
> to
> some extent, but they don't encapsulate or timestamp documents.
> 
> I suggest that we maybe in addition to the timestamp token standards, that
> we need a public domain/FSF style model that provides a framework for
> storing and validating a document. So to speak, a document harness, and
> that
> without this tool, that none of us are going to be able to build system
> (that we will get paid for), at least in the big picture.
> 
> Todd Glassey
> 
> --- SNIP ---
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18715 for ietf-pkix-bks; Tue, 18 May 1999 12:29:21 -0700 (PDT)
Received: from tomcat.sac.verio.net ([e-mail] [209.162.64.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18710 for <[e-mail]>; Tue, 18 May 1999 12:29:20 -0700 (PDT)
Received: from mcg.org.br (pm09-37.sac.verio.net [209.162.65.150]) by tomcat.sac.verio.net (8.9.1a/8.9.1) with ESMTP id MAA25807; Tue, 18 May 1999 12:29:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 18 May 1999 12:25:40 -0700
From: Ed Gerck <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
CC: "David P. Kemp" <[e-mail]>, Bob Blakley <[e-mail]>
Subject: General formula, was Re: Attribute certificate lifetimes: way too much  math, but getting closer to correct
References: <016c01bea087$750a7000$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All:

There was recent questioning on this list about the possible ways to
estimate certificate lifetime when attributes are included in the
certificate, not only the key.  There was also questioning whether
even discussing this subject might make sense, since the problem seems
to be so open-ended as to be indeterminate. I show that this is not so
and that the formula derived by Bob Blakley is indeed correct, even in
a much more general context than the one he used for its intuitive 
derivation. As a practical rule, I show that key lifetime should 
be at most 1/3 the shortest attribute's lifetime.

Since any certificate has attributes (e.g., the date it was issued,
the company name it was issued to, etc.) which may be invalid sooner 
(e.g., Y2K, misspelling, CA error) than the originally intended key 
lifetime, this discussion may be important to provide an upper bound 
for key lifetimes for any type of certificates. It will also clearly 
show that long-lived certificates should have a least number of 
attributes.

I report that certificate lifetime with M multiple attributes can be 
modeled in average behavior and without imposing attribute independence, 
by using an exponential decay formula for each effective attribute [1]. 
The number N of effective attributes can be larger than the number M of 
original multiple attributes in the certificate, which allows the 
representation of sub-attributes that are too significant to be ignored.

The mathematical basis for the attribute certificate lifetime model 
considered here is that any attribute will always present a monotonically
decreasing time function, which can be well-approximated by a linear 
first-degree differential equation -- as is well-known.

In the general result obtained [1], one can calculate the lifetime T of 
a certificate in terms of each effective attribute's a priori lifetime 
Tn by the simple formula:

1/T = 1/T1 + 1/T2 + 1/T3 + ...+ 1/TN             (1)

for "N" effective attributes, where the key is also one of the attributes. 
The M original attribute dependencies upon one another are directly 
reflected in the number N of effective attributes as well as in each a 
priori lifetime Tn in equation (1).

I further note that no other hypothesis was needed [1] to derive (1), such 
as those made by Bob Blakley in his derivation of a previous formula for 
the lifetime of an attribute certificate:

(i) attributes are independent,
(ii) attribute lifetimes have a continuous distribution and,
(iii) attribute n-1 does not expire before attribute n, for all 2<n<N.

However even though equation (1) lifts the three assumptions that were 
imposed by Bob Blakley, it yet achieves the same result in terms of the 
key-lifetime:

> And the expected lifetime of an attr. cert. is
>
>        Lk * (1 / (1+ SUM(i= 1..n) (Lk / Lai)))
>
>(all these presume the appropriate assumption about independence of
> attribute lifetimes).

as can be seen by inspection. The distinctions are that equation (1)
may consider a larger number of attributes than originally given in the 
certificate, and that in equation (1) all lifetimes play an equal formal 
role, while in Bob's formula the key-lifetime Lk is formally singled out.

However, I note further that there is no reason to distinguish between
the key and any other attribute in equation (1) or in Bob's formula 
because all attributes (including the key) belong to the same certificate
in both studies.  Equation (1) and Bob's formula are therefore formally 
equal -- the difference being only that equation (1) was derived without 
any restrictions from (i), (ii) and (iii).

Thus, equation (1) validates the former result by Bob and answers in the 
negative all David Kemp's doubts about its validity, which I express in the
list below.

DOUBT 1: Attribute certification is a murky situation which lifetime 
behavior cannot be proved or disproved because the a priori distributions 
are unknown, and in general, unknowable.
REPLY:  Lifetime a priori distributions for each attribute are indeed 
unknown but their time evolution is all that is required for equation (1),
which can be approximated by linear first-degree differential equations for 
each attribute [1]. This yields an exponential decay law for each attribute, 
which can be made as accurate as desired by dividing each attribute into 
sub-attributes and writing an additional differential equation for each one. 
This may increase the number of effective attributes than originally given,
but the formalism is not modified.

DOUBT 2: Conventional wisdom suggests that the mean attribute lifetime is
significantly shorter than the mean PK lifetime.
REPLY: This is irrelevant for the derivation of equation (1),  which 
represents certificate lifetime.

DOUBT 3: There is no conventional wisdom about the distribution of
attribute lifetimes, but one would venture that it is a discrete, not a
continuous distribution.  Therefore, one cannot say that  "with
probability 1, attribute 2 doesn't expire at t1".
REPLY: There are no such assumptions for equation (1).

DOUBT 4: Possibly, attributes within a single certificate will not have 
pairwise mutually independent lifetimes, so their lifetimes are more than 
likely correlated.
REPLY: There is no such assumption for equation (1). Each effective 
attribute's lifetime is estimated or measured a priori, implictly with any 
interdependency or correlation that may exist or one wishes to represent, 
and then inputted to equation (1) as a number that wholly represents such 
interactions.  The mathematical basis for this procedure is that any 
attribute will always have a monotonically decreasing validity function 
over time, which can be well-approximated by the solution of a linear 
first-degree differential equation with an adequate rate.

DOUBT 5: The question whether pairwise mutual independence is sufficient 
for Bob's formula to hold, or whether the stronger joint independence is 
required. 
REPLY: Since Bob's formula is formally equal to equation (1), and 
equation (1) actually holds for a model where attribute independence is
not an issue, this doubt does not apply.

DOUBT 6: The preconditions for Bob's formula to be correct cannot be
demonstrated.
REPPLY: This is true. However, Bob's preconditions as given by (i), (ii) 
and (iii) are not necessary and can be entirely abandoned [1], leading 
however to the same formula. 

;-) DOUBT 7: Therefore one may prefer Steve's formula "The effective 
lifetime of a certificate is inversely proportional to the square of the 
number of attributes", simply because it rolls trippingly off the tongue.
REPLY:  Try equation (1) : "The inverse of the certificate lifetime is equal
to the sum of the inverses of each effective attribute lifetime".


Next, I will use Bob's example but now with equation (1):

        eye color (lifetime = 72 years)
        department (lifetime = 1 quarter)
        telephone extension (lifetime = 2 years)
        manager (lifetime = 1 quarter)
        key-lifetime = 1 quarter

which yields a certificate lifetime of

1/T = 1/(72*4)  + 1/1 + 1/(2*4) + 1/1 + 1/1

so that T = 0.32 quarters or, 28.8 days. In other words, the certificate 
will be valid for less time (0.32 quarters) than what might be expected 
(and, controlled) by its key validity (1 quarter). 

This means that Bob's assertion:

 "The lesson here is that you have to make the key lifetime VERY short 
 compared to the shortest attribute lifetime in order to get the actual 
 lifetime of an attribute certificate close to its nominal lifetime"

is indeed correct, as shown by this example. However, Bob's assertion is 
correct also for any other lifetime ratios and examples. Such can be 
easily understood from equation (1).  Since all lifetimes play an equal 
role, I can affirm in the general case that: 

 "Certificate lifetime is always shorter than the shortest lifetime".

as can be seen from equation (1) by inspection.  Thus, if I want to control 
certificate lifetime by challenge-response with its key then indeed I have 
to make key-lifetime VERY short compared to the shortest attribute 
lifetime in the certificate. Then, certificate lifetime will still be 
shorter than key-lifetime but their difference will be closer to zero.

As a practical rule, key-lifetime Tk should be at most 1/3 the shortest 
attribute lifetime Ta, since for Tk = Ta/3 one has:

1/T = 1/Tk + 1/Ta + ...+ 1/TN =~ 1/Tk + 1/Ta => T =~ 0.75 * Tk


As a final remark, I note that two attributes with lifetime equal to the
key will reduce certificate lifetime to only 30% of the key lifetime. And, 
that three attributes that each have a lifetime equal to twice the key 
lifetime will nonetheless reduce certificate lifetime to 40% of the key 
lifetime. Thus, long-lived public-key certificates should have a least 
number of attributes -- a fact which denies the usefulness of overloading 
public-key certificates with data in an attempt to increase reliance (e.g.,
e-mail addresses fax numbers, phone numbers, etc.) unless the key lifetime
is properly much reduced or there is no key.  But, even for no key the least
number of attributes will again result in a much longer-lived certificate. 

Comments are welcome.


Cheers,

Ed Gerck


[1] Consider an ensemble of certificates, each with a given number M of 
attributes, with each attribute defined by a lifetime -- including
the key. This ensemble can include certificates that are issued at the
same time for different keyholders and certificates that are issued at
different times for the same keyholder. The ensemble is an analysis tool,
to be used in order to allow the calculation of average statistics based
on time averages, but note that the M attributes are not supposed to be 
independent from one another.

Note also that lifetime a priori distributions for each attribute are 
unknown but their time evolution is all that is required, which can be 
approximated by a linear first-degree differential equation for each 
attribute. This yields an exponential decay law for each attribute,  
which can be made as accurate as desired by dividing each attribute 
into sub-attributes and writing a linear first-order differential 
equation for each one. 

The justifications for the attribute certificate lifetime model 
considered here are thus:

(a) empirical: any observed lifetime for an attribute will necessarily
 subsume any dependencies from other attributes. If the observed time
 variation fits well an exponential decay law then the lifetime is 
 defined as the inverse of this exponential rate (as usual). Otherwise,
 the attribute will be divided into as many sub-attributes as needed to
 fit well different exponential rates (i.e., lifetimes). This is an 
 empirical/heuristic/theoretical modeling process that is a function
 of cost and risk. Leaving out sub-attributes that have fast dependencies
 can be risky since they can quickly decay to zero and yet be considered
 valid within a larger lifetime, but identifying them all can be costly 
 --  so, a compromise solution is necessary in the modeling phase
 (engineering specification of that particular certificate). This will
 lead to N effective attributes for the original M attributes, N >= M,
 each effective attribute with an effective lifetime -- these values
 are called "a priori lifetimes".

(b) mathematical: any attribute will always present a monotonically 
 decreasing validity function over time, which can be well-approximated
 by a linear first-degree differential equation with an adequate rate.


The above procedure will define a system of N attributes (including
the key) and the N a priori lifetimes. The original number M of 
certificate attributes may be smaller but this is irrelevant.

Loosely speaking, the ensemble represents the average experience for 
each effective attribute's lifetime when all attributes are considered 
together. Thus, the ensemble may combine empirical data, heuristics and 
also theoretical data in order to allow the observer to rely upon an 
effective lifetime value to each attribute -- the "a priori lifetimes". 
Note again that the M attributes are not supposed to be independent.

To build the system of N equations that will represent the time validity
function for each effective attribute, I write one normalized linear
first-order differential equation for each effective attribute n 
(including the key):

dAn/dt = - An/Tn , for n =1, ...N              (2)

where d/dt is time derivative (in continuous or discrete form), Tn is the 
effective attribute's a priori lifetime, and An is the attribute validity 
function at time t:

An = fraction of valid attributes n at time t, normalized to the ensemble.

The solution to equation (2) is:

An(t) = 1.0 * exp(-t/Tn)  , for n =1, ...N 

Now, define C to be the certificate validity function represented by the 
product of each individual validity solutions to equation (2), all 
with equal weights:

C = A1 * A2 * ... * AN = 1.0 * exp (-t/T1 - t/T2 - ... - t/TN)

and verify that C obeys equation (2) whith the standard solution:

C(t) = 1.0 * exp (-t/T)

if and only if the certificate lifetime T is given by

1/T = 1/T1 + 1/T2 + ... 1/TN.

This result is given in equation (1).

______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [e-mail]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18285 for ietf-pkix-bks; Tue, 18 May 1999 12:11:55 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA18281 for <[e-mail]>; Tue, 18 May 1999 12:11:53 -0700 (PDT)
Received: 	id PAA18902; Tue, 18 May 1999 15:07:37 -0400
Received: by gateway id <LBQBD162>; Tue, 18 May 1999 15:10:04 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Tue, 18 May 1999 15:09:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Agreed, this is a simple way to include multiple message imprints for those
applications that really must.  I therefore see no reason to include a
SEQUENCE OF MessageImprint within the time stamp request and tokens.

	Robert.

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Sunday, May 16, 1999 7:35 AM
> To: 	[e-mail]; [e-mail]
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> >My concern is that composite hashes do not scale:
> >
> >1. There are currently about 7 hash algorithms to play with (md2, md4,
> md5,
> >sha1, rimemd128, ripemd160, ripemd256). That implies 7 single oids, plus
> 7x6
> >combinations with two of them, plus 7x6x5 combinations of three, and so
> on. I
> >feel much more confortable with 7 oids rather than with such a
> collection.
> 
> Scalability of xWithY algorithms is always a problem.  Why not use an
> algorithm
> identifier instead of an OID?  OID = { ... }, parameters =
> SEQUENCE { hash_oid1, hash_oid2 }?  That way you introduce a single new
> OID,
> and can reuse all the existing OIDs for hash algorithms.
> 
> Peter.
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA17844 for ietf-pkix-bks; Tue, 18 May 1999 11:58:03 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA17840 for <[e-mail]>; Tue, 18 May 1999 11:58:01 -0700 (PDT)
Received: 	id OAA13472; Tue, 18 May 1999 14:54:33 -0400
Received: by gateway id <LBQBD1YK>; Tue, 18 May 1999 14:57:00 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Tue, 18 May 1999 14:56:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael;

As I said earlier, the place to solve the "who was first" argument is within
the TSTTime field, not with the serial number.  The serial number should be
used just for token identification, the same way certificate serial numbers
are used for certificate identification.

However, I have yet to see a convincing argument that we really need to
solve this problem (or a lot of support for solving it).  With the increased
resolution that we have provided for TSTTime, I don't think that this is a
concern.  For applications that require the answer to "who was first", they
should use a TSA with increased time resolution and which has specified
(within its policy) that it will never produce two timestamps containing the
same time.  However, not all applications will require this.  Remember, the
reason this draft exists is to support non-repudiation of digital
signatures, for which this is not an issue.

Therefore, I think we are okay the way things are.

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Sunday, May 16, 1999 10:54 PM
> To: 	'Peter Sylvester'; [e-mail]
> Subject: 	RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re:
> serialNumber )
> 
> 
> Peter,
> 
> you wrote:
> --------------------------------------------------------------
> >If SerialNumber is present one might be tempted to deduce that the time
> stamps are unique. BUT that is not the way to >interprete the presence of
> a
> SerialNumber
> 
> One should not start to think:
> 
> - I find serialnumber ==> I have unique time stamps
>   (The result is probably true, but why making the test at all?)
> 
> - I don't have serialnumber ==> Not unique time stamps
>   (This may simply be wrong, again, it depends on the service).
> 
> In order to decide which kind of service ou have, I guess, one needs to
> use
> a policy identifier, configuration knowledge, or
> whatever. You don't use a time stamping authority's signing certificate
> just
> because it looks nice (i.e. has the right
> extension)??
> ---------------------------------------------------------------
> 
> Precisely! This is a sort of ambiguity I am trying to remove by mandating
> the serialNumber. The SerialNumber is ALWAYS there, and the time stamps
> are
> ALWAYS unique. Does not it make the whole lot much easier?
> 
> 
> By the way, treating the serialNumber as a uniqueID will work, i.e. the
> serialNumber can be used as a uniqueID. But not in the opposite direction,
> as ID does not have to be incremental and monotonous.
> 
> Regards
> MichaelZ
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12160 for ietf-pkix-bks; Tue, 18 May 1999 08:58:03 -0700 (PDT)
Received: from champlain.gns.ca (router.gns.ca [209.47.49.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12156 for <[e-mail]>; Tue, 18 May 1999 08:57:57 -0700 (PDT)
Received: from localhost (tyson@localhost) by champlain.gns.ca (8.9.3/8.9.3) with ESMTP id LAA25340 for <[e-mail]>; Tue, 18 May 1999 11:59:18 -0400 (EDT)
Date: Tue, 18 May 1999 11:59:18 -0400 (EDT)
From: Tyson Macaulay <[e-mail]>
To: [e-mail]
Subject: Delta CRL size
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

We trying to do a little modeling between delta CRLs and OCSP/CRT
checking systems.

We have the Valicert responder running and can estimate and average the
OCSP and CRT response size to around 730 bytes per.

Has anyone got any data on what a range or size would be for a delta CRL?
Suppose the CRL lifetime was 4 hours and the delta granularity was... 10
minutes?  

Any ideas.  Any at all?

Thanks,

Tyson

--
Tyson Macaulay
Chief Technology Officer
General Network Services Inc.
email: [e-mail]
voice: 613 230.3980





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07621 for ietf-pkix-bks; Tue, 18 May 1999 06:46:33 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07612 for <[e-mail]>; Tue, 18 May 1999 06:46:22 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26083; Tue, 18 May 1999 06:45:55 -0700 (PDT)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA01974; Tue, 18 May 1999 09:45:52 -0400 (EDT)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id JAA06634; Tue, 18 May 1999 09:45:52 -0400 (EDT)
From: Anne Anderson - Sun Microsystems <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 18 May 1999 09:45:52 -0400 (EDT)
To: "Xiong Shao Jun" <[e-mail]>
CC: [e-mail]
Subject: Re: On key identifier
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14145.28294.74006.605265@saguaro>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Xiong Shao Jun writes:
 > I get sample data from rfc2459, Example D.1, which is a CA certificate,
 > and I think I should
 > do SHA-1 on the DER-encoded subjectPublicKey, according to the above
 > paragraph, but I
 > got a different result. My SHA-1 result is:
 > a1d443c9243cfa0587f8a99898ddefc4e7359888
 > 
 > Below is data from rfc2459:
....
 > 0608 30 1d           29: . SEQUENCE
 > 0610 06 03             3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
 >                               : 55 1d 0e
 > 0615 04 16           22: . . . . . OCTET STRING
 >                               : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95
 > aa d5 ff
 >                               : 1c 21 e4 22 75 d6

I get the same result you do.  I believe you are doing the correct
calculation, even if the INTEGER encapsulated in the key BIT STRING
is incorrectly encoded.

Anne
-- 
Anne H. Anderson  ECI#712-KC Email: [e-mail]
Sun Microsystems Laboratories   or: [e-mail]
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07410 for ietf-pkix-bks; Tue, 18 May 1999 06:35:38 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07406 for <[e-mail]>; Tue, 18 May 1999 06:35:37 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00880; Tue, 18 May 1999 09:35:04 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-bert1-00.txt
Date: Tue, 18 May 1999 09:35:02 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New 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		: Basic Event Representation Token v1
	Author(s)	: T. Glassey, M. McNeil
	Filename	: draft-ietf-pkix-bert1-00.txt
	Pages		: 38
	Date		: 17-May-99
	
More and more, standards agencies that use PKI technologies 
developed and promulgated through the efforts of the IETF have come 
to ask for a finite method of representing a discrete instant in 
time as a referable event. The present document establishes defined 
data structures for requesting a Basic Event Representation Token 
(BERT), after it has been issued by a Trusted Timebase provider.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-bert1-00.txt

Internet-Drafts are also 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-bert1-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-bert1-00.txt".
	
NOTE:	The mail server at ietf.org 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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-bert1-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-bert1-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA24741 for ietf-pkix-bks; Mon, 17 May 1999 19:11:14 -0700 (PDT)
Received: from www.eci.com.cn ([159.226.41.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA24722 for <[e-mail]>; Mon, 17 May 1999 19:11:09 -0700 (PDT)
Received: from eci.com.cn ([10.226.41.80]) by www.eci.com.cn (Netscape Messaging Server 3.5)  with ESMTP id 290 for <[e-mail]>; Tue, 18 May 1999 10:09:35 +0100
Message-ID: <[e-mail]>
Date: Tue, 18 May 1999 10:09:35 +0800
From: "gang cao" <[e-mail]>
X-Mailer: Mozilla 4.06 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: how to use CPS?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

When one request a certificate , he need know
The Certificate Policy .but when  a certificate user
 use a certificate and he does not know the Certificate
Policy ,  must he stop the program and go to the
URI where have the Certificate Policy to see the
Certificate Policy?

Reading through the RFC 2459 and RFC 2527 ,
i could not find how a certficate user use the
Certificate Policy.

thanks for any comment.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA19967 for ietf-pkix-bks; Mon, 17 May 1999 14:18:41 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19963 for <[e-mail]>; Mon, 17 May 1999 14:18:40 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id QAA29998; Mon, 17 May 1999 16:17:06 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id QAA01063; Mon, 17 May 1999 16:17:04 -0500 (CDT)
Message-ID: <002f01bea0aa$eebb7660$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Attributes within PK certs? [draft-ietf-pkix-ac509prof-00.txt]
Date: Mon, 17 May 1999 16:19:21 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01BEA081.05B313C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_002C_01BEA081.05B313C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Yosi,

For the record, I'm in complete agreement with Russ here.

I don't know of any reason why the X509v3 format couldn't
be used for certs with short lifetimes, or with no key, or both.  They
wouldn't
be "regular" certs, but that's the point.

--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom
-----Original Message-----
From: Russ Housley <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Monday, May 17, 1999 3:22 PM
Subject: Re: Attributes within PK certs? [draft-ietf-pkix-ac509prof-00.txt]


>There are many cases where attributes are short lived.  For example, a web
>server may grant access to a particular page only after a previous page is
>viewed.  This has nothing to do with the lifetime of the X.509 identity
>certificate, and there is no reason to duplicate the public key.
>
>Russ
>
>At 01:07 PM 5/16/99 +0300, [e-mail] wrote:
>>
>>
>>Hello,
>>
>>I have been reading this thread about AttributeCertificates and I can't
>>understand why the X509v3  can't serve for issuing short lived
>>certificates?
>>Why is it neccessary to define new format for AC which does not include a
>>public key, but just points to it?
>>
>>Best, Yosi Mass,
>>IBM Haifa Research Lab
>>
>>
>>
>>"Bob Blakley" <[e-mail]> on 05/15/99 01:29:09 AM
>>
>>Please respond to "Bob Blakley" <[e-mail]>
>>
>>To:   "Linn, John" <[e-mail]>, "Russ Housley"
>>      <[e-mail]>
>>cc:   [e-mail]
>>Subject:  Re: Attributes within PK certs?
>>      [draft-ietf-pkix-ac509prof-00.txt]
>>
>>
>>
>>
>>
>>Russ,
>>
>>>Steve Kent's Rule of Revocation: "The effective lifetime of a certificate
>>>is inversely proportional to the square of the number of attributes."
>>>
>>>I agree with Steve's rule.
>>
>>Steve's rule is actually not correct. The correct formula can actually be
>>easily demonstrated.
>>
>>Assume that a certificate has "n" attributes, all with pairwise mutually
>>independent lifetimes.
>>
>>Assume that the certificate's key's lifetime starts at t=0 and ends at t=E,
>>where E>0.
>>
>>Look at attribute number 1.  Its lifetime ends at t1.  This divides the
>>timeline into 2 pieces
>>(The interval from t=0 to t=t1, and the interval from t=t1 to t=E.)  On
>>average
>>each of these pieces will be the same length - that is, half the length of
>>the
>>interval from
>>t=0 to t=E.
>>
>>Now look at attribute number 2.  With probability 1, it doesn't expire
>>exactly
>>at t1.  Instead,
>>it expires at some other time t2.  This adds one more interval to the
>>timeline; it doesn't matter,
>>so let's say attribute 2 expires first.  This divides the timeline into
>>three
>>segments -
>>t=0 to t=t2, t=t2 to t=t1, and t=t1 to t=E.  On average, these three
>>segments
>>will have equal
>>lengths, each one-third of the length of the interval from t=0 to t=E.
>>
>>Continue the process; each new attribute results in exactly one more
>>segment,
>>and (assuming
>>independent lifetimes) all segments on average have equal length.  This
>>means
>>that
>>the real formula is
>>
>>    lifetime of cert with attributes = lifetime of cert without attributes
>>*
>>(1/n)
>>
>>    where n is the number of attributes with pairwise mutually independent
>>expiry intervals.
>>
>>Hence I propose Bob & Steve's (corrected) rule of attribute certificate
>>lifetimes:
>>
>>"The effective lifetime of a certificate is inversely proportional to the
>>number of attributes
>>in the certificate, if all attributes' lifetimes are pairwise mutually
>>independent."
>>
>>
>>--bob
>>
>>Bob Blakley ([e-mail])
>>Chief Scientist, Dascom
>>
>>
>>
>>
>
>

------=_NextPart_000_002C_01BEA081.05B313C0
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990517T211921Z
END:VCARD

------=_NextPart_000_002C_01BEA081.05B313C0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA18926 for ietf-pkix-bks; Mon, 17 May 1999 12:46:19 -0700 (PDT)
Received: from www.meridianus.com (209.249.223.21.has.no.reverse [209.249.223.21] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA18922 for <[e-mail]>; Mon, 17 May 1999 12:46:18 -0700 (PDT)
Received: from brick by www.meridianus.com (8.8.8+Sun/SMI-SVR4) id NAA01833; Mon, 17 May 1999 13:42:24 -0700 (PDT)
Message-ID: <01b201bea09d$e1ac2ee0$930aff0c@brick>
From: "TSG - Meridianus" <[e-mail]>
To: "IETF PKIX" <[e-mail]>
Subject: Timestamping: We have submitted a new token structure draft
Date: Mon, 17 May 1999 12:45:51 -0700
Organization: Meridianus Inc
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,
GMT submitted a new timestamping draft this A.M. with regard to creating a
suite of  "Event Representation" Token Structures and the API's to support
their use. We believe  that this is key to the furthering of the use of both
timestamping and its reliance on certified time.

To this end we wanted to tell you that you can find an interim copy of the
draft at http://www.gmtsw.com/ietf , until it propagates through the IETF's
publishing process.

We are already getting pretty positive responses on the structure and its
use models. So if you have any commentary on the concept, the token
structures, please let us know.

And yes we found the typo in the table on pg. 24, but it was already
submitted so we will address this on the next take on the -01- document,

Thanks for your time and consideration in this -
Todd Glassey



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17823 for ietf-pkix-bks; Mon, 17 May 1999 10:29:50 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17819 for <[e-mail]>; Mon, 17 May 1999 10:29:49 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA08911; Mon, 17 May 1999 10:25:47 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 17 May 1999 13:00:30 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Attributes within PK certs? [draft-ietf-pkix-ac509prof-00.txt]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There are many cases where attributes are short lived.  For example, a web
server may grant access to a particular page only after a previous page is
viewed.  This has nothing to do with the lifetime of the X.509 identity
certificate, and there is no reason to duplicate the public key.

Russ

At 01:07 PM 5/16/99 +0300, [e-mail] wrote:
>
>
>Hello,
>
>I have been reading this thread about AttributeCertificates and I can't
>understand why the X509v3  can't serve for issuing short lived
>certificates?
>Why is it neccessary to define new format for AC which does not include a
>public key, but just points to it?
>
>Best, Yosi Mass,
>IBM Haifa Research Lab
>
>
>
>"Bob Blakley" <[e-mail]> on 05/15/99 01:29:09 AM
>
>Please respond to "Bob Blakley" <[e-mail]>
>
>To:   "Linn, John" <[e-mail]>, "Russ Housley"
>      <[e-mail]>
>cc:   [e-mail]
>Subject:  Re: Attributes within PK certs?
>      [draft-ietf-pkix-ac509prof-00.txt]
>
>
>
>
>
>Russ,
>
>>Steve Kent's Rule of Revocation: "The effective lifetime of a certificate
>>is inversely proportional to the square of the number of attributes."
>>
>>I agree with Steve's rule.
>
>Steve's rule is actually not correct. The correct formula can actually be
>easily demonstrated.
>
>Assume that a certificate has "n" attributes, all with pairwise mutually
>independent lifetimes.
>
>Assume that the certificate's key's lifetime starts at t=0 and ends at t=E,
>where E>0.
>
>Look at attribute number 1.  Its lifetime ends at t1.  This divides the
>timeline into 2 pieces
>(The interval from t=0 to t=t1, and the interval from t=t1 to t=E.)  On
>average
>each of these pieces will be the same length - that is, half the length of
>the
>interval from
>t=0 to t=E.
>
>Now look at attribute number 2.  With probability 1, it doesn't expire
>exactly
>at t1.  Instead,
>it expires at some other time t2.  This adds one more interval to the
>timeline; it doesn't matter,
>so let's say attribute 2 expires first.  This divides the timeline into
>three
>segments -
>t=0 to t=t2, t=t2 to t=t1, and t=t1 to t=E.  On average, these three
>segments
>will have equal
>lengths, each one-third of the length of the interval from t=0 to t=E.
>
>Continue the process; each new attribute results in exactly one more
>segment,
>and (assuming
>independent lifetimes) all segments on average have equal length.  This
>means
>that
>the real formula is
>
>    lifetime of cert with attributes = lifetime of cert without attributes
>*
>(1/n)
>
>    where n is the number of attributes with pairwise mutually independent
>expiry intervals.
>
>Hence I propose Bob & Steve's (corrected) rule of attribute certificate
>lifetimes:
>
>"The effective lifetime of a certificate is inversely proportional to the
>number of attributes
>in the certificate, if all attributes' lifetimes are pairwise mutually
>independent."
>
>
>--bob
>
>Bob Blakley ([e-mail])
>Chief Scientist, Dascom
>
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17744 for ietf-pkix-bks; Mon, 17 May 1999 10:21:39 -0700 (PDT)
Received: from gmtsw.com (test.glassey.com [207.126.98.130] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA17740 for <[e-mail]>; Mon, 17 May 1999 10:21:38 -0700 (PDT)
Received: from brick by gmtsw.com (SMI-8.6/SMI-SVR4) id KAA27652; Mon, 17 May 1999 10:21:54 -0700
Message-ID: <01a101bea089$ae44c9e0$930aff0c@brick>
From: "Todd S. Glassey" <[e-mail]>
To: "IETF PKIX" <[e-mail]>
References: <000301bea010$a12526c0$[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Mon, 17 May 1999 10:21:14 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,
I want to really de-rail this conversation before any issues on the
precision or the type of timing infrastructure needed are decided without a
publicly stated end-use model, since without this, we cannot erect any
specific solution and the effort becomes, commercially speaking, IMHO, a
waste of time.

To that end,  I suggest that we look at the legal and commercial
requirements for timestamping *before* consuming anymore of PKIX's precious
time here, because it really seems to me that what is needed here is a set
of standards to represent:

1)    The Token Structures - lets come to standards for representing events
before we define how you get access to the event representation mechanisms,
because one without the other is what we have right now and it seems to be
to be commercially speaking - of limited value at this time.n This would
constitute a standard for representing events in space-time (we, Meridianus,
call this GeoSpatial or GeoPositional Timestamping) and it should including
recursive stamping to manage the "Chain of Custody" issues - See our new ID
for details on this (it was filed this AM).

2)   The API and distributed access services for validating the timestamps;
that is some technically approved methods of using them - here then is where
Z-C-A-P team's routines are given the once over by the Auditors, so the API
spec is important and fits here. AFTER the TOKENS and their use models are
defined though.

3)   And maybe a standard Document Encapsulation Format for archiving
(long-term document) storage and authentication.

This last item, #3, is more important than people know now.  The issues
going on in XML based document filing system and event management processed
based thereon (see www.receipts.org for one example) are opening new
opportunities for document processing and control systems. These provide
mechanism for segmenting content and providing embedded parsing services to
some extent, but they don't encapsulate or timestamp documents.

I suggest that we maybe in addition to the timestamp token standards, that
we need a public domain/FSF style model that provides a framework for
storing and validating a document. So to speak, a document harness, and that
without this tool, that none of us are going to be able to build system
(that we will get paid for), at least in the big picture.

Todd Glassey

--- SNIP ---



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA17538 for ietf-pkix-bks; Mon, 17 May 1999 10:04:52 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA17534 for <[e-mail]>; Mon, 17 May 1999 10:04:51 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id MAA29527; Mon, 17 May 1999 12:03:10 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id MAA00556; Mon, 17 May 1999 12:03:08 -0500 (CDT)
Message-ID: <016c01bea087$750a7000$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: Attribute certificate lifetimes: way too much math, but getting closer to correct
Date: Mon, 17 May 1999 12:05:25 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0169_01BEA05D.8C020D60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0169_01BEA05D.8C020D60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All

I'm forwarding (with permission) the following private correspondence with
Dave Kemp, for
the group's interest.

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

David,

>C'mon Bob, you've been working too hard.

Seems likely :)

>Steve's original formula is
>(I assume) based on the apocryphal formula for the time required for a
>committee of n members to reach agreement; a situation which cannot be
>proved or disproved because the a-priori distributions of the members'
>attitudes are unknown, and in general, unknowable.

An interesting basis for quantification of any sort....  By the way, I used to
espouse exactly the same formula (Steve & I seem to have come to it
independently).  Then I revised it in the WRONG direction (and even told
the revised incorrect version to Steve) and began saying that it was 2**n
rather than n**2.  But I have now seen the light....

>Attribute certification is a similarly murky situation.  John
>originally stipulated "overlapping CA and AA responsibilities and
>lifetimes", but conventional wisdom suggests that the mean attribute
>lifetime is significantly shorter than the mean PK lifetime.

Right, which is exactly the case I analyzed in my note...

>I doubt
>that there is any conventional wisdom about the distribution of
>attribute lifetimes, but I would venture that it is a discrete, not a
>continuous distribution.  Therefore, one cannot say that  "with
>probability 1, attribute 2 doesn't expire at t1".

I very much doubt that it's discrete, given the difficulty of synchronizing
clocks, even if it might be "theoretically discrete".

>I would also venture
>that attributes within a single certificate will not have pairwise
>mutually independent lifetimes - a single AA may have issued multiple
>attributes and their lifetimes are more than likely correlated.

Exactly!! Which is why I put the qualifier into the forumla.  For attributes
whose lifetimes are correlated, you have to either analyze the correlation,
or lump them as if they were a single compound attribute.

>And I
>question whether pairwise mutual independence is sufficient for
>your formula to hold, or whether the stronger joint independence is
>required.

Might be....

>In short, the preconditions for your formult to be correct cannot be
>demonstrated.  I therefore prefer Steve's formula, simply because it
>rolls trippingly off the tongue.

Rolls trippingly off the tongue, but is wrong even at the level of O-notation.
If you want the right "tripping" formula, it's inversely proportional to the
number
of attributes, not inversely proportional to the square.  As much as I wish it
were otherwise, having told lots of audiences myself that it was the
square....

>Like Mozart's opera which had too
>many notes, your formula has not enough syllables.

Another point lurks in here though.  And that has to do with relative
lifetimes of
keys and attributes, to which you've already referred.  If you know the
lifetime of
the key (let's call it Lk), and the lifetimes of each of the (presumed
independent)
attributes (call them La1, ..., Lan) then you can use a generalized version of
the
formula I gave earlier to calculate the lifetime of the cert:

The probability of any attribute expiring during the lifetime of the key is
given by
the ratio of their respective lifetimes, i.e.

        for attribute i, the expected number of times that it will expire
during the lifetime of the
        certificate is (Lk / Lai)

Then the average number of intervals which attribute expirations divide the
cert.
lifetime into is

        SUM(i = 1..n) (Lk / Lai)

Thus the probability of an attr. cert. being valid throughout its nominal
lifetime is

        1 / (1+ SUM(i= 1..n) (Lk / Lai))

(The "1 +" is the contribution of the key expiration itself; if there are no
additional attributes,
the probability will be 1; otherwise it will be lower).

And the expected lifetime of an attr. cert. is

        Lk * (1 / (1+ SUM(i= 1..n) (Lk / Lai)))

(all these presume the appropriate assumption about independence of attribute
lifetimes).

Note that this takes into account the fact that attributes may expire ANY
number of times,
including zero, during the lifetime of the cert.  It also reflects the
advantage you get by
making attr. cert. lifetimes short, and gives you a way to figure out how
short they must
be, given that you know something about the volatility of the attributes
you're certifying.

To take an example, if you issue a cert. whose key lifetime is 365 days, and
include in
it three attributes

        eye color (lifetime = 72 years)
        department (lifetime = 1 quarter)
        telephone extension (lifetime = 2 years)

Then you get

        365 * (1 / (1+ (1/72) + 4 + (1/2))) =
        365 * (1 / 5.576) =
        365 * 0.179 =
        65 days

As expected, the short-lifetime attribute dominates; if there were more than
one
short-lifetime attribute the effect would be much more pronounced:

        eye color (lifetime = 72 years)
        department (lifetime = 1 quarter)
        telephone extension (lifetime = 2 years)
        manager (lifetime = 1 quarter)

Gives

        365 * (1 / (1+ (1/72) + 4 + (1/2) + 4)) =
        365 * (1 / 9.576) =
        365 * 0.104 =
        38 days (10% of nominal)

Shortening the lifetime of the cert. to 1 quarter helps in percentage but not
absolute terms:

        90 * (1 / (1+ (1/288) + 1 + (1/8) + 1)) =
        90* (1 / 3.129) =
        90 * 0.320 =
        28 days (32% of nominal)

Shortening the lifetime to one month again increases percentage of lifetime
but not duration:

        30 * (1 / (1+ (1/864) + (1/3) + (1/24) + (1/3))) =
        30* (1 / 1.709) =
        30 * 0.585 =
        18 days (59% of nominal)

Shortening the lifetime to one DAY gives a pretty good percentage result:

        1* (1 / (1+ (1/26280) + (1/90) + (1/730) + (1/90))) =
        1* (1 / 1.023) =
        1* 0.978 =
        0.978 days (98% of nominal)

The lesson here is that you have to make the key lifetime VERY short compared
to the shortest
attribute lifetime in order to get the actual lifetime of an attr. cert. close
to its nominal lifetime.


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom

------=_NextPart_000_0169_01BEA05D.8C020D60
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990517T170525Z
END:VCARD

------=_NextPart_000_0169_01BEA05D.8C020D60--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA16010 for ietf-pkix-bks; Mon, 17 May 1999 06:44:24 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA16006 for <[e-mail]>; Mon, 17 May 1999 06:44:21 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id PAA19722 for <[e-mail]>; Mon, 17 May 1999 15:44:11 +0200
Received: from HYDRA ([195.198.186.72]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id PAA113378; Mon, 17 May 1999 15:44:05 +0200
Received: by HYDRA with Microsoft Mail id <01BEA07B.F6E29AA0@HYDRA>; Mon, 17 May 1999 15:43:09 +0200
Message-ID: <01BEA07B.F6E29AA0@HYDRA>
From: Anders Rundgren <[e-mail]>
To: Nick Pope <[e-mail]>, Hans Nilsson <[e-mail]>, Stephen Kent <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "'SEIS-List'" <[e-mail]>
Subject: QC Interoperability     Was: Rename Qualified Certificates?
Date: Mon, 17 May 1999 15:43:07 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,
I have a rather serious comment to a paragraph in your last posting:

>Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
>It's purpose is NOT to state any functional or other requirements. It's
>purpose is only to provide technical interoperability between "Qualified
>Certificates". E.g. so that the information put into an Italian "Qualified
>Certificate", can be displayed and understood by a German, English or
>American software.

The QC draft MAY support legal interoperability (whatever that mean) but
for TECHNICAL interoperability you have a long uncertain way to go.

You CAN  (for example) create a Java class that READS a QC-compatible certificate
but what is the enormous value of that if the INTERPRETATION of a variant set of attributes is
somewhere outside of the draft?  The reader is < 1% of the QC problem.

And the optional biometric part is not even possible to read using a generic class
as the mechanisms to access biometric template data is not specified in any detail.

And if you put an already variant file-format like a QC in another flexible container
like PKCS #15 you can be sure of ZERO interoperability.  I.e. you MAY be able to READ
QC data but you won't be able to ACT (using generic code) because you don't know the
semantics given a set of different QC manufacturers.

##############################################################
I.e. to achieve Interoperability (in the sense that end-users would know it) requires a
very strict profile with a FIXED set of attributes and interpretation.
##############################################################

Sorry for being pessimistic but 20++ year of SW development has taught me that
universal flexible formats (like EDI) requires a great deal of "adjustments" for every
actual implementation before the s.c. interoperability shows up :-). 

The solution? Either there is none or a MSFT-like thing will happen.  I.e. a market-leader
sets a de facto standard which may or may not adhere to the QC-draft.

Anders




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA12085 for ietf-pkix-bks; Mon, 17 May 1999 02:49:11 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA12081 for <[e-mail]>; Mon, 17 May 1999 02:49:06 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Mon, 17 May 1999 10:46:35 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 17 May 1999 10:45:43 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id KAA12658; Mon, 17 May 1999 10:46:26 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id KAA09257; Mon, 17 May 1999 10:46:24 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: [e-mail]
Cc: [e-mail], "'PKIX mailing group'" <[e-mail]>
Subject: Re: AC509prof-00. LACResponseMessage 
In-Reply-To: Your message of "Mon, 17 May 1999 19:05:26 +1000." <000d01bea044$69d9bc10$[e-mail]> 
MIME-Version: 1.0
Date: Mon, 17 May 1999 10:46:23 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Michael,

Given that the "L" in LACResponseMessage stands for limited,
and that the protocol is not intended to be yet another
competitor in the CMP/CMC space, I'm not sure that I agree
with supporting "grantedWithMods". For this to make sense
the requestor has to be able to check what the mods were
and whether its happy with the mods.

I'd guess that this makes the requestor as complex as a
CMC/CMP client, so why would it use the limited protocol?
(I assume that CMP and/or CMC will eventually be extended 
to handle ACs.)

Also, remember that LAAP is a strawman, perhaps this mail 
will kick off discussion as to whether such a protocol
is required or not (I believe it is, I know that some others
don't). If the consensus is that LAAP is useful, then we 
can sensibly discuss just how limited it should be.

Regards,
Stephen.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA11821 for ietf-pkix-bks; Mon, 17 May 1999 02:08:07 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA11817 for <[e-mail]>; Mon, 17 May 1999 02:08:05 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id TAA31808; Mon, 17 May 1999 19:08:24 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: <[e-mail]>
Cc: "'PKIX mailing group'" <[e-mail]>, "Kirrily Tompsett" <SECURITY/SDPL/[e-mail]>
Subject: Re: AC509prof-00. LACResponseMessage 
Date: Mon, 17 May 1999 19:05:26 +1000
Message-ID: <000d01bea044$69d9bc10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

LACResponseMessage is defined as

LACResponseMessage ::= CHOICE {
        ac        [0]  AttributeCertificate,
        errorInfo [1]  ErrorMsgContent -- from [CMP]
   }

1. CHOICE makes it impossible to communicate both the AC and non-critical
errors/warnings. grantedWithMods -do you think it will never be a case with
AC?  Should it be just a SEQUENCE?

2. Using ErrorMsgContent is probably not necessary. PKIStatusInfo [CMP] will
do just fine, and it can communicate both success and failure information.
The application should attempt parsing the AC data only after checking the
PKIStatusInfo ::PKIStatus first.

So, my proposal would be:

LACResponseMessage ::= SEQUENCE {
        errorInfo   PKIStatusInfo -- from [CMP],
        ac          AttributeCertificate OPTIONAL -- may not be present if a
critical error occurred
   }



Michael Zolotarev
Technical Architect, Baltimore Technologies Limited (Australia)



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA11352 for ietf-pkix-bks; Mon, 17 May 1999 01:00:50 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA11348 for <[e-mail]>; Mon, 17 May 1999 01:00:48 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id KAA04160; Mon, 17 May 1999 10:01:07 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 17 May 1999 10:00:42 +0200
To: "Nick Pope" <[e-mail]>, "Hans Nilsson" <[e-mail]>, "Stephen Kent" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Cc: <[e-mail]>
In-Reply-To: <000901be9f92$b45280e0$020aa8c0@nplaptop1>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA11349
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nick,

Thank you for sharing your thoughts, but I think you got i a little bit wrong.

But, on the other hand, it is this type of misunderstandings that makes me
think that maybe we should change the name anyway.

At 12:53 PM 5/16/99 +0100, Nick Pope wrote:
>Stefan,
>
>The problem with using the term qualified is that under the terms of the
>European Directive the certificate profile that is in the current
>internet-draft does NOT meet all the requirements for qualified certificates
>in Annex I.

What do you mean by this???

Do you mean that it is NOT possible to construct a Qualified Certificate
according to the directive, using the PKIX profile.

Please tell me in what sense!!!

The PKIX specification is a technical standard for interoperability. It's
purpose it so supply you with tools to understand the information stored in
such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE "QUALIFIED" OR
NOT. 

>
>Also, unless it is issued by a CA which also meets the annex II it cannot
>claim to meet the full requirements of qualified electronic signatures which
>are equivalent to hand-written signatures under clause 5.1 of the directive.
>

Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
It's purpose is NOT to state any functional or other requirements. It's
purpose is only to provide technical interoperability between "Qualified
Certificates". E.g. so that the information put into an Italian "Qualified
Certificate", can be displayed and understood by a German, English or
American software.

>Thus, using this term is very misleading when related to European
>legislation.

Yes, maybe you are right. 
Personally I don't think there is any conflict, but I sure can see the
misunderstandings coming. 

>
>I would support Hans Nilsson's recommendation of the term Identity
>Certificate.
>
>Nick Pope

Anything that we can get a consensus around will do for me. I still like
QCP better but maybe a straw poll is the only way to settle this.

As I see it, we have three candidates.

1- Qualified Certificates (no change)
2- QCP (short form for "Qualified Certificates" Profile.
3- Identity Certificates


Steve, can we make a straw poll on this or do you have any other opinion.

/Stefan

>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]On Behalf
>> Of Stefan Santesson
>> Sent: 14 May 1999 12:18
>> To: Russ Housley; Hans Nilsson; Stephen Kent
>> Cc: [e-mail]
>> Subject: Re: Rename Qualified Certificates?
>>
>>
>> Regaring name change of PKIX Qualified Certificates...
>>
>> I'm ready to give my proposal to a final solution to this.
>>
>> I propose that we throughout the specification define and use the
>> abbreviation QCP, standing for "Qualified Certificate Profile.
>>
>> This is the only reasonable solution I have found.
>>
>> The QCP is a PROFILE for certificates aimed to support digital signatures
>> that are considered functionally equivalent to handwritten signatures.
>>
>> There is only one term known to me that is used to denote such
>> certificate,
>> and that is the term "Qualified Certificate". So I don't want to lose the
>> close relation to that term.
>>
>> This is why I believe that QCP is a good "middle way". The "P" clarifies
>> that this is a technical profile and prevents mixups with any national
>> regulation or legal framework specifying functional requirements for
>> Qualified Certificates.
>>
>> But before I close this I would like to have Stephen Kent's opinion, since
>> this may effect the charter.
>>
>> /Stefan
>>
>> At 08:32 AM 5/7/99 -0400, Russ Housley wrote:
>> >I agree that the name should be changed; however, I really do
>> not like the
>> >one you have proposed.  "Identity certificates" is a commonly used term
>> >meaning that an identity is bound to a public key in a certificate.
>> >
>> >Perhaps a merging of the two terms is better: Qualified Identity
>> Certificates.
>> >
>> >Russ
>> >
>> >
>> >At 08:15 AM 5/7/99 +0200, Hans Nilsson wrote:
>> >>Yesterday I attended a meeting with the European Standards
>> Organization CEN,
>> >>where we now are trying to prepare the necessary standardization for
>> >>implementing the EU directive on Electronic Signatures. The
>> work in PKIX is
>> >>regarded as most relevant in this respect, and will be most
>> likely be used
>> >>and referenced a lot. This is also true for the current working draft on
>> >>Qualified Certificates, which is very much in line with the
>> requirements in
>> >>Annex I of the directive.
>> >>
>> >>However, the term Qualified Certiciates is already being used in the
>> >>Directive with a special meaning and definition ("a certifciate
>> that meets
>> >>the requirements laid down in Annex I and is provided by a certification
>> >>service provider that fulfills the requirements laid down in annex II").
>> >>
>> >>Although I am partly responsible for "hijacking" the term QC from the
>> >>directive and using it for our work, I now realise that this
>> was not a very
>> >>good decision, since the EU term also requires that the CA
>> fulfils Annex II.
>> >>We thus two honomyms that mean two different things.
>> >>
>> >>I would therefore like to propose that the PKIX term is changed
>> to something
>> >>else, and possibly more descriptive. My suggestion is "identity
>> >>certificates", but there may be other good suggestions.
>> >>
>> >>Regards
>> >>
>> >>Hans Nilsson
>> >>iD2 Technologies
>> >>
>>
>> -------------------------------------------------------------------
>> Stefan Santesson                <[e-mail]>
>> Accurata Systemsäkerhet AB      http://www.accurata.se
>> Slagthuset                      Tel. [phone]
>> 211 20  Malmö                   Fax. [phone]
>> Sweden                        Mobile [phone]
>>
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>>

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA03366 for ietf-pkix-bks; Sun, 16 May 1999 19:57:12 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA03350 for <[e-mail]>; Sun, 16 May 1999 19:57:08 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id MAA25580; Mon, 17 May 1999 12:57:46 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Mon, 17 May 1999 12:54:44 +1000
Message-ID: <000301bea010$a12526c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

you wrote:
--------------------------------------------------------------
>If SerialNumber is present one might be tempted to deduce that the time
stamps are unique. BUT that is not the way to >interprete the presence of a
SerialNumber

One should not start to think:

- I find serialnumber ==> I have unique time stamps
  (The result is probably true, but why making the test at all?)

- I don't have serialnumber ==> Not unique time stamps
  (This may simply be wrong, again, it depends on the service).

In order to decide which kind of service ou have, I guess, one needs to use
a policy identifier, configuration knowledge, or
whatever. You don't use a time stamping authority's signing certificate just
because it looks nice (i.e. has the right
extension)??
---------------------------------------------------------------

Precisely! This is a sort of ambiguity I am trying to remove by mandating
the serialNumber. The SerialNumber is ALWAYS there, and the time stamps are
ALWAYS unique. Does not it make the whole lot much easier?


By the way, treating the serialNumber as a uniqueID will work, i.e. the
serialNumber can be used as a uniqueID. But not in the opposite direction,
as ID does not have to be incremental and monotonous.

Regards
MichaelZ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA19737 for ietf-pkix-bks; Sun, 16 May 1999 04:53:57 -0700 (PDT)
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA19731 for <[e-mail]>; Sun, 16 May 1999 04:53:45 -0700 (PDT)
Received: from [158.152.35.12] (helo=nplaptop1) by finch-post-12.mail.demon.net with smtp (Exim 2.12 #1) id 10izU3-000MDu-0C; Sun, 16 May 1999 11:53:31 +0000
From: "Nick Pope" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>, "Hans Nilsson" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Rename Qualified Certificates?
Date: Sun, 16 May 1999 12:53:24 +0100
Message-ID: <000901be9f92$b45280e0$020aa8c0@nplaptop1>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

The problem with using the term qualified is that under the terms of the
European Directive the certificate profile that is in the current
internet-draft does NOT meet all the requirements for qualified certificates
in Annex I.

Also, unless it is issued by a CA which also meets the annex II it cannot
claim to meet the full requirements of qualified electronic signatures which
are equivalent to hand-written signatures under clause 5.1 of the directive.

Thus, using this term is very misleading when related to European
legislation.

I would support Hans Nilsson's recommendation of the term Identity
Certificate.

Nick


Nick Pope

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf
> Of Stefan Santesson
> Sent: 14 May 1999 12:18
> To: Russ Housley; Hans Nilsson; Stephen Kent
> Cc: [e-mail]
> Subject: Re: Rename Qualified Certificates?
>
>
> Regaring name change of PKIX Qualified Certificates...
>
> I'm ready to give my proposal to a final solution to this.
>
> I propose that we throughout the specification define and use the
> abbreviation QCP, standing for "Qualified Certificate Profile.
>
> This is the only reasonable solution I have found.
>
> The QCP is a PROFILE for certificates aimed to support digital signatures
> that are considered functionally equivalent to handwritten signatures.
>
> There is only one term known to me that is used to denote such
> certificate,
> and that is the term "Qualified Certificate". So I don't want to lose the
> close relation to that term.
>
> This is why I believe that QCP is a good "middle way". The "P" clarifies
> that this is a technical profile and prevents mixups with any national
> regulation or legal framework specifying functional requirements for
> Qualified Certificates.
>
> But before I close this I would like to have Stephen Kent's opinion, since
> this may effect the charter.
>
> /Stefan
>
> At 08:32 AM 5/7/99 -0400, Russ Housley wrote:
> >I agree that the name should be changed; however, I really do
> not like the
> >one you have proposed.  "Identity certificates" is a commonly used term
> >meaning that an identity is bound to a public key in a certificate.
> >
> >Perhaps a merging of the two terms is better: Qualified Identity
> Certificates.
> >
> >Russ
> >
> >
> >At 08:15 AM 5/7/99 +0200, Hans Nilsson wrote:
> >>Yesterday I attended a meeting with the European Standards
> Organization CEN,
> >>where we now are trying to prepare the necessary standardization for
> >>implementing the EU directive on Electronic Signatures. The
> work in PKIX is
> >>regarded as most relevant in this respect, and will be most
> likely be used
> >>and referenced a lot. This is also true for the current working draft on
> >>Qualified Certificates, which is very much in line with the
> requirements in
> >>Annex I of the directive.
> >>
> >>However, the term Qualified Certiciates is already being used in the
> >>Directive with a special meaning and definition ("a certifciate
> that meets
> >>the requirements laid down in Annex I and is provided by a certification
> >>service provider that fulfills the requirements laid down in annex II").
> >>
> >>Although I am partly responsible for "hijacking" the term QC from the
> >>directive and using it for our work, I now realise that this
> was not a very
> >>good decision, since the EU term also requires that the CA
> fulfils Annex II.
> >>We thus two honomyms that mean two different things.
> >>
> >>I would therefore like to propose that the PKIX term is changed
> to something
> >>else, and possibly more descriptive. My suggestion is "identity
> >>certificates", but there may be other good suggestions.
> >>
> >>Regards
> >>
> >>Hans Nilsson
> >>iD2 Technologies
> >>
>
> -------------------------------------------------------------------
> Stefan Santesson                <[e-mail]>
> Accurata Systemsäkerhet AB      http://www.accurata.se
> Slagthuset                      Tel. [phone]
> 211 20  Malmö                   Fax. [phone]
> Sweden                        Mobile [phone]
>
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA17722 for ietf-pkix-bks; Sun, 16 May 1999 03:08:47 -0700 (PDT)
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA17718 for <[e-mail]>; Sun, 16 May 1999 03:08:43 -0700 (PDT)
From: [e-mail]
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA20674; Sun, 16 May 1999 12:07:42 +0200
Received: from d12mta02.de.ibm.com (d12mta01 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.7m1/NCO v1.8) with SMTP id MAA63374; Sun, 16 May 1999 12:07:52 +0200
Received: by d12mta02.de.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id C1256773.0037A333 ; Sun, 16 May 1999 12:07:42 +0200
X-Lotus-FromDomain: IBMIL@IBMDE
To: "Bob Blakley" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 16 May 1999 13:07:23 +0300
Subject: Re: Attributes within PK certs? [draft-ietf-pkix-ac509prof-00.txt]
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=5tk7GAoiwaUzXnNyX24JkUvR8ab4DMo04SYRj1aOLPGB4MSKBoL0vs3V"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--0__=5tk7GAoiwaUzXnNyX24JkUvR8ab4DMo04SYRj1aOLPGB4MSKBoL0vs3V
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hello,

I have been reading this thread about AttributeCertificates and I can't
understand why the X509v3  can't serve for issuing short lived
certificates?
Why is it neccessary to define new format for AC which does not include a
public key, but just points to it?

Best, Yosi Mass,
IBM Haifa Research Lab



"Bob Blakley" <[e-mail]> on 05/15/99 01:29:09 AM

Please respond to "Bob Blakley" <[e-mail]>

To:   "Linn, John" <[e-mail]>, "Russ Housley"
      <[e-mail]>
cc:   [e-mail]
Subject:  Re: Attributes within PK certs?
      [draft-ietf-pkix-ac509prof-00.txt]





Russ,

>Steve Kent's Rule of Revocation: "The effective lifetime of a certificate
>is inversely proportional to the square of the number of attributes."
>
>I agree with Steve's rule.

Steve's rule is actually not correct. The correct formula can actually be
easily demonstrated.

Assume that a certificate has "n" attributes, all with pairwise mutually
independent lifetimes.

Assume that the certificate's key's lifetime starts at t=0 and ends at t=E,
where E>0.

Look at attribute number 1.  Its lifetime ends at t1.  This divides the
timeline into 2 pieces
(The interval from t=0 to t=t1, and the interval from t=t1 to t=E.)  On
average
each of these pieces will be the same length - that is, half the length of
the
interval from
t=0 to t=E.

Now look at attribute number 2.  With probability 1, it doesn't expire
exactly
at t1.  Instead,
it expires at some other time t2.  This adds one more interval to the
timeline; it doesn't matter,
so let's say attribute 2 expires first.  This divides the timeline into
three
segments -
t=0 to t=t2, t=t2 to t=t1, and t=t1 to t=E.  On average, these three
segments
will have equal
lengths, each one-third of the length of the interval from t=0 to t=E.

Continue the process; each new attribute results in exactly one more
segment,
and (assuming
independent lifetimes) all segments on average have equal length.  This
means
that
the real formula is

    lifetime of cert with attributes = lifetime of cert without attributes
*
(1/n)

    where n is the number of attributes with pairwise mutually independent
expiry intervals.

Hence I propose Bob & Steve's (corrected) rule of attribute certificate
lifetimes:

"The effective lifetime of a certificate is inversely proportional to the
number of attributes
in the certificate, if all attributes' lifetimes are pairwise mutually
independent."


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom




--0__=5tk7GAoiwaUzXnNyX24JkUvR8ab4DMo04SYRj1aOLPGB4MSKBoL0vs3V
Content-type: application/octet-stream; 
	name="Bob Blakley.vcf"
Content-Disposition: attachment; filename="Bob Blakley.vcf"
Content-transfer-encoding: base64

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkJsYWtsZXk7Qm9iDQpGTjpCb2IgQmxha2xleQ0K
T1JHOkRhc2NvbQ0KVElUTEU6Q2hpZWYgU2NpZW50aXN0DQpURUw7V09SSztWT0lDRTorMSAoNTEy
KSA0NTgtNDAzNyB4IDUwMTINClRFTDtXT1JLO0ZBWDorMSAoNTEyKSA0NTgtMjM3Nw0KQURSO1dP
Uks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo7O1BsYXphIEJhbGNvbmVzPTBEPTBBNTUxNSBC
YWxjb25lcyBEcml2ZTtBdXN0aW47VFg7Nzg3MzE7VVNBDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFV
T1RFRC1QUklOVEFCTEU6UGxhemEgQmFsY29uZXM9MEQ9MEE1NTE1IEJhbGNvbmVzIERyaXZlPTBE
PTBBQXVzdGluLCBUWCA3ODczMT0wRD0wQVVTQQ0KVVJMOg0KVVJMOmh0dHA6Ly93d3cuZGFzY29t
LmNvbQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDpibGFrbGV5QGRhc2NvbS5jb20NClJFVjoxOTk5MDUx
NFQyMjI5MDlaDQpFTkQ6VkNBUkQNCg==

--0__=5tk7GAoiwaUzXnNyX24JkUvR8ab4DMo04SYRj1aOLPGB4MSKBoL0vs3V--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA16310 for ietf-pkix-bks; Sat, 15 May 1999 16:44:23 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA16306 for <[e-mail]>; Sat, 15 May 1999 16:44:20 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id LAA25153; Sun, 16 May 1999 11:43:58 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92681183701854>; Sun, 16 May 1999 11:43:57 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: On key identifier
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 16 May 1999 11:43:57 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>Hi, folks. I'm working on a PKIX project. A few days ago, when I run a test on
>key identifier, I encounter a problem. In rfc 2459 section 4.2.1.2, as to key
>identifier, it says:
>
>(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value of
>the BIT STRING subjectPublicKey (excluding the tag,  length, and number of
>unused bits).

That's only the PKIX recommendation, in practice people are putting pretty much
anything in there, ranging from a single byte up to the full SHA-1 (or at least
some 20-byte value) hash of some part of the key or something else.

>I get sample data from rfc2459, Example D.1, which is a CA certificate, and I
>think I should do SHA-1 on the DER-encoded subjectPublicKey, according to the
>above paragraph, but I got a different result. My SHA-1 result is:
>a1d443c9243cfa0587f8a99898ddefc4e7359888

This would only matter if the key ID's were implicit (in which case you'd have
to ensure that the value you calculate corresponds exactly to the value someone
else would calculate).  Since they're explicit, it doesn't really matter if you
don't get it exactly right, as long as it's unique for each key.

Peter.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA16254 for ietf-pkix-bks; Sat, 15 May 1999 16:35:43 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA16249 for <[e-mail]>; Sat, 15 May 1999 16:35:40 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id LAA25240; Sun, 16 May 1999 11:35:24 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <92681132401531>; Sun, 16 May 1999 11:35:24 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 16 May 1999 11:35:24 (NZST)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>My concern is that composite hashes do not scale:
>
>1. There are currently about 7 hash algorithms to play with (md2, md4, md5,
>sha1, rimemd128, ripemd160, ripemd256). That implies 7 single oids, plus 7x6
>combinations with two of them, plus 7x6x5 combinations of three, and so on. I
>feel much more confortable with 7 oids rather than with such a collection.

Scalability of xWithY algorithms is always a problem.  Why not use an algorithm
identifier instead of an OID?  OID = { ... }, parameters =
SEQUENCE { hash_oid1, hash_oid2 }?  That way you introduce a single new OID,
and can reuse all the existing OIDs for hash algorithms.

Peter.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA02101 for ietf-pkix-bks; Fri, 14 May 1999 22:37:50 -0700 (PDT)
Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA02097 for <[e-mail]>; Fri, 14 May 1999 22:37:48 -0700 (PDT)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.1960.3) id <K2GZTS4J>; Sat, 15 May 1999 07:36:47 +0200
Message-ID: <[e-mail]>
From: Hans Nilsson <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: SV: Rename Qualified Certificates?
Date: Sat, 15 May 1999 07:36:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Since you sound as if you want to close this issue, I would like to repeat
my initial objection to the name, and also to the new Qualified Certificate
Profile. In my dictionary, qualified is defined as follows:

1.	To describe by enumerating the characteristics or qualities of;
characterize.
2.	To make competent or eligible for an office, a position, or a task.
3.	a. To declare competent or capable; certify. b. To make legally
capable; license.
4.	To modify, limit, or restrict, as by giving exceptions.

So the word signifies that a certificate has been limited or restricted in
some way. But it does not say why or for what purpose. If the reader has not
also read the EU Directive on Electronic Signatures (and most people have
not), he has no idea what qualified means in this context.

I have two alternative proposals:

- Identity certificate (profile): This is after all what the specification
is mostly about
- Signature certificate (profile): This is what the certificate is primarily
to be used for (because for signatures you need an unmistakable identity)

I also would like to hear Steve's opinion on this. Maybe we can make a
strawpoll (although it pollutes the list even more than this discussion :-)

Hans Nilsson



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08168 for ietf-pkix-bks; Fri, 14 May 1999 15:26:09 -0700 (PDT)
Received: from honcho.austin.dascom.com (email.austin.dascom.com [206.196.73.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08164 for <[e-mail]>; Fri, 14 May 1999 15:26:08 -0700 (PDT)
Received: from austin.dascom.com by honcho.austin.dascom.com (8.8.8/SMI-SVR4) id RAA25164; Fri, 14 May 1999 17:26:59 -0500 (CDT)
Received: from shaggy by austin.dascom.com (8.8.8/SMI-SVR4) id RAA25103; Fri, 14 May 1999 17:26:58 -0500 (CDT)
Message-ID: <021a01be9e59$2fa56900$[e-mail]>
Reply-To: "Bob Blakley" <[e-mail]>
From: "Bob Blakley" <[e-mail]>
To: "Linn, John" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Attributes within PK certs? [draft-ietf-pkix-ac509prof-00.txt]
Date: Fri, 14 May 1999 17:29:09 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0217_01BE9E2F.46CF6100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0217_01BE9E2F.46CF6100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Russ,

>Steve Kent's Rule of Revocation: "The effective lifetime of a certificate
>is inversely proportional to the square of the number of attributes."
>
>I agree with Steve's rule.

Steve's rule is actually not correct. The correct formula can actually be
easily demonstrated.

Assume that a certificate has "n" attributes, all with pairwise mutually
independent lifetimes.

Assume that the certificate's key's lifetime starts at t=0 and ends at t=E,
where E>0.

Look at attribute number 1.  Its lifetime ends at t1.  This divides the
timeline into 2 pieces
(The interval from t=0 to t=t1, and the interval from t=t1 to t=E.)  On
average
each of these pieces will be the same length - that is, half the length of the
interval from
t=0 to t=E.

Now look at attribute number 2.  With probability 1, it doesn't expire exactly
at t1.  Instead,
it expires at some other time t2.  This adds one more interval to the
timeline; it doesn't matter,
so let's say attribute 2 expires first.  This divides the timeline into three
segments -
t=0 to t=t2, t=t2 to t=t1, and t=t1 to t=E.  On average, these three segments
will have equal
lengths, each one-third of the length of the interval from t=0 to t=E.

Continue the process; each new attribute results in exactly one more segment,
and (assuming
independent lifetimes) all segments on average have equal length.  This means
that
the real formula is

    lifetime of cert with attributes = lifetime of cert without attributes *
(1/n)

    where n is the number of attributes with pairwise mutually independent
expiry intervals.

Hence I propose Bob & Steve's (corrected) rule of attribute certificate
lifetimes:

"The effective lifetime of a certificate is inversely proportional to the
number of attributes
in the certificate, if all attributes' lifetimes are pairwise mutually
independent."


--bob

Bob Blakley ([e-mail])
Chief Scientist, Dascom



------=_NextPart_000_0217_01BE9E2F.46CF6100
Content-Type: text/x-vcard;
	name="Bob Blakley.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Bob Blakley.vcf"

BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:[phone] x 5012
TEL;WORK;FAX:[phone]
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Plaza Balcones=3D0D=3D0A5515 =
Balcones Drive=3D0D=3D0AAustin, TX 78731=3D0D=3D0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:[e-mail]
REV:19990514T222909Z
END:VCARD

------=_NextPart_000_0217_01BE9E2F.46CF6100--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA06984 for ietf-pkix-bks; Fri, 14 May 1999 12:48:04 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06980 for <[e-mail]>; Fri, 14 May 1999 12:48:02 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id VAA25878 for <[e-mail]>; Fri, 14 May 1999 21:50:54 +0200
Received: from mega (t1o69p104.telia.com [62.20.144.104]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id VAA52318; Fri, 14 May 1999 21:50:51 +0200
Message-ID: <002d01be9e4b$2bc26ad0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "'Sam Schaen'" <[e-mail]>
Cc: "Linn, John" <[e-mail]>, <[e-mail]>
Subject: Re: Attributes within PK certs?[draft-ietf-pkix-ac509prof-00.txt]
Date: Fri, 14 May 1999 21:48:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA06981
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,
comments in line,

>> I have seen at least one vendor's product that espouses very short
>> validity periods for attribute certificates (e.g., 1 hour or 1 day). 
>> Short enough that one is willing to accept the risk that the information
>> in the certificate has changed without resorting to a certificate
>> revocation process.

>This remarkable invention should be better investigated
>by PKIX using applications.  It confounds Steve's
>Rule of Revocation, and addresses Internet needs
>at the same time. 

An example of this "remarkable invention" can be studied at [http://www.mobilephones-tng.com/v100/dynamiccerts.html ]

If we are talking about on-line operations there is money to save and security
can be completely acceptable for commercial use as the attribute
certificate is typically just a few seconds old when it is used by the relying
party.

For off-line (e-mail) use, such a dynamic system may add time-stamping
as well as you could send a signed mail as an "authorized" person but could
also have lost some power [ :-( ] when the receiver opens the mail a week later.
The letter would in most cases still be regarded as valid.


<snip>

Regards
Anders Rundgren




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA06384 for ietf-pkix-bks; Fri, 14 May 1999 11:28:57 -0700 (PDT)
Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA06380 for <[e-mail]>; Fri, 14 May 1999 11:28:55 -0700 (PDT)
Received: from brick (dialup-209.245.134.2.SanJose1.Level3.net [209.245.134.2]) by hawk.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id LAA13474; Fri, 14 May 1999 11:31:42 -0700 (PDT)
Message-ID: <009e01be9e37$fe776520$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Fri, 14 May 1999 08:36:50 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: Peter Sylvester <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Friday, May 14, 1999 1:58 AM
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )


> >
> > The unique monotonic etc serialNumber is critical when you have to
resolve
> > 'who was the first' argument between two stamps, having the same time
value.
> > This may well happen if the resolution of the clock is relatively low,
and
> > two requests entered the TS server virtually simultaneously. Think about
> > on-line betting, auctions, etc.
> This is right if you want service

I don't think that this is a real-world example.

What this example pre-supposes is that the point of legal contact with the
auction process is distributed or is part of a distributed auction event
processing systems where there are multiple servers all operating on the
same event pool.

This will as likely as not, NEVER happen commercially. With bandwidth and
heavy iron and clustering/SSI being what it is why would anyone try to erect
such a costly system to use.

This is exactly why I have been ranting about the use models for the time
stamping system.

>
> >
> > Defining serialNumber OPTIONAL will make it very confusing for a client
who
> > relies on the sequence as well as on the time itself.
> No, because the authority has defined their service in advance.
> if the authority defines a service that guarantees strict sequencing,
> then this is known in advance.
>
> >
> > And I would be deadly scared of seeing something like "if more than one
time
> > stamp are generated with the same time value, then TSA MUST include
> > serialNumber into the TSTInfo. Otherwise, the field may not be present
...".

This is a problem that will get larger as faster and faster machines are
created. At somepoint, the timebase resolution of the stamp may not be
sufficiently large enough to deal with the speed at which two or more
transactions vie for the queue. And as to two times created by the same
server with the same timestamp, that sounds impossible to me since they
would be served by the same event processing infrastructure so they couldn't
have the same time... unless the time values are represented by too small a
field...

> Me, too. but probably not for the same reasons.
>
> If SerialNumber is present one might be tempted to deduce that the time
> stamps are unique. BUT that is not the way to interprete the
> presence of a SerialNumber
>
> The authority first defines that it provides a certain service,
> and THEN it uses a certain technology. Whatever you find in the stamp,
> it does'nt matter. if the authority considers never to deliver more than
> 4.000.000.000 time stamps per second, you may not need a sequence number.
>
> One should not start to think:
>
> - I find serialnumber ==> I have unique time stamps
>   (The result is probably true, but why making the test at all?)
>
> - I don't have serialnumber ==> Not unique time stamps
>   (This may simply be wrong, again, it depends on the service).
>
> In order to decide which kind of service ou have, I guess, one
> needs to use a policy identifier, configuration knowledge, or
> whatever. You don't use a time stamping authority's signing
> certificate just because it looks nice (i.e. has the right
> extension)??

What the heck is this stamping system for? Distributed access to stamping
facilities? Critically identifying events, or "authenticating signatures" as
described - I have to ask the burning question - why would I use that? what
would give me a financial interest in doing this? Who is going to pay me to
timestamp stuff?

There is only so much business for TTP's and at some point saturation is
going to occur (it may have already!)


So then what is timestamping really going to be used for? I suggest that the
issue is how to create culpable timestamping process models that people can
operate on a single system, what that means is addressing the following
issues:

    1)    The physical source of time and its
            believability properties (HW and SW timebase services)
    2)    The token structure used to represent the events
            and its proofing facilities
    3)    The crypto services to keep #1 honest and #2 secure
    4)    The remote query/proofing services so that I can
           dispute a timestamp...

Don't get the wrong impression now -
------------------------------------
I think that while the routines described in the Zuceratto/Pinkas/Cain/Adams
Draft are fantastic, but from my perspective, they are putting the cart
before the horse.

What I propose is that the concept and the user requirements for
timestamping are more mundane than distributed processing as proposed in the
initial and revised Time Stamp and Notary Services Drafts to date. That we
should really understand exactly what it is we are trying to accomplish
here, and that the end users want systems not pieces of systems. With that
in mind, what I want to propose is that this timestamping issue is about the
4 issues listed above and not as much, about distributed systems.

If anyone doubts this commercially, then answer the riddle on Fisher and
Bellcore's mind - why hasn't Surety gone public with all the money they are
making?.

The answer is Distributed Systems (whether operated by a TTP or used as
embedded systems) are not what people want,
    A) they want to own it themselves
    B) it has to fit seamlessly into their legacy apps alreay in production,
and
    C) they must have a compelling reason for buying secure time and since
most of them think that they already have it anyway, thanks to the OS
marketing people.

Let me tell you, selling time and timeservices is hard. As the founder of
Coastek and the new Meridianus effort, I can attest to this first hand. So
what I propose is that the use model issue is paramount here and it is still
unaddressed as of today.

The Solution
-------------
What we should do as a standards org, is to create a suite of basic event
representation tokens, and then promugate them to the higher level standards
orgs, as well as the service routines to make and validate them.
But make no mistake, it is the tokens that tie this all together, not the
API routines, they are just a pathway to the token, and this has been the
disconnect in this timestamping process all along.

----

Lets give this wheel another spin - any comments?

Todd



>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05638 for ietf-pkix-bks; Fri, 14 May 1999 10:01:40 -0700 (PDT)
Received: from ns1.dmz.valicert.com (ns1.valicert.com [63.65.221.10]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA05634 for <[e-mail]>; Fri, 14 May 1999 10:01:39 -0700 (PDT)
Received: from ns1.serverfarm.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns1.dmz.valicert.com (8.9.2/8.9.2) with ESMTP id KAA07911; Fri, 14 May 1999 10:03:18 -0700 (PDT)
Received: from peternt (static-3-26.engineering.valicert.com [192.168.3.26] (may be forged)) by ns1.serverfarm.valicert.com (8.9.2/8.9.2) with SMTP id KAA29834; Fri, 14 May 1999 10:04:09 -0700 (PDT)
Received: by localhost with Microsoft MAPI; Fri, 14 May 1999 10:10:41 -0500
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
To: "'Sam Schaen'" <[e-mail]>
Cc: "Linn, John" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Attributes within PK certs?[draft-ietf-pkix-ac509prof-00.txt]
Date: Fri, 14 May 1999 10:10:40 -0500
Organization: ValiCert Inc.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Friday, May 14, 1999 8:10 AM, Sam Schaen [SMTP:[e-mail]] wrote:
> 
> I have seen at least one vendor's product that espouses very short
> validity periods for attribute certificates (e.g., 1 hour or 1 day). 
> Short enough that one is willing to accept the risk that the information
> in the certificate has changed without resorting to a certificate
> revocation process.
>

This remarkable invention should be better investigated
by PKIX using applications.  It confounds Steve's
Rule of Revocation, and addresses Internet needs
at the same time. 

One of the modes of using OCSP is that
its responses may serve as a
surrogate-certificate, with short-expiry.  UAs can 
quote the OCSP status response instead of the public key
id cert, should the (Indirect) response issuer
incorporate the public key of the referenced cert 
in the OCSP per-cert-status extension block.

At some point PKIX will need to
define the "Qualified OCSP Profile"
of course, to standardize this optional, but
standard operational model of 2459/OCSP
deployment.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04613 for ietf-pkix-bks; Fri, 14 May 1999 07:28:59 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04609 for <[e-mail]>; Fri, 14 May 1999 07:28:57 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA00864; Fri, 14 May 1999 16:31:12 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 14 May 1999 16:31:11 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id QAA11646; Fri, 14 May 1999 16:31:10 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id QAA16558; Fri, 14 May 1999 16:31:09 +0200
Date: Fri, 14 May 1999 16:31:09 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OSCP BIG BANG
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Denis,
> 
> >>
> >> The change from MAY to MUST was intentional. The notion is that a CA is
> >> considered as OCSP compliant only if it is capable of putting the AIA
> >> extension, with OCSP-specific values, into certs that it generates.
> >
> >What do you mean here ? He is capable to do it, but it does not  ? This is
> >a very
> >odd concept to me.
> 

It seems that what is actually required in case that someone wants
to provide ocsp, is that the software used to provide certification
MUST be able to set AIAs. 

The AIA is an extension especially defined for the Internet, either 
one should be completely silent about whether 'in the Internet context' 
it is required to support an AIA extension in order to be able to support
a multitude of requirements that may come from other protocols, or simply say,
AIA support is mandatory in the Internet. 

Is there a need to clarify rfc2459? If the AIA is mandatory,
then there is no conflict with latest OCSP draft. 
 
Combining a mandatary support for AIAs with a special service definition
like OCSP needs some explication, especially when you can operate
a service without it.

P 

BTW: One might add to the text that the certificate that carries 
'ocsp signing' extended key usage extension,  SHOULD/MAY also carry 
an AIA with ocsp code signing and the url of the service fo example. 




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA04051 for ietf-pkix-bks; Fri, 14 May 1999 06:08:22 -0700 (PDT)
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA04047 for <[e-mail]>; Fri, 14 May 1999 06:08:20 -0700 (PDT)
Received: from MAILHUB2 (mail.mitre.org [129.83.221.18]) by mbunix.mitre.org (8.8.8/8.8.8) with ESMTP id JAA25816; Fri, 14 May 1999 09:10:58 -0400 (EDT)
Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub2.mitre.org with SMTP id 831060; Fri, 14 May 1999 09:10:56 EST
Message-ID: <[e-mail]>
Date: Fri, 14 May 1999 09:09:59 -0400
From: Sam Schaen <[e-mail]>
Organization: The MITRE Corporation
X-Mailer: Mozilla 4.5 [en]C-19990120M  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: "Linn, John" <[e-mail]>, [e-mail]
Subject: Re: Attributes within PK certs?[draft-ietf-pkix-ac509prof-00.txt]
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In  the DOD PKI, the process of registering for and receiving a
certificate is fairly expensive, since a face-to-face visual
identification of the individual by a registration authority or other
trusted person is required.  (This is expensive because the potential is
for 2.5 million users spread around the world, thus requiring a large
infrastructure.)

On the other hand, we do permit the use of the stable (identity)
certificate to be used for various purposes, including authentication
for obtaining other certificates.  Currently, we only implement using
the identity certificate to obtain an S/MIME certificate.

However, that concept could be extended to other types of certificates,
including attribute certificates.  Since the cost for successive
certificates is relatively inexpensive (because it is entirely
electronic and does not require the face-to-face identification), it may
be acceptable to have certificates that do not have a long effective
lifetime.

I have seen at least one vendor's product that espouses very short
validity periods for attribute certificates (e.g., 1 hour or 1 day). 
Short enough that one is willing to accept the risk that the information
in the certificate has changed without resorting to a certificate
revocation process.

If we can agree that attribute certificates will be an adjunct to a more
stable certificate, we can then begin to debate whether the format of
the certificate should be a complete X.509 certificate with additional
extensions or a special attribute certificate that is cryptographically
bound to the identity certificate.

One also needs to consider who will be issuing attribute certificates. 
In many cases, one would want the owner of a particular resource to be
able to grant access to that resource.  That may not be the same
organization that can best validate the identity of the user.  So it may
be prudent to allow for the identity and attribute certificates to be
issued by different authorities.

Sam Schaen
MITRE Corporation

Russ Housley wrote:
> 
> John:
> 
> Steve Kent's Rule of Revocation: "The effective lifetime of a certificate
> is inversely proportional to the square of the number of attributes."
> 
> I agree with Steve's rule. While the subjectDirectoryAttribute extension
> trick allows for early deployment, it will reduce the effective lifetime of
> X.509 identity certificate.  It increases the likelihood that revocation
> will be necessary.
> 
> I do not think that the PKIX AC Profile should encourage the use of the
> subjectDirectoryAttribute extension trick.  Nor do I think that the PKIX AC
> Profile should discourage people from using it in the near term.  I think
> the PKIX AC Profile should be silent on this point.
> 
> Russ
> 
> At 03:34 PM 5/10/99 -0400, Linn, John wrote:
> >I'd like to welcome this work to PKIX's scope, and to make a general comment
> >relevant to the draft. I believe that attribute certification will be
> >valuable and important in broadening the scope of PKI technologies to span
> >authorization as well as authentication.  If experience is a guide, however,
> >new certification infrastructures can take a long time to become
> >established.  With this in mind, I suggest that we decouple the idea of
> >certifying authorization attributes from the idea that they must be in ACs
> >separate from public-key identity certificates.  As [XPDAM] allows, I
> >suggest that PKIX-profiled authorization attributes alternatively be
> >representable within subjectDirectoryAttributes of a public-key certificate,
> >when CA and AA responsibilities and validity periods overlap appropriately.
> >This would imply some change to 2459's description of this attribute (which
> >says that it may be used in local environments, but is not recommended as an
> >essential part of the 2459 profile), but would allow authorization
> >attributes to be incorporated incrementally within CAs' certificates rather
> >than necessitating a separate infrastructure.
> >
> >--jl



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA03780 for ietf-pkix-bks; Fri, 14 May 1999 05:18:42 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA03776 for <[e-mail]>; Fri, 14 May 1999 05:18:41 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA05582; Fri, 14 May 1999 05:19:19 -0700 (PDT)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 12 May 1999 11:25:36 -0400
To: "Linn, John" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Attributes within PK certs? [draft-ietf-pkix-ac509prof-00.txt]
Cc: [e-mail]
In-Reply-To: <[e-mail] mics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

Steve Kent's Rule of Revocation: "The effective lifetime of a certificate
is inversely proportional to the square of the number of attributes."

I agree with Steve's rule. While the subjectDirectoryAttribute extension
trick allows for early deployment, it will reduce the effective lifetime of
X.509 identity certificate.  It increases the likelihood that revocation
will be necessary.

I do not think that the PKIX AC Profile should encourage the use of the
subjectDirectoryAttribute extension trick.  Nor do I think that the PKIX AC
Profile should discourage people from using it in the near term.  I think
the PKIX AC Profile should be silent on this point.

Russ


At 03:34 PM 5/10/99 -0400, Linn, John wrote:
>I'd like to welcome this work to PKIX's scope, and to make a general comment
>relevant to the draft. I believe that attribute certification will be
>valuable and important in broadening the scope of PKI technologies to span
>authorization as well as authentication.  If experience is a guide, however,
>new certification infrastructures can take a long time to become
>established.  With this in mind, I suggest that we decouple the idea of
>certifying authorization attributes from the idea that they must be in ACs
>separate from public-key identity certificates.  As [XPDAM] allows, I
>suggest that PKIX-profiled authorization attributes alternatively be
>representable within subjectDirectoryAttributes of a public-key certificate,
>when CA and AA responsibilities and validity periods overlap appropriately.
>This would imply some change to 2459's description of this attribute (which
>says that it may be used in local environments, but is not recommended as an
>essential part of the 2459 profile), but would allow authorization
>attributes to be incorporated incrementally within CAs' certificates rather
>than necessitating a separate infrastructure. 
>
>--jl


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA03447 for ietf-pkix-bks; Fri, 14 May 1999 04:15:12 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA03443 for <[e-mail]>; Fri, 14 May 1999 04:15:09 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id NAA24269; Fri, 14 May 1999 13:17:58 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 14 May 1999 13:17:51 +0200
To: Russ Housley <[e-mail]>, Hans Nilsson <[e-mail]>, Stephen Kent <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Rename Qualified Certificates?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA03444
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Regaring name change of PKIX Qualified Certificates...

I'm ready to give my proposal to a final solution to this.

I propose that we throughout the specification define and use the
abbreviation QCP, standing for "Qualified Certificate Profile.

This is the only reasonable solution I have found.

The QCP is a PROFILE for certificates aimed to support digital signatures
that are considered functionally equivalent to handwritten signatures.

There is only one term known to me that is used to denote such certificate,
and that is the term "Qualified Certificate". So I don't want to lose the
close relation to that term.

This is why I believe that QCP is a good "middle way". The "P" clarifies
that this is a technical profile and prevents mixups with any national
regulation or legal framework specifying functional requirements for
Qualified Certificates.

But before I close this I would like to have Stephen Kent's opinion, since
this may effect the charter.

/Stefan

At 08:32 AM 5/7/99 -0400, Russ Housley wrote:
>I agree that the name should be changed; however, I really do not like the
>one you have proposed.  "Identity certificates" is a commonly used term
>meaning that an identity is bound to a public key in a certificate.
>
>Perhaps a merging of the two terms is better: Qualified Identity Certificates.
>
>Russ
>
>
>At 08:15 AM 5/7/99 +0200, Hans Nilsson wrote:
>>Yesterday I attended a meeting with the European Standards Organization CEN,
>>where we now are trying to prepare the necessary standardization for
>>implementing the EU directive on Electronic Signatures. The work in PKIX is
>>regarded as most relevant in this respect, and will be most likely be used
>>and referenced a lot. This is also true for the current working draft on
>>Qualified Certificates, which is very much in line with the requirements in
>>Annex I of the directive.
>>
>>However, the term Qualified Certiciates is already being used in the
>>Directive with a special meaning and definition ("a certifciate that meets
>>the requirements laid down in Annex I and is provided by a certification
>>service provider that fulfills the requirements laid down in annex II").
>>
>>Although I am partly responsible for "hijacking" the term QC from the
>>directive and using it for our work, I now realise that this was not a very
>>good decision, since the EU term also requires that the CA fulfils Annex II.
>>We thus two honomyms that mean two different things.
>>
>>I would therefore like to propose that the PKIX term is changed to something
>>else, and possibly more descriptive. My suggestion is "identity
>>certificates", but there may be other good suggestions.
>>
>>Regards
>>
>>Hans Nilsson
>>iD2 Technologies
>>

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA00196 for ietf-pkix-bks; Fri, 14 May 1999 01:55:16 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA00192 for <[e-mail]>; Fri, 14 May 1999 01:55:14 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA22020; Fri, 14 May 1999 10:58:06 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 14 May 1999 10:58:06 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id KAA07939; Fri, 14 May 1999 10:58:05 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id KAA16384; Fri, 14 May 1999 10:58:05 +0200
Date: Fri, 14 May 1999 10:58:05 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The unique monotonic etc serialNumber is critical when you have to resolve
> 'who was the first' argument between two stamps, having the same time value.
> This may well happen if the resolution of the clock is relatively low, and
> two requests entered the TS server virtually simultaneously. Think about
> on-line betting, auctions, etc.
This is right if you want service.

> 
> Defining serialNumber OPTIONAL will make it very confusing for a client who
> relies on the sequence as well as on the time itself.
No, because the authority has defined their service in advance. 
if the authority defines a service that guarantees strict sequencing,
then this is known in advance.  

> 
> And I would be deadly scared of seeing something like "if more than one time
> stamp are generated with the same time value, then TSA MUST include
> serialNumber into the TSTInfo. Otherwise, the field may not be present ...".
Me, too. but probably not for the same reasons. 

If SerialNumber is present one might be tempted to deduce that the time
stamps are unique. BUT that is not the way to interprete the 
presence of a SerialNumber  

The authority first defines that it provides a certain service, 
and THEN it uses a certain technology. Whatever you find in the stamp, 
it does'nt matter. if the authority considers never to deliver more than
4.000.000.000 time stamps per second, you may not need a sequence number.

One should not start to think:

- I find serialnumber ==> I have unique time stamps 
  (The result is probably true, but why making the test at all?)
 
- I don't have serialnumber ==> Not unique time stamps
  (This may simply be wrong, again, it depends on the service).

In order to decide which kind of service ou have, I guess, one
needs to use a policy identifier, configuration knowledge, or
whatever. You don't use a time stamping authority's signing
certificate just because it looks nice (i.e. has the right
extension)??


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA25446 for ietf-pkix-bks; Thu, 13 May 1999 23:08:53 -0700 (PDT)
Received: from selva.dit.upm.es (selva-gw.dit.upm.es [138.4.2.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA25441 for <[e-mail]>; Thu, 13 May 1999 23:08:33 -0700 (PDT)
Received: from dit.upm.es (toro-3.dit.upm.es [138.4.21.3]) by selva.dit.upm.es (8.9.1a/8.9.1) with ESMTP id IAA10342; Fri, 14 May 1999 08:10:47 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 14 May 1999 08:07:24 +0200
From: "Jose A. Manas" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Zuccherato <[e-mail]>
CC: [e-mail], "'Juan G. de la Vega'" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
References: <01E1D01C12D7D211AFC70090273D20B112BE22@sothmxs06>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert Zuccherato wrote:

> As I stated at the time, since this protocol relies on signatures to
> preserve the integrity of the time stamp token, and signing algorithms make
> use of hashes, if SHA-1 is broken, for example, then no time stamp token
> will be trusted.  Thus, adding more hashes will not improve the security of
> the protocol.

I prefer to think of time stamping as a service provided by a TTP.
Part of TTPs value derives from evidence storage for later resolution of
disputes. Since it is a core part of a time-stamping service not to
disclose
data, the only evidence a TSA may hold is the hash value(s). 
Enhancing the "quality" of evidence is achieved by means of several hash
values.
That's true despite the fact that the "time-stamp receipt" returned by
the TSA
might be broken (if a single hash value is used to sign the receipt).

> I am also concerned that TSA's will begin demanding that 3 (or 4 or 5)
> different message imprints be included within the request, in order to make
> it more "secure".  Or that verifiers will begin to be required to verify
> every message imprint (even though you only really need to verify one
> imprint).  This will make client tools much more complex.

I'd rather say client tools are simpler.
In order to get a time-stamp, as many hash values may be provided as
wished,
and even different TSA (with different practices) may accept a single
request token.
Verification is a separate issue, where the verifier may apply its own
point of view on which hash algorithms are reliable
(in fact, the practice of the verifier may be different from
the practice of the service provider).

> Since the benefits of including a SEQUENCE OF Message Imprint are dubious,
> there are possibly negative consequences, and there doesn't appear to be a
> great deal of support for including it, I left it out.

I'd rather say that it is a cheap opportunity to devise a clean
exchange protocol that keeps doors open for actual implementations
to choose as appropiate for their business case.

>         Robert.

Best,
pp

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA25438 for ietf-pkix-bks; Thu, 13 May 1999 23:08:23 -0700 (PDT)
Received: from selva.dit.upm.es (selva-gw.dit.upm.es [138.4.2.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA25432 for <[e-mail]>; Thu, 13 May 1999 23:08:13 -0700 (PDT)
Received: from dit.upm.es (toro-3.dit.upm.es [138.4.21.3]) by selva.dit.upm.es (8.9.1a/8.9.1) with ESMTP id IAA10338; Fri, 14 May 1999 08:10:41 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 14 May 1999 07:52:12 +0200
From: "Jose A. Manas" <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "Juan G. de la Vega" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My concern is that composite hashes do not scale:

1. There are currently about 7 hash algorithms to play with
(md2, md4, md5, sha1, rimemd128, ripemd160, ripemd256).
That implies 7 single oids, plus 7x6 combinations with two of them,
plus 7x6x5 combinations of three, and so on. I feel much more
confortable with 7 oids rather than with such a collection.

2. How are new algorithms introduced?
You need a new bunch of OIDs, plus the knowledge of the size
of each hash value to be widely spread.

3. Under which OID branch are these combinations to exist?
(you mention some hash root, but so far algorithms are under
separate prefixes)

It is so simple to have a sequence of hashes (even for signing)
that it looks unwise to further complicate the already complex
problem of OID over population.

Best,
pp

[e-mail] wrote:
> 
>      The object ID of a composite hash algorithm will uniquely determine the
> order in which the component hashes are to be placed.  The object ID of such an
> algorithm will be an ordinary-looking OID.    A typical example would be roughly
> as follows:
> 
> SHA1_then_MD5  ::=  OBJECT IDENTFIER     { hash_root  7 }
>      -- the value of this hash will consist of 36 octets.  The first 20 octets
> consist of the output
>      -- of the SHA1 algorithm on the input data, and the last 16 octets consist
> of the output of
>      -- the MD5 algorithm on the input data.
> 
>      There should be no greater problem in interpreting this object ID than that
> of any other hash algorithm.  I believe that several such algorithm ID's should
> be defined and published in a standard location.  These could be used for many
> signature applications, and not just for time stamps.
> 
>           Tom Gindin

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[e-mail]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA25341 for ietf-pkix-bks; Thu, 13 May 1999 22:52:58 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA25337 for <[e-mail]>; Thu, 13 May 1999 22:52:50 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id PAA10533; Fri, 14 May 1999 15:56:36 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'Paul Koning'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt (Re:precisionFactor)
Date: Fri, 14 May 1999 15:53:25 +1000
Message-ID: <001c01be9dce$167edff0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <01E1D01C12D7D211AFC70090273D20B112BE23@sothmxs06>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>The intent was for precision to mean the delta between the time value and
>the actual UTC when it was issued.  How about if I change the example to
>"This precisionFactor would account for  50-Hz (20ms) or 60-Mh (16.67ms)
>power-frequency clocks that are closely synchronized to UTC, for example."

Sounds OK. Anticipating people to start arguing that "closely synchronised"
is a very loose definition, I can suggest adding something like:
"The actual method and frequency of synchronising the clock with UTC time,
as well as the characteristics of the clock itself, define the deviation
from UTC. As time stamp is not conceived to be used as a source of precise
timing, that information is not present in the stamp. However, the TSA's
policy MAY contain necessary details for interested parties".

MichaelZ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA28375 for ietf-pkix-bks; Thu, 13 May 1999 17:14:46 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA28371 for <[e-mail]>; Thu, 13 May 1999 17:14:43 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id KAA05191; Fri, 14 May 1999 10:15:58 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Fri, 14 May 1999 10:12:44 +1000
Message-ID: <001501be9d9e$800ecdc0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <01E1D01C12D7D211AFC70090273D20B112BE27@sothmxs06>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,

You wrote:
>However, that doesn't mean that resolving the "who was first" argument
isn't
>important or isn't something we want to do within this protocol.  (After
>all, we do support precision greater than a second even though it probably
>isn't required for the stated purpose above.)  If we do decide that this is
>something that is important and is something we want to do, I think that
the
>serialNumber is the wrong place to do it.  All timing (and therefore
>sequencing) information should be contained with the TSTTime field.  Thus,
>we could, for example, mandate that the fractionOfSecond field must be
>strictly monotonically increasing within a second and mandating that the
TSA
>not generate more than one time stamp with the same time value.

>I really think that the serial number should remain simply a method for
>identifying specific tokens and therefore, does not need to be mandatory.

I have no objections to any other means to resolve the naughty 'who is the
first' problem.
However, if we keep on using the time itself, then theoretically we can run
into the same problem. It is just that the finer time resolution makes the
the chance of simultaneous requests less probable. But the chance is still
there. And I do not see how the TSA would technically be able to guarantee
to "not generate more than one time stamp with the same time value."

Regards
MichaelZ




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23118 for ietf-pkix-bks; Thu, 13 May 1999 07:26:40 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA23114 for <[e-mail]>; Thu, 13 May 1999 07:26:38 -0700 (PDT)
Received: 	id KAA16447; Thu, 13 May 1999 10:25:22 -0400
Received: by gateway id <J96LDLZQ>; Thu, 13 May 1999 10:27:47 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BE29@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: "'PKIX mailing group'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt (Re: Protocol)
Date: Thu, 13 May 1999 10:27:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael;

The issue of billing has been discussed previously (at least at the Los
Angeles meeting).  At the time we decided that we would not introduce
additional requirements into this document to accommodate billing, if those
requirements conflicted with some of the stated goals of this protocol (for
example, that the requester not be verified by the TSA).  While billing is a
real concern, and in order to do so, the requester will have to be
identified, that should be done outside of the protocol defined by this
document.

That is why we say:
"In situations where the TSA requires the identity of the requesting entity,

it is suggested that alternate identification means be used (e.g. CMS 
encapsulation [CMS] or TLS authentication [RFC2246])."
That is also one of the reasons that no particular transport mechanism
described is mandated by this draft.  

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, May 12, 1999 10:02 PM
> To: 	'Robert Zuccherato'; 'PKIX mailing group'
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt (Re:
> Protocol)
> 
> Robert,
> You wrote:
> >I am hesitant to require the extra layer when it isn't really required.
> The
> >PKIHeader would serve no purpose here.
> 
> I can see one apparent need for having something more in the protocol
> frame
> then just Length,Flag,<TST structure>. That is, the originator info.
> Otherwise, billing becomes a real problem.
> CMP format would solve it by specifying the Sender in the header and
> signing
> the whole lot ( so nobody can send a request on somebody else's behalf).
> Or
> just a signature may suffice, as a minimum.
> 
> To me, billing alone can justify having more complex structure.
> 
> Regards
> MichaelZ
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22849 for ietf-pkix-bks; Thu, 13 May 1999 06:50:20 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22845 for <[e-mail]>; Thu, 13 May 1999 06:50:19 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id ga002372 for <[e-mail]>; Thu, 13 May 1999 15:53:32 +0100
Message-ID: <012001be9d47$87139940$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Thu, 13 May 1999 15:50:10 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael,

    I mainly agree with you; the time itself is a strictly monotonically
increasing function :-)
    I find this field particularly useful in order to device a relative
temporal relationship amongst TSTs (issued by the same TSA) and in case some
record with references  is implemented as an audit activities support. Using
this, 2 given timestamps can be easily compared (<).
    But I also see that this may not be an issue in some cases such as when
a TSA publishes what has been called "signed time".
    Whether it should be optional or mandatory, I do not have strong
opinion, I think it should be there and I will use it most of the times (if
not all).

bye,

Juan.

----- Mensaje original -----
De: Michael Zolotarev <[e-mail]>
Para: <[e-mail]>
Enviado: jueves 13 de mayo de 1999 2:59
Asunto: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )


> The unique monotonic etc serialNumber is critical when you have to resolve
> 'who was the first' argument between two stamps, having the same time
value.
> This may well happen if the resolution of the clock is relatively low, and
> two requests entered the TS server virtually simultaneously. Think about
> on-line betting, auctions, etc.
>
> Defining serialNumber OPTIONAL will make it very confusing for a client
who
> relies on the sequence as well as on the time itself.
>
> And I would be deadly scared of seeing something like "if more than one
time
> stamp are generated with the same time value, then TSA MUST include
> serialNumber into the TSTInfo. Otherwise, the field may not be
present...".
>
> MichaelZ
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22826 for ietf-pkix-bks; Thu, 13 May 1999 06:48:25 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22822 for <[e-mail]>; Thu, 13 May 1999 06:48:24 -0700 (PDT)
Received: 	id JAA03913; Thu, 13 May 1999 09:47:09 -0400
Received: by gateway id <J96LDL3A>; Thu, 13 May 1999 09:49:34 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BE27@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Thu, 13 May 1999 09:49:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael;

The primary purpose of this document is for time stamping with a PKI to
support the non-repudiation of signatures.  In this situation we will
primarily be comparing time stamps to revocation times and certificate
expiry times, neither of which involves "who was the first".

However, that doesn't mean that resolving the "who was first" argument isn't
important or isn't something we want to do within this protocol.  (After
all, we do support precision greater than a second even though it probably
isn't required for the stated purpose above.)  If we do decide that this is
something that is important and is something we want to do, I think that the
serialNumber is the wrong place to do it.  All timing (and therefore
sequencing) information should be contained with the TSTTime field.  Thus,
we could, for example, mandate that the fractionOfSecond field must be
strictly monotonically increasing within a second and mandating that the TSA
not generate more than one time stamp with the same time value.

I really think that the serial number should remain simply a method for
identifying specific tokens and therefore, does not need to be mandatory.  

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, May 12, 1999 8:59 PM
> To: 	[e-mail]
> Subject: 	RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re:
> serialNumber )
> 
> The unique monotonic etc serialNumber is critical when you have to resolve
> 'who was the first' argument between two stamps, having the same time
> value.
> This may well happen if the resolution of the clock is relatively low, and
> two requests entered the TS server virtually simultaneously. Think about
> on-line betting, auctions, etc.
> 
> Defining serialNumber OPTIONAL will make it very confusing for a client
> who
> relies on the sequence as well as on the time itself.
> 
> And I would be deadly scared of seeing something like "if more than one
> time
> stamp are generated with the same time value, then TSA MUST include
> serialNumber into the TSTInfo. Otherwise, the field may not be present
> ...".
> 
> MichaelZ
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA19126 for ietf-pkix-bks; Thu, 13 May 1999 02:50:18 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA19122 for <[e-mail]>; Thu, 13 May 1999 02:50:16 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id ha002243 for <[e-mail]>; Thu, 13 May 1999 11:53:24 +0100
Message-ID: <005601be9d25$fafa21c0$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: "Robert Zuccherato" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Thu, 13 May 1999 11:50:01 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Just some comments on your response,

-----Mensaje original-----
De: Robert Zuccherato <[e-mail]>
Para: [e-mail] <[e-mail]>; 'Juan G. de la Vega'
<[e-mail]>
Fecha: miércoles 12 de mayo de 1999 21:01
Asunto: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt


R:

Juan;

As I stated at the time, since this protocol relies on signatures to
preserve the integrity of the time stamp token, and signing algorithms make
use of hashes, if SHA-1 is broken, for example, then no time stamp token
will be trusted.  Thus, adding more hashes will not improve the security of
the protocol.


J: I was thinking in something a step forward; regarding TST as a signed
receipt not as the only time certificate itself (it is difficult to imagine
a TSA just signing without keeping any record), in this case multiple hashes
do improve the security of the protocol since the TSA keeps multiple
representation of the data item stamped and may reissue (without requiring
the user) a TST using a non-broken hash algorithm when the formerly used is
no longer to be trusted. Anyway, since the protocol just considers TSTs as
valid time stamping proofs then the inclusion of multiple hash would make no
effect as far as the signature algorithm wouldn't regard these.

R:
I am also concerned that TSA's will begin demanding that 3 (or 4 or 5)
different message imprints be included within the request, in order to make
it more "secure".  Or that verifiers will begin to be required to verify
every message imprint (even though you only really need to verify one
imprint).  This will make client tools much more complex.


J: I do not agree with you. The verifier is not required or forced to, the
verifier herself decides which policies fit
her security/trust requirements. In this sense your proposal of using
"composite" OIDs limits the configuration of those requirements and also
backward compatibility. If my client application just computes SHA-1 and a
TST comes with the OID "SHA-1++NEWHASH" it would reject that Token, while
this should not happen if my application could scan several OIDs looking for
SHA-1...
If you use "composite" OIDs and willing to support 4 different hash
algorithms, then you go up to 15 OIDs and the associated computing of the
messageImprint field, I think that is more complex that having 4 OIDs and
following a sequence. Anyway, this does not apply if the signature is the
only support for time certificates...

R:
Since the benefits of including a SEQUENCE OF Message Imprint are dubious,
there are possibly negative consequences, and there doesn't appear to be a
great deal of support for including it, I left it out.

Robert.

regards,

    Juan.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA18943 for ietf-pkix-bks; Wed, 12 May 1999 19:02:20 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA18924 for <[e-mail]>; Wed, 12 May 1999 19:02:10 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id MAA26337; Thu, 13 May 1999 12:05:48 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'PKIX mailing group'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt (Re: Protocol)
Date: Thu, 13 May 1999 12:02:29 +1000
Message-ID: <001301be9ce4$a967eef0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <01E1D01C12D7D211AFC70090273D20B112BE1F@sothmxs06>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Robert,
You wrote:
>I am hesitant to require the extra layer when it isn't really required.
The
>PKIHeader would serve no purpose here.

I can see one apparent need for having something more in the protocol frame
then just Length,Flag,<TST structure>. That is, the originator info.
Otherwise, billing becomes a real problem.
CMP format would solve it by specifying the Sender in the header and signing
the whole lot ( so nobody can send a request on somebody else's behalf). Or
just a signature may suffice, as a minimum.

To me, billing alone can justify having more complex structure.

Regards
MichaelZ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA18462 for ietf-pkix-bks; Wed, 12 May 1999 18:48:19 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA18458 for <[e-mail]>; Wed, 12 May 1999 18:48:03 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id LAA26075 for <[e-mail]>; Thu, 13 May 1999 11:52:17 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments (Re: Tag)
Date: Thu, 13 May 1999 11:49:02 +1000
Message-ID: <001201be9ce2$c8bc7b10$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Let me speculate a little bit about the problem of tags.

First, an abstract: A tag, (at least my idea of it, MZ), is an optional
sequence, containing any sort of data, that allows a requestor to associate
the time stamp with the data it has been produced for.

Second, a few questions to ask:
Q1. Does anybody need the tags at all?
Q2. Does having tags create any problems?
Q3. Can we achieve the same goals without tags? Is it more practical?
Q4. Would many clients need tags? Would the majority of clients use tags?

If you answered Q1:Y, Q2:N, Q2:N, then you agree that tags have right to
exist. I do not think many people would argue, and many have already come up
with real life examples where tags come handy.

Now, the question is WHERE should a tag be defined.

The only possible options are:
1) As a field inside the TS request and response structures
2) As a field inside outer protocol frame or even transport frame.

The choice directly depends on how you answer Q4.
If it is reasonable to expect that tags will be used by the majority of the
clients, then it should become a field inside the core time stamp
structures.
Otherwise, we can get around by just providing recommendations on how
tagging can be implemented using various encapsulations of the time stamp
messages.

-------------------------------------------------
My suggestion would be that a TimeStampReq is added with an optional field.
If present, the response will contain the same value. This can be done by
1)Preserving a similar field in the TimeStampToken, or 2)by merging the tag
into the unauthenticatedAttrib of the signerInfo. The former seems to be
simpler, but I have no particular preferences here.
-------------------------------------------------
Talking about the practicalities of having tags - recently I have tried a
Notary application, developed by some company. Guess what - they do not have
tags, and the solution (to associate the tokens with the origins) they came
up with is inevitable ugly, and does not always work anyway.


MichaelZ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA18450 for ietf-pkix-bks; Wed, 12 May 1999 18:46:54 -0700 (PDT)
Received: from COLUMBIA.BBN.COM (COLUMBIA.BBN.COM [192.1.17.53]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA18446 for <[e-mail]>; Wed, 12 May 1999 18:46:52 -0700 (PDT)
Received: from coldhcp1-179.bbn.com by COLUMBIA.BBN.COM id aa11461; 12 May 99 21:44 EDT
Reply-To: <[e-mail]>
From: "Dave Sweigert" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: DoD PKI in the news
Date: Wed, 12 May 1999 21:40:38 -0400
Message-ID: <000401be9ce1$9b33f200$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <001101be9cdb$d42555a0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Inside the Army, 10 May 1999

Hamre pushes ahead with infosec effort
NEW PKI POLICY WILL HAVE DRAMATIC IMPACT ON MILITARY, BUSINESS AFFAIRS
By Jeremy Singer

Copyright Inside the Army


A new public key infrastructure policy signed by Deputy Defense Secretary
John Hamre last week will have a "huge impact" on the way the Army and other
services conduct military and business affairs, a service official told
Inside the Army last week.

"As far as electronic commerce goes, this is a watershed event," he said.

In many cases, the new policy will reduce the number of intermediaries
handling documents, and greatly expedite the process of approving travel
orders, for example, he said.

PKI is one element of the layered strategy information assurance officials
are working on this year. A department-wide PKI will allow DOD to
communicate securely and help eliminate paper from the military's
operations, two major priorities for Hamre. Public key cryptography involves
two related keys, one public and one private, and an infrastructure of
people and systems is required in order to manage the keys and the services
they provide, which include data integrity, user identification and
authentication, encryption and digital signature.

"The DOD PKI, in the context of the Defense-in-Depth strategy, will provide
a solid foundation for IA capabilities across the Department," Hamre wrote
in the memo, obtained by Inside the Army.

"The goal of this DOD-wide infrastructure is to provide general-purpose PKI
services (e.g. issuance and management of certificates and revocation lists
in support of digital signature and encryption services) to a broad range of
applications, at levels of assurance consistent with operational
imperatives," he continued.

"Implementation of these policies will ensure that DOD components are using
the infrastructure, and that future uses of public key cryptography as part
of the Department's Defense-in-Depth strategy are consistent with threat and
risk tolerance," Hamre concluded.

Hamre first outlined his plans for a defense-wide PKI in August 1997. The
going has been slow, however, due to the complexities involved in
implementing such an intricate system in such a large community. Just a few
weeks ago, DOD released its PKI Roadmap, which begins to spell out in detail
how the department will establish a PKI.

Key elements of the PKI are the issuance and revocation of digital
certificates, which are electronic proofs of identity. According to Hamre's
memo, Class 5 assurance certificates should be used for the sending of
classified information over unencrypted networks. Class 4 certificates will
be used for sending unclassified, mission critical information over
unencrypted networks, and for protection information crossing classification
boundaries.

Category one mission-critical systems, which the Clinger-Cohen Act says must
be related to command and control of military forces, integral to a weapon
or weapons system or critical to direct fulfillment of military or
intelligence missions, must begin migrating to Class 4 certificates and
tokens and achieve full implementation by June 2000, the memo states.

When operating over unencrypted networks, category two systems, which
operate in direct support of systems identified by commander-in-chiefs as
mission critical, and category three systems, which are required to perform
department level and component level core functions, must use a Class 3
certificates. "These systems, that employ public key cryptography, must
migrate to the use of Class 4 certificates and tokens by December 31, 2002,"
the memo states. "All other applications that employ public key technology
(e.g. mission critical information on encrypted networks using [National
Security Agency] Type 1 approved encryption, and mission
support/administrative information on any networks) must use Class 3
certificates. All DOD users, at a minimum, will be issued a Class 3
certificate by October 2001."

The Defense Department plans to leverage two ongoing PKI efforts for the
target PKI defined in the DOD road map: Fortezza (the near-term solution for
Class 4) and Class 3, formerly known as medium assurance PKI. The memo
directs DOD organizations to deploy trained personnel and installed software
and hardware for registration operations for the efforts, as well as
infrastructure with the capability to issue certificates from the Class 3
PKI to each member of the organization, by October 2000.

All certificates will evolve to Class 4 certificates with the target PKI,
the memo states. As hardware token technology becomes more mature and
ubiquitous, DOD will move from Class 3 to Class 4 certificates for all
applications, the memo states. Components will begin to issue the Class 4
certificates by January 2002. The planned architecture for the Class 4
certificate will draw on the features of an identification card, building
access token and workstation access token, on a single token.

By issuing a memo to get all DOD components on the same page, the overall
effort will be more cost-effective, the service source told ITA. "You need
to engage the buying power of DOD," he said. "When you're talking about
buying cards in the tens of thousands, it's very expensive, but when you
start talking about ordering in the hundreds of thousands, the price begins
to look quite reasonable."

The memo is also intended to make sure the services are on the same page to
ensure interoperability, he continued, and difficulties could result if any
of the components are lagging behind.

DOD plans to use external certificate authorities to ensure secure
interoperability between the department and its vendors and contractors,
according to the memo. "ECAs will operate under a process that delivers the
level of assurance that is required to meet business and legal
requirements," the document states.

By June 2000, DOD webservers that are not publicly accessible will need to
have a minimum of Class 3 certificates, and will use these certificates for
server authentication via Secure Sockets Layer protocol or higher, the memo
states; by October 2001, all private DOD and DOD-interest web servers will
require client identification and authentication using Class 3 user
certificates.

Incorporating the PKI policy in the tactical arena may present difficulties,
the source said. Officials will need to decide "who has the authority to do
what," he said. If an intelligence officer with access to restricted
information is killed or otherwise incapacitated, the person stepping into
his position must have the same attributes on his electronic identification
to be able to access the same information, he said, and it is difficult to
plan ahead for that type of contingency.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA18149 for ietf-pkix-bks; Wed, 12 May 1999 17:58:33 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA18145 for <[e-mail]>; Wed, 12 May 1999 17:58:21 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id LAA25164 for <[e-mail]>; Thu, 13 May 1999 11:02:30 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )
Date: Thu, 13 May 1999 10:59:14 +1000
Message-ID: <001101be9cdb$d42555a0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The unique monotonic etc serialNumber is critical when you have to resolve
'who was the first' argument between two stamps, having the same time value.
This may well happen if the resolution of the clock is relatively low, and
two requests entered the TS server virtually simultaneously. Think about
on-line betting, auctions, etc.

Defining serialNumber OPTIONAL will make it very confusing for a client who
relies on the sequence as well as on the time itself.

And I would be deadly scared of seeing something like "if more than one time
stamp are generated with the same time value, then TSA MUST include
serialNumber into the TSTInfo. Otherwise, the field may not be present ...".

MichaelZ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15722 for ietf-pkix-bks; Wed, 12 May 1999 11:29:34 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA15718 for <[e-mail]>; Wed, 12 May 1999 11:29:33 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 12 May 1999 18:30:53 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA04263 for <[e-mail]>; Wed, 12 May 1999 14:30:34 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <KVQTPYQ0>; Wed, 12 May 1999 14:34:29 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: [e-mail]
Subject: RE: Attributes within PK certs?
Date: Wed, 12 May 1999 14:36:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David Kemp wrote, excerpting: 

> But although algorithm parameters and extensions can both be profiled
> to hold attributes within communities of interest, I do not believe it
> would be architecturally sound for a community as large as PKIX to
> profile such practices.  Instead, PKIX should do everything possible
> to encourage the distinction between identification and authorization;
> allowing PK certs on the Internet scale to be long-lived and
> (relatively) simple.  Standardized authorization structures, wherever
> they are carried, will be a long time in coming.  Standardizing the
> placement of attributes in PK certs will, IMO, delay the availability
> of AC-enabled applications far more than it would accelerate the
> availability of cert-based authorization.
> 

Futures are hard to predict, but I'll venture an alternate view.  If
authorization attributes can be represented only in separate ACs, this means
that they can't be used until certificate-using protocols and their
implementations evolve to represent, transport, and support ACs as well as
PKCs.  If attributes could also be represented within (non-critical) PKC
extensions, a principal could obtain and use a common PKC to interoperate
with peers recognizing the attributes and (in an identity-based mode,
without the benefit of attribute-accorded rights) with other peers who don't
recognize attributes.  Depending on implementation structure, the
distinction might be confined within security modules invoked for
certificate processing, largely insulated from calling applications. By
incurring fewer dependencies on certificate-using applications, and allowing
incremental migration to attribute usage, this option could simplify rather
than delay attribute enablement. Its availability wouldn't preclude use of
separate ACs when supported and/or necessary to accomodate diverse
administrative structures or validity periods. 

--jl


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15663 for ietf-pkix-bks; Wed, 12 May 1999 11:22:31 -0700 (PDT)
Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15659 for <[e-mail]>; Wed, 12 May 1999 11:22:30 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by smtp4.ny.us.ibm.COM (8.8.8/8.8.7) with ESMTP id OAA26930; Wed, 12 May 1999 14:23:47 -0400
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v1.8) with SMTP id OAA17252; Wed, 12 May 1999 14:24:42 -0400
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id 8525676F.006520A4 ; Wed, 12 May 1999 14:24:34 -0400
X-Lotus-FromDomain: IBMUS
To: "Juan G. de la Vega" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 12 May 1999 14:24:27 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

     The object ID of a composite hash algorithm will uniquely determine the
order in which the component hashes are to be placed.  The object ID of such an
algorithm will be an ordinary-looking OID.    A typical example would be roughly
as follows:

SHA1_then_MD5  ::=  OBJECT IDENTFIER     { hash_root  7 }
     -- the value of this hash will consist of 36 octets.  The first 20 octets
consist of the output
     -- of the SHA1 algorithm on the input data, and the last 16 octets consist
of the output of
     -- the MD5 algorithm on the input data.

     There should be no greater problem in interpreting this object ID than that
of any other hash algorithm.  I believe that several such algorithm ID's should
be defined and published in a standard location.  These could be used for many
signature applications, and not just for time stamps.

          Tom Gindin




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15559 for ietf-pkix-bks; Wed, 12 May 1999 11:10:19 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA15555 for <[e-mail]>; Wed, 12 May 1999 11:10:17 -0700 (PDT)
Received: 	id OAA25875; Wed, 12 May 1999 14:10:15 -0400
Received: by gateway id <J96LDHTG>; Wed, 12 May 1999 14:12:41 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BE23@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: "'Paul Koning'" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Wed, 12 May 1999 14:12:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul;

The intent was for precision to mean the delta between the time value and
the actual UTC when it was issued.  How about if I change the example to
"This precisionFactor would account for  50-Hz (20ms) or 60-Mh (16.67ms)
power-frequency clocks that are closely synchronized to UTC, for example."

	Robert.

> ----------
> From: 	Paul Koning[SMTP:[e-mail]]
> Sent: 	Wednesday, May 12, 1999 1:26 PM
> To: 	[e-mail]
> Cc: 	[e-mail]; [e-mail]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> >>>>> "Robert" == Robert Zuccherato <[e-mail]>
> writes:
> 
>  >> Comment4 The description of the precision field is somehow
>  >> difficult to understand, and the name 'precision' is
>  >> misleading. It is not a precision, it is the precision factor. I
>  >> had to guess that 31.25 is actually a product of division of 1 by
>  >> 32.  My suggestion would be: "The precisionFactor field is an 8
>  >> bit signed integer. The actual precision of the clock is
>  >> calculated as a power(2, precisionFactor). Negative
>  >> precisionFactor value produces a precision as a fraction of a
>  >> second - for instance, precisionFactor=-5 would yield 2^(-5) =
>  >> 0.03125 sec (31ms). This precisionFactor would account for the
>  >> 50-Hz (20ms) or 60-Mh (16.67ms) power-frequency clock, for
>  >> example. Note that this method defines a precision of a clock as
>  >> 'being around the value', not as an exact figure."
>  >> 
>  Robert> Your wording is probably easier to understand.  Absent any
>  Robert> objections, I will use that.
> 
> I have a concern but it is common to the existing text and the
> proposed new text.
> 
> The term "precision" is not defined.  Several interpretations are
> possible, but the most natural one is contradicted by the example.
> 
> If the intent is that it indicates merely the step size of the local
> clock, the name should be "resolution", defined as the delta between
> one time value and the immediately following distinct time value.
> 
> If the intent is that it indicates the worst case error, i.e., the
> delta between the time value and the actual UTC when it was issued,
> "precision" is ok ("tolerance" might be even clearer).  But in that
> case, the example is misleading; while the tolerance of a 50 Hz clock
> clearly can't be significantly smaller than 20 ms, it might very well
> be a whole lot larger.
> 
> For the latter, some examples might be: (1) a fine resolution clock
> closely synchronized to UTC, for example with GPS -- 1 ms.  (2) a
> typical computer's clock synchronized to UTC once a day: 8 seconds.
> 
> Given a choice between the two interpretations, I strongly prefer the
> latter (i.e., tolerance w.r.t UTC); reporting resolution seems rather
> pointless. 
> 
> 	paul
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15476 for ietf-pkix-bks; Wed, 12 May 1999 10:58:29 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA15472 for <[e-mail]>; Wed, 12 May 1999 10:58:27 -0700 (PDT)
Received: 	id NAA20324; Wed, 12 May 1999 13:56:39 -0400
Received: by gateway id <J96LDH3W>; Wed, 12 May 1999 13:59:05 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BE22@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Juan G. de la Vega'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Wed, 12 May 1999 13:59:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id KAA15473
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juan;

As I stated at the time, since this protocol relies on signatures to
preserve the integrity of the time stamp token, and signing algorithms make
use of hashes, if SHA-1 is broken, for example, then no time stamp token
will be trusted.  Thus, adding more hashes will not improve the security of
the protocol.

I am also concerned that TSA's will begin demanding that 3 (or 4 or 5)
different message imprints be included within the request, in order to make
it more "secure".  Or that verifiers will begin to be required to verify
every message imprint (even though you only really need to verify one
imprint).  This will make client tools much more complex.  

Since the benefits of including a SEQUENCE OF Message Imprint are dubious,
there are possibly negative consequences, and there doesn't appear to be a
great deal of support for including it, I left it out.

	Robert.

> ----------
> From: 	Juan G. de la Vega[SMTP:[e-mail]]
> Sent: 	Wednesday, May 12, 1999 7:06 AM
> To: 	[e-mail]
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> Hi there,
>  
>     I would like to make use of this new draft announcement to recall an
> old discussion on the messageImprint field which seems not to have been
> solved at sigth of this new draft:
>  
>     The question of using a SEQUENCE OF MessageImprint instead of the
> single MessageImprint arised on the basis of strenghtening the relation
> beetwen the digital object to be stamped and the representation of that
> object (i.e. message digests) in a way that beared possible weaknesses in
> one of the hash functions used to obtain that representation.
>     In order to address this without modifying the syntax, the use of
> "composite" OIDs was proposed (i.e. valid OID could be "SHA1++MD5"),
> besides this is not specified in the draft, it doesn´t seem to be a very
> good idea and this is my personal opinion; a structure "SEQUENCE OF" would
> be more appropriate there, not just because the number of OIDs grows
> exponentially (assuming an agreed method for sorting the hashes) with the
> number of hash functions, but for some other reasons:
> 
>  
>     On one hand, the use of a "SEQUENCE OF" would replace the presently
> optional field "messageImprint". There is no need for this new field to be
> declared optional since an "empty sequence" may be used. Therefore this
> becomes a wherewithal to reduce optional fields (I can remember someone
> complained about that).
> 
>  
>     On the other hand this new structure preserves interoperability; TST
> verification software may not understand an agreed "composite OID" in
> which agreement it did not take part (i.e. a verifier trying to validate a
> token issued by some other TSA that agreed a new OID with ITS clients).Not
> understanding the OID it would be unable to process the associated value.
> It seems more natural to me that a client software "scans" a sequence of
> hashes looking for those it knows and trusts...
>  
> bye,
>  
> Juan.
> ____________________________________________
> Juan González-de-la-Vega
> Software Engineer
> e-mail: < [e-mail]>
> FNMT - Fábrica Nacional de Moneda y Timbre
> Phone: [phone].
> Fax: [phone]
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15184 for ietf-pkix-bks; Wed, 12 May 1999 10:25:57 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15180 for <[e-mail]>; Wed, 12 May 1999 10:25:55 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA27159; Wed, 12 May 1999 19:28:39 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 12 May 1999 19:28:38 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id TAA21643; Wed, 12 May 1999 19:28:34 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id TAA15741; Wed, 12 May 1999 19:28:33 +0200
Date: Wed, 12 May 1999 19:28:33 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-01.txt comments
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The need for the tag is also specific to the use models. Here again, what is
> being attempted here - to audit who is doing what and to whom? For what
> purpose?
Right, that seems to be the question.
> 
> >
> > For example if one uses an e-mail based service, the request would
> > probably have a message-id in the header and the response may use
> > an in-reply-to or references.
> 
> I agree a tag is necessary to identify the applications, how ever I would
> like to see something larger than a tag. Say I want to authenticate, end to
> end, that a particular application sent the logging server a message for
> logging. I would want  to store a branding token from the app itself in the
> timestamp structure to support identifying which app and which specific
> instance of it did the deed.
> 
> Here again the missing piece would be a standard way of watermarking  or
> branding executables so that they could identify themselves. My feeling is
> that this is a much bigger issue than people think.
I don't think that AUTHENTICATION is the demand. The demand seems to be
to simplify the implementation of a kind 'high level datagram oriented'
protocol, where the process that issues the request does not immediately
receive a response on a full duplex channel, AND it may be somewhat 
difficult to associate the response to the request. In any case, I do not
see a need for some 'tag' inside the signed portion of the response. 

> 
> >In the ftp case you may need a
> > convention what filenames to use.
> >
> > Comment2: The sequence number is use when you want a
> >
> >  "strictly monotonically increasing Integer from one TimeStampToken
> >   XXXXXXXX
> >  to the next."
> >
> > If you don't have a sequence number, you don't have "strictly".
> >
> > There is no need to always provide unique time stamps for certain
> > types of service. The 'stamps' from a real postal service are
> > within a precision of half an hour or even less for example.
> 
> Peter, pardon my reply here, but this comment is both out of context,
> generally wrong, and irrelevent to commercial timestamping.
> 
> If you are trying to create a postal processing system, wherein you only see
> (or contact) the postal agent once a day, then the issue of the
> date/timestamp may be OK. But by the way, the actuality of when you deposit
> mail with the post office and when it is stamped is also a mystery in most
> instances, except to say, that the mail will be cancled when it is
> processed, and that is the time that it will have stamped on it. So in
> reality, unless the mail is hand canceled, what you get stamped on the mail,
> is the "when they got around to it" time which in most instance is within 24
> hrs of depositing the mail with "them".
Aren't you just confirming what I had said?  The time stamp that you received
for a registered mail is not necessarily a UNIQUE value.

Why is this comment out of context? My context was to try to explain
why sequence number may be optional and not required for all services.
The weak precision of real postal service time stamps 
is only an illustration of a situation where unique time stamps do not occur
when you just county seconds or minutes or whatever. There are time stamping
services that include strict sequencing (so you could use them to solve
problems about who did something before someone else.)

But for example to get a time stamp to indicate that
I have filed early enough my tax declaration, neither me nor the
verifying cares whether the time stamps are unique. The stamps are
recognised by both parties as being the authoritive indication of 
some time, not more.


> > Comment4: Why just 8 bits signed integer for a precision. The encoding
> >           is just an integer.
> >           The fractionofSecond definition is not quite nice for
> >           a display. A power of 10 seems more appropriate. In fact
> >           I do not see at all why it should be an integer: The
> >           genTime is a STRING, thus fractionOfSecond would probably
> >           better be a NumericalString, so a display may simply
> >           concatenate   genTime '.' franctionOfSecond
> 
> My feeling is that *any* timestamp structure MUST be able to support time
> resolution into the MicroSeconds, and if the Draft McNeil and I are about to
> send, you will see we have done just this. AQlso the structure should be
> totally binary in nature. The who of who is using it is a computer, so keep
> it digital.
Human beings don't think in binary terms.
Or, then generaltime should also be a binary? 

Time stamping is something else than providing a good value of time. ??

> >           Whether the precision is really needed in this case is
> >           another matter. Shouldn't it be optional?
> 
> No, the precision of the stamp structure is part of what's being
> standardized and so it should be fixed, IMHO.

Where is this roadmap defined? IMHO the time stamping text does not
necessarily define a trustworthy replacement of an NTP protocol. 
If one can have a protocol that can handle that, why not, but that's 
not all.  

Regards
P



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15170 for ietf-pkix-bks; Wed, 12 May 1999 10:25:11 -0700 (PDT)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15166 for <[e-mail]>; Wed, 12 May 1999 10:25:10 -0700 (PDT)
Received: from xedia.com by relay3.UU.NET with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQgoxh13334; Wed, 12 May 1999 13:26:44 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA18372; Wed, 12 May 99 13:26:07 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA02178; Wed, 12 May 1999 13:26:38 -0400
Date: Wed, 12 May 1999 13:26:38 -0400
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
References: <01E1D01C12D7D211AFC70090273D20B112BE1F@sothmxs06>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>>>> "Robert" == Robert Zuccherato <[e-mail]> writes:

 >> Comment4 The description of the precision field is somehow
 >> difficult to understand, and the name 'precision' is
 >> misleading. It is not a precision, it is the precision factor. I
 >> had to guess that 31.25 is actually a product of division of 1 by
 >> 32.  My suggestion would be: "The precisionFactor field is an 8
 >> bit signed integer. The actual precision of the clock is
 >> calculated as a power(2, precisionFactor). Negative
 >> precisionFactor value produces a precision as a fraction of a
 >> second - for instance, precisionFactor=-5 would yield 2^(-5) =
 >> 0.03125 sec (31ms). This precisionFactor would account for the
 >> 50-Hz (20ms) or 60-Mh (16.67ms) power-frequency clock, for
 >> example. Note that this method defines a precision of a clock as
 >> 'being around the value', not as an exact figure."
 >> 
 Robert> Your wording is probably easier to understand.  Absent any
 Robert> objections, I will use that.

I have a concern but it is common to the existing text and the
proposed new text.

The term "precision" is not defined.  Several interpretations are
possible, but the most natural one is contradicted by the example.

If the intent is that it indicates merely the step size of the local
clock, the name should be "resolution", defined as the delta between
one time value and the immediately following distinct time value.

If the intent is that it indicates the worst case error, i.e., the
delta between the time value and the actual UTC when it was issued,
"precision" is ok ("tolerance" might be even clearer).  But in that
case, the example is misleading; while the tolerance of a 50 Hz clock
clearly can't be significantly smaller than 20 ms, it might very well
be a whole lot larger.

For the latter, some examples might be: (1) a fine resolution clock
closely synchronized to UTC, for example with GPS -- 1 ms.  (2) a
typical computer's clock synchronized to UTC once a day: 8 seconds.

Given a choice between the two interpretations, I strongly prefer the
latter (i.e., tolerance w.r.t UTC); reporting resolution seems rather
pointless. 

	paul


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15159 for ietf-pkix-bks; Wed, 12 May 1999 10:24:14 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA15155 for <[e-mail]>; Wed, 12 May 1999 10:24:12 -0700 (PDT)
Received: 	id NAA06654; Wed, 12 May 1999 13:22:37 -0400
Received: by gateway id <J96LDHFF>; Wed, 12 May 1999 13:25:03 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BE21@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Peter Sylvester'" <[e-mail]>
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments
Date: Wed, 12 May 1999 13:24:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter;

My comments are below.

> ----------
> From: 	Peter Sylvester[SMTP:[e-mail]]
> Sent: 	Wednesday, May 12, 1999 4:54 AM
> To: 	[e-mail]
> Subject: 	draft-ietf-pkix-time-stamp-01.txt comments
> 
> Comment4: Why just 8 bits signed integer for a precision. The encoding
>           is just an integer.
> 
Given that some people did not want any precision at all.  I think that 8
bits is a good compromise.

>           The fractionofSecond definition is not quite nice for
>           a display. A power of 10 seems more appropriate. In fact
>           I do not see at all why it should be an integer: The
>           genTime is a STRING, thus fractionOfSecond would probably
>           better be a NumericalString, so a display may simply
>           concatenate   genTime '.' franctionOfSecond
> 
>           Whether the precision is really needed in this case is
>           another matter. Shouldn't it be optional?
> 
If you do not want any greater precision than that offered by
GeneralizedTime, you can put a 1 value in fractionOfSecond and 0 in
precision.  Thus, no one is forced to use greater precision than they want.
>              
> 2.1. Requirements of the TSA
> 
> The TSA is REQUIRED:
>      1. to provide a trusted source of time.
>                      trustworthy ?? 
> 
Either is fine with me.

>      2. not to include any identification of the requesting entity in 
>         the time stamp token.
> 
>      3. to include a monotonically incrementing value of the time of day 
>         into its time stamp token.
>                             tokens.      
> 
Sure.

>      4. to produce a time stamp token upon receiving a valid request 
>         from the requester.
> What does this mean if the TSA can ignore the request due to overrun?
> See security section 4.5 ??
> 
I don't see a conflict.  But to make things more clear, how about:
4. to produce a time stamp token upon receiving a valid request 
        from the requester, when this is possible.

>      5. to include within each time stamp token an identifier to 
>         uniquely indicate the trust and validation policy under which
>         the token was created.
> The policy is optional, isn't it?
> 
No, it is not optional in TSTInfo.

>      6. to only time stamp a hash representation of the datum, i.e. a
>         data imprint associated with a one-way collision resistant hash-
>         function OID.
> 
>      7. to examine the OID of the one-way collision resistant hash-
>         function and to verify that this function is "sufficient" (see
>         Section 2.4). 
> The text later on does not specify what kind of error should be returned.
> Shouldn't there be an error code in the PKIFailureInfo? Or is this
> badAlg or badRequest ?
> 
I was under the impression that badAlg would cover that.

>      8. not to examine the imprint being time stamped in any way. 
> What does THAT mean? If you keep a log of requests/tokens, are you
> 'examining' the request?  
> 
No, I wouldn't think that keeping a log would constitute "examining" the
request.  This requirement simply means that the TSA cannot attempt to
determine any information about the message from the imprint, that may
inadvertently leak out.
>     
>      9. to sign each time stamp token using a key generated exclusively 
>         for this purpose and have this property of the key indicated on 
>         the corresponding certificate.
> 
>     10. to include supplementary temporal information in the time stamp 
>         token (from TDA's) if asked by the requester.  If this is not 
>         possible, the TSA shall respond with an error message.
> Would it be possible to respond with a 'modified answer' 
> and simply not including the missing TDAs in the token.
> The application could decide how to interprete the result? I don't really
> care.  
> 
It is possible to do that now, I believe.  The TSA could respond with
PKIStatus having value (1) grantedWithMods, which is an error message, and
not include the missing TDAs.

>     11. to provide a signed receipt (i.e. in the form of an 
>         appropriately defined time stamp token) to the requester, where 
>         appropriate, as defined by policy.
> 
> The definition of TSTTime (or TSTInfo) does not say what should
> put as time in case of a PKIStatus rejected especially when
> 
>     timeNotAvailable {14},
>       -- the TSAs time source is not available
> 
Actually, we say:
"When issuing an error response with PKIFailureInfo having value 
timeNotAvailable (14) then the TSA MAY place any value (e.g. a random 
value, the closest approximation available, or a fixed value) in the 
tstTime field of TSTInfo.  Upon receiving such an error response a 
client MUST not trust the time contained in the tstTime field."

> A small wording change in the following:
> 
>      6. A CA shall normally conduct a test for proof of possession for 
>         each user's signing private key (including the TSA/TDA signing 
>         private key). However, in some environments, the CA might not 
>         perform a proof-of-possession of the private key when issuing 
>         certificates. In these instances, in order to prevent certain
>         attacks and to properly check the validity of the binding 
>         between an end entity and a key pair, a certificate identifier 
>         of the TSA/TDA shall be included as a signed attribute.
> 
>                                               the signature MUST contain
>         an ESSCertID authenticated attribute.
> 
> see also the wording in:
> 
> certificate that is to be used to verify the token.  This field MAY be 
> omitted if the Signing Certificate Attribute has been included as a 
> signed attribute.  (See Section 5 of [ESS].)  It MUST be present if the 
> ESSCertID Attribute is not used to identify the TSA.
> 
Fair enough.


> The socket based protocol does not seem to follow the requirements
> of not giving non signed responses.
> 
Actually, we say a response "is or includes a TimeStampToken".  So the
unsigned messages within the socket based protocol do not contradict this
requirement.
>  
> In fact, there seems to be some confusion in layers. What is considered
> as 'not respond' in a context of http for example. You cut the
> connection? You just let the connection time out? 
> 
>         produce a valid response before responding, if this is possible.  
>         If this is not possible, it MUST ignore the requests and not 
>                                     ????????????????????????????????
>         respond.
>         ???????
> 
> It seems to me that the socket based protocol is basically designed
> as an internal protocol among a front end transaction based http 
> and a back end signing entity for example, thus operated in a different
> security context; no problem with that. 
> 
> In general I guess it is necessary to make a precise definition what means
> 'returning a response', 'not returning a response' depending on each
> lower layer, especially for http, 'document contains no data' = 0 length
> response or time out.  
> 
See comment above.

> > A simple MIME object is specified as follows.
> 
> >    Content-Type: application/timestamp
> >   Content-Transfer-Encoding: base64
> 
> >   <<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
> No: An appropriate, content preserving transfer encoding should be used.
> Someone can reencode in quoted-printable or whatever. 
> 
> Which method should be used in http to send a request. 
> (POST ??) PUT?? Don't care?? 
> 
I don't really have an opinion about these.  If someone with a strong
opinion wants to suggest something, that would be fine.

> > This MIME object can be sent and received using common HTTP processing
> > engines over WWW links and provides a simple browser-server transport
>                                                CLIENT
> > for Time Stamp messages.
> 
>      1. When there is a reason to believe that the TSA/TDA can no longer
>         be trusted, the authority's certificate MUST be revoked and 
>         placed on the appropriate CRL.  Thus, at any future time the 
>         tokens signed with the corresponding key will not be valid.
> 
> Tokens with a time superior than the end of validity are not valid.
> 
I would think not.

> And telling HOW a ca should act should not be the business of this
> text. There might be OCSP for example.
> 
True.  I will modify the sentence to not prejudice any particular revocation
method.

> It seems that a paragraph about configuration is missing:
> 
> - what URI should be used?
> - How do I get a trustworthy certificate
> 
> One suggestion that minimises the two parameters into one:
> 
> A certificate of a TSA/TDA may contain an AIA with 
> id-kp-temporalDataAuthority and an URL. 
> 
> and to say that it is a local matter of an application to decide
> which time stamp service is 'trustworthy'. 
> 
This is probably a good idea.

> Appendix A:
> 
> For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute 
> type.  This attribute type specifies the time stamp token, which MUST be 
>                                                                  can
> included as a signed attribute of the SignedData object. 
> 
Sure.

Thanks for your comments.

	Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA14677 for ietf-pkix-bks; Wed, 12 May 1999 09:20:43 -0700 (PDT)
Received: from ridge.spiritone.com (ridge.spiritone.com [205.139.108.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA14673 for <[e-mail]>; Wed, 12 May 1999 09:20:42 -0700 (PDT)
Received: from cme (m6-244.spiritone.com [208.130.240.244]) by ridge.spiritone.com (8.8.8/8.8.8) with SMTP id JAA16244; Wed, 12 May 1999 09:23:06 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 12 May 1999 09:22:43 -0700
To: Ari Huttunen <[e-mail]>
From: Carl Ellison <[e-mail]>
Subject: Re: X.509 ACs vs. SPKI?
Cc: [e-mail], [e-mail], Carl Ellison <[e-mail]>, Carl Ellison <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----

Hi Ari.

At 12:56 PM 5/12/99 +0300, Ari Huttunen wrote:
>Hi,
>
>Has someone made a comparison of what can / cannot be done 
>in X.509 Attribute Certificates (draft-ietf-pkix-ac509prof-00.txt)
>that can be done with SPKI certificates? Would there be some ideas
>in SPKI that could be used to enhance X.509 ACs?
>
>My aim here is very pragmatic. I don't observe SPKI as going
>forward, so I would like X.509 ACs to be able to do as much as
>possible...

I perceive SPKI going forward.  I'm currently doing an implementation at 
Intel, for example, and there are others doing implementations elsewhere.  
The first 2 of 4 drafts have been given to the group co-chairs for approval 
for giving to the group to go for RFC.  I have been slow getting those out, 
which may be why you don't perceive action.

OTOH, your question deserves an answer.  I remember David Kemp suggesting 
that the X.509 community would borrow from SPKI but would probably never 
give up its love affair with ASN.1, so the SPKI ideas would be incorporated 
into X.509 somehow but not exactly.

>For the sake of conversation, here's a proposal how SPKI certificates
>could be put inside X.509 ACs. I certainly do not claim that this
>works as-is, but it might be made to work.
>
>1) The server checking X.509 ACs is also acting as the CA that
>   issues those ACs.
>
>2) The SPKI certificate security fields are mapped as follows:
>   Issuer = refers to the X.509 certificate of the server.
>   Subject = refers to the X.509 certificate of the client.
>   Delegation = ..as in SPKI..
>   Authority = ..as in SPKI..
>   Validity = attrCertValidityPeriod


I see three problems doing the equivalent of SPKI within X.509 and in 
particular with ACs.

1.	The identification of issuer and subject is convoluted at best.  Missing 
is the option that is needed for maximum security (not to mention 
anonymity): a public key or the hash of the key.  The IssuerSerial option is 
subject to constraints not expressed in the certificate.  GeneralNames isn't 
constrained or defined, AFAIK, in this spec, so that too depends on 
constraints not evident in the certificate.  The ObjectDigestInfo might be 
used to refer to some public key, but that use isn't spelled out -- and even 
then, it is only the subject ID that has this option so identification of 
the Issuer is left troubled.

2.	X.509 does not define the semantics of a certificate, only the syntax.  I 
find this especially when mapping out the CDSA extensions that extract SPKI 
authorization information from existing X.509 certificates (so that our 
implementation will accept and use a mixture of certificate types: X.509, 
PGP, SPKI, ....).  Interpreting an X.509v3 certificate requires a different 
trust policy module (in CDSA terms -- the code module that understands the 
semantics of each field) for each different CPS -- or, to an approximation, 
for each different root key.  For example, SET cardholder certificates 
define an authorization (permission to use a given PAN/EXP) but plant that 
authorization in the CommonName field of the SubjectName.  Meanwhile, some 
extensions of the SET certificate carry authorization information while 
others are to be used for chain validation only.

3.	X.509 may be able to define SDSI names, but there is no mechanism for 
referring to a fully qualified SDSI name.  That means that the only 
mechanisms for making an SPKI attribute certificate (one that gives an 
authorization to a named entity or group) have to rely on assumptions about 
naming conventions.  In particular, I see no way to express:

	(name <key> N_1 N_2 ... N_k)

in X.509.

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

I've speculated before that one could make an X.509v4 correcting these 
problems, but I'm doubtful.  X.509 has a lot of baggage that would be 
traumatic to discard.  It also has a belief system that could be even more 
troublesome: that a certificate is a signed document that's entirely up to 
the interpreting code to understand.  This allows single-application CA and 
verification applications, but does not lend itself to multiple-application 
code.

 - Carl


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1b15

iQCVAwUBNzmq0hN3Wx8QwqUtAQGZjgP/TKTp1flc875QIwYWOa7xrqKWt6nKtZ+H
yTZ8loH6Ln0kzurLgwKLK3HauJMnqv29y+IooAI9d3w3HFQL+Ijodg1vXyOBFv5N
fJHDQ8iyn9kCyNKwCJiMdmuwPgyqqAo6X2PlQWEVirZsWqRKru/NT5UL1esKTvC7
g5rSkimwP/E=
=wSAV
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison         [e-mail]     http://www.pobox.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA14176 for ietf-pkix-bks; Wed, 12 May 1999 08:32:47 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA14172 for <[e-mail]>; Wed, 12 May 1999 08:32:44 -0700 (PDT)
Received: 	id LAA28732; Wed, 12 May 1999 11:31:16 -0400
Received: by gateway id <J96LDGMP>; Wed, 12 May 1999 11:33:41 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BE1F@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: "'PKIX mailing group'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Wed, 12 May 1999 11:33:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael;

My responses are below.

> ----------
> From: 	Michael Zolotarev[SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Wednesday, May 12, 1999 2:46 AM
> To: 	'Robert Zuccherato'; 'PKIX mailing group'
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> Comment1.
> The new draft does not address the problem of defining an optional 'tag'
> field to help associating a stamp with its origin.
> The need for the tag has been discussed intensively by the mail group, and
> I
> do not recall anybody arguing against it.
> 
As I said at the time, I'm not against this.  However, my records show that
there was also a counter-proposal asking that this information not be
included in the request (in order to prevent leakage of information to the
TSA), but that a new structure be defined in an annex that includes both the
tag and the presently defined token ("3 Time Stamping issues" from Denis
Pinkas on April 1, 1999).  This proposal also had some support and there was
the suggestion that the tag could be included by the requester as an
unauthenticated attribute in the token.  It was my impression that this was
acceptable to all.  However, in order to include this unauthenticated
attribute in an annex, I will need a concrete proposal and some text.

> Comment2
> The SerialNumber is defined as OPTIONAL. The need for having it is clear,
> it
> is not anyhow request-specific, or a difficult thing to implement for the
> TSA. So why is it optional?
> 
Actually, it isn't clear to me that it should be mandatory.  I may be wrong,
but it seems to me that the serial number is only required if the
application is going to be referring to tokens without actually presenting
the tokens themselves (i.e. issuer and serial number).  It isn't clear to me
that this will always be the case (unlike with certificates, for example).
Thus, I am reluctant to mandate their use.  

> Comment3
> in TSTInfo: "TSA services MAY produce "signed times" which are timestamp
> tokens that do not contain a nonce or message imprint and are thus not
> linked to any request". Does it mean that a stamp with the imprint but
> without a nonce is regarded as a 'signed time'.
> 
No.  Signed times are "timestamp tokens that do not contain a nonce or
message imprint".  

> Comment4
> The description of the precision field is somehow difficult to understand,
> and the name 'precision' is misleading. It is not a precision, it is the
> precision factor. I had to guess that 31.25 is actually a product of
> division of 1 by 32.
> My suggestion would be:
> "The precisionFactor field is an 8 bit signed integer. The actual
> precision
> of the clock is calculated as a power(2, precisionFactor). Negative
> precisionFactor value produces a precision as a fraction of a second - for
> instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec (31ms). This
> precisionFactor would account for the 50-Hz (20ms) or 60-Mh (16.67ms)
> power-frequency clock, for example. Note that this method defines a
> precision of a clock as 'being around the value', not as an exact figure."
> 
Your wording is probably easier to understand.  Absent any objections, I
will use that.

> Comment5.
> The socket based protocol is apparently borrowed from the CMP spec. Should
> we stop being shy, make one more step forward, and expand the CMP-defined
> messages by adding TSA messages? That is, the message will contain a
> proper
> PKIHeader (as defined by the CMP), and the PKIBody with ID=XXX (XXX > 23,
> as
> 23 is the last ID reserved by the CMP). The actual PKIBody would be the
> DER-encoded TSA message.
> This would set a good example for other PKI services, such as AC and
> Notary.
> 
I am hesitant to require the extra layer when it isn't really required.  The
PKIHeader would serve no purpose here.

	Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13528 for ietf-pkix-bks; Wed, 12 May 1999 07:18:21 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13524 for <[e-mail]>; Wed, 12 May 1999 07:18:20 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26663; Wed, 12 May 1999 10:20:31 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-04.txt
Date: Wed, 12 May 1999 10:20:30 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New 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		: Certificate Management Messages over CMS
	Author(s)	: X. Liu, M. Myers, J. Weinstein, J. Schaad
	Filename	: draft-ietf-pkix-cmc-04.txt
	Pages		: 40
	Date		: 11-May-99
	
This document defines a Certificate Management protocol using CMS (CMC).
This protocol addresses two immediate needs within the Internet PKI
community:
 
1. The need for an interface to public key certification products and
   services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-
   signed certificates with Diffie-Hellman public keys.
 
A small number of additional services are defined to supplement the core
certificate request service.
 
Throughout this specification the term CMS is used to refer to both [CMS]
and [PKCS7].  For signedData the two specifications are equivalent.  For
envelopedData CMS is a superset of the PKCS7. In general, the use of
PKCS7 in this document is aligned to the Cryptographic Message Syntax
[CMS] that provides a superset of the PKCS7 syntax. The term CMC refers
to this specification.
 
The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in
this document are to be interpreted as described in [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-04.txt

Internet-Drafts are also 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-cmc-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-04.txt".
	
NOTE:	The mail server at ietf.org 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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA13435 for ietf-pkix-bks; Wed, 12 May 1999 07:09:17 -0700 (PDT)
Received: from penguin.prod.itd.earthlink.net (penguin.prod.itd.earthlink.net [207.217.120.134]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA13431 for <[e-mail]>; Wed, 12 May 1999 07:09:16 -0700 (PDT)
Received: from brick (dialup-209.245.131.88.SanJose1.Level3.net [209.245.131.88]) by penguin.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id HAA24040; Wed, 12 May 1999 07:11:50 -0700 (PDT)
Message-ID: <062001be9c81$5b8db380$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-01.txt comments
Date: Wed, 12 May 1999 07:10:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter, I disagree with a good bit of your commentary.

----- Original Message -----
From: Peter Sylvester <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, May 12, 1999 1:54 AM
Subject: draft-ietf-pkix-time-stamp-01.txt comments


> I have forgotten to include the group in the following message.
>
> I profit from the occasion to comment Michael Zolotarev's remarks:
>
> Comment1: The need for a tag had indeed been discussed, but is it
> clear at which protocol level a tag is needed, i.e. is this an
> issue of some underlying transport protocol, or would the tag be included
> in the signature of the response?

The need for the tag is also specific to the use models. Here again, what is
being attempted here - to audit who is doing what and to whom? For what
purpose?

>
> For example if one uses an e-mail based service, the request would
> probably have a message-id in the header and the response may use
> an in-reply-to or references.

I agree a tag is necessary to identify the applications, how ever I would
like to see something larger than a tag. Say I want to authenticate, end to
end, that a particular application sent the logging server a message for
logging. I would want  to store a branding token from the app itself in the
timestamp structure to support identifying which app and which specific
instance of it did the deed.

Here again the missing piece would be a standard way of watermarking  or
branding executables so that they could identify themselves. My feeling is
that this is a much bigger issue than people think.

>In the ftp case you may need a
> convention what filenames to use.
>
> Comment2: The sequence number is use when you want a
>
>  "strictly monotonically increasing Integer from one TimeStampToken
>   XXXXXXXX
>  to the next."
>
> If you don't have a sequence number, you don't have "strictly".
>
> There is no need to always provide unique time stamps for certain
> types of service. The 'stamps' from a real postal service are
> within a precision of half an hour or even less for example.

Peter, pardon my reply here, but this comment is both out of context,
generally wrong, and irrelevent to commercial timestamping.

If you are trying to create a postal processing system, wherein you only see
(or contact) the postal agent once a day, then the issue of the
date/timestamp may be OK. But by the way, the actuality of when you deposit
mail with the post office and when it is stamped is also a mystery in most
instances, except to say, that the mail will be cancled when it is
processed, and that is the time that it will have stamped on it. So in
reality, unless the mail is hand canceled, what you get stamped on the mail,
is the "when they got around to it" time which in most instance is within 24
hrs of depositing the mail with "them".

All in all, the 200+ year old postal process is changing and since
Electronic Mail and Document Processing systems are moving into digital and
operating 7x24 hrs and your comment doesn't seem to make sense to me in
light of this.

>
> Comment3: Is there a a De Morgan problem in the wording?

Potentially

>
> Comment4: Why just 8 bits signed integer for a precision. The encoding
>           is just an integer.
>           The fractionofSecond definition is not quite nice for
>           a display. A power of 10 seems more appropriate. In fact
>           I do not see at all why it should be an integer: The
>           genTime is a STRING, thus fractionOfSecond would probably
>           better be a NumericalString, so a display may simply
>           concatenate   genTime '.' franctionOfSecond

My feeling is that *any* timestamp structure MUST be able to support time
resolution into the MicroSeconds, and if the Draft McNeil and I are about to
send, you will see we have done just this. AQlso the structure should be
totally binary in nature. The who of who is using it is a computer, so keep
it digital.

>
>           Whether the precision is really needed in this case is
>           another matter. Shouldn't it be optional?

No, the precision of the stamp structure is part of what's being
standardized and so it should be fixed, IMHO.

>
> Comment5: There seems to be some kind of inflation of similar
>           protocols (X over Y, Y over X, ...)
>
> Peter
>
> ----- Begin Included Message -----
>
> From: Peter Sylvester <[e-mail]>
> Date: Tue, 11 May 1999 20:30:12 +0200
> To: [e-mail], [e-mail], [e-mail],
>         [e-mail]
> Subject: draft-ietf-pkix-time-stamp-01.txt comments
>
> Hi,
>
> a little bit of nit-picking (and maybe more) :-)
>
>
> 2.1. Requirements of the TSA
>
> The TSA is REQUIRED:
>      1. to provide a trusted source of time.
>                      trustworthy ??
>
>      2. not to include any identification of the requesting entity in
>         the time stamp token.
>
>      3. to include a monotonically incrementing value of the time of day
>         into its time stamp token.
>                             tokens.
>
>      4. to produce a time stamp token upon receiving a valid request
>         from the requester.
> What does this mean if the TSA can ignore the request due to overrun?
> See security section 4.5 ??
>
>      5. to include within each time stamp token an identifier to
>         uniquely indicate the trust and validation policy under which
>         the token was created.
> The policy is optional, isn't it?
>
>      6. to only time stamp a hash representation of the datum, i.e. a
>         data imprint associated with a one-way collision resistant hash-
>         function OID.
>
>      7. to examine the OID of the one-way collision resistant hash-
>         function and to verify that this function is "sufficient" (see
>         Section 2.4).
> The text later on does not specify what kind of error should be returned.
> Shouldn't there be an error code in the PKIFailureInfo? Or is this
> badAlg or badRequest ?
>
>      8. not to examine the imprint being time stamped in any way.
> What does THAT mean? If you keep a log of requests/tokens, are you
> 'examining' the request?
>
>      9. to sign each time stamp token using a key generated exclusively
>         for this purpose and have this property of the key indicated on
>         the corresponding certificate.
>
>     10. to include supplementary temporal information in the time stamp
>         token (from TDA's) if asked by the requester.  If this is not
>         possible, the TSA shall respond with an error message.
> Would it be possible to respond with a 'modified answer'
> and simply not including the missing TDAs in the token.
> The application could decide how to interprete the result? I don't really
> care.
>
>     11. to provide a signed receipt (i.e. in the form of an
>         appropriately defined time stamp token) to the requester, where
>         appropriate, as defined by policy.
>
> The definition of TSTTime (or TSTInfo) does not say what should
> put as time in case of a PKIStatus rejected especially when
>
>     timeNotAvailable {14},
>       -- the TSAs time source is not available
>
> A small wording change in the following:
>
>      6. A CA shall normally conduct a test for proof of possession for
>         each user's signing private key (including the TSA/TDA signing
>         private key). However, in some environments, the CA might not
>         perform a proof-of-possession of the private key when issuing
>         certificates. In these instances, in order to prevent certain
>         attacks and to properly check the validity of the binding
>         between an end entity and a key pair, a certificate identifier
>         of the TSA/TDA shall be included as a signed attribute.
>
>                                               the signature MUST contain
>         an ESSCertID authenticated attribute.
>
> see also the wording in:
>
> certificate that is to be used to verify the token.  This field MAY be
> omitted if the Signing Certificate Attribute has been included as a
> signed attribute.  (See Section 5 of [ESS].)  It MUST be present if the
> ESSCertID Attribute is not used to identify the TSA.
>
>
> The socket based protocol does not seem to follow the requirements
> of not giving non signed responses.
>
> In fact, there seems to be some confusion in layers. What is considered
> as 'not respond' in a context of http for example. You cut the
> connection? You just let the connection time out?
>
>         produce a valid response before responding, if this is possible.
>         If this is not possible, it MUST ignore the requests and not
>                                     ????????????????????????????????
>         respond.
>         ???????
>
> It seems to me that the socket based protocol is basically designed
> as an internal protocol among a front end transaction based http
> and a back end signing entity for example, thus operated in a different
> security context; no problem with that.
>
> In general I guess it is necessary to make a precise definition what means
> 'returning a response', 'not returning a response' depending on each
> lower layer, especially for http, 'document contains no data' = 0 length
> response or time out.
>
>
>
> > A simple MIME object is specified as follows.
>
> >    Content-Type: application/timestamp
> >   Content-Transfer-Encoding: base64
>
> >   <<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
> No: An appropriate, content preserving transfer encoding should be used.
> Someone can reencode in quoted-printable or whatever.
>
>
> Which method should be used in http to send a request.
> (POST ??) PUT?? Don't care??
>
>
> > This MIME object can be sent and received using common HTTP processing
> > engines over WWW links and provides a simple browser-server transport
>                                                CLIENT
> > for Time Stamp messages.
>
>      1. When there is a reason to believe that the TSA/TDA can no longer
>         be trusted, the authority's certificate MUST be revoked and
>         placed on the appropriate CRL.  Thus, at any future time the
>         tokens signed with the corresponding key will not be valid.
>
> Tokens with a time superior than the end of validity are not valid.
>
> And telling HOW a ca should act should not be the business of this
> text. There might be OCSP for example.
>
>
> It seems that a paragraph about configuration is missing:
>
> - what URI should be used?
> - How do I get a trustworthy certificate
>
> One suggestion that minimises the two parameters into one:
>
> A certificate of a TSA/TDA may contain an AIA with
> id-kp-temporalDataAuthority and an URL.
>
> and to say that it is a local matter of an application to decide
> which time stamp service is 'trustworthy'.
>
> Appendix A:
>
> For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute
> type.  This attribute type specifies the time stamp token, which MUST be
>                                                                  can
> included as a signed attribute of the SignedData object.
>
>
> have fun
>
>
> ----- End Included Message -----
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA12082 for ietf-pkix-bks; Wed, 12 May 1999 04:06:33 -0700 (PDT)
Received: from fnmt.es ([194.224.76.148]) by mail.proper.com (8.8.8/8.8.5) with SMTP id EAA12078 for <[e-mail]>; Wed, 12 May 1999 04:06:31 -0700 (PDT)
Received: from [192.168.1.176] by fnmt.es (NTMail 3.02.13) with ESMTP id va001971 for <[e-mail]>; Wed, 12 May 1999 13:09:38 +0100
Message-ID: <013301be9c67$7679a240$[e-mail]>
From: "Juan G. de la Vega" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Wed, 12 May 1999 13:06:15 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_012E_01BE9C78.37430420"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_012E_01BE9C78.37430420
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi there,

    I would like to make use of this new draft announcement to recall an =
old discussion on the messageImprint field which seems not to have been =
solved at sigth of this new draft:

    The question of using a SEQUENCE OF MessageImprint instead of the =
single MessageImprint arised on the basis of strenghtening the relation =
beetwen the digital object to be stamped and the representation of that =
object (i.e. message digests) in a way that beared possible weaknesses =
in one of the hash functions used to obtain that representation.
    In order to address this without modifying the syntax, the use of =
"composite" OIDs was proposed (i.e. valid OID could be "SHA1++MD5"), =
besides this is not specified in the draft, it doesn=B4t seem to be a =
very good idea and this is my personal opinion; a structure "SEQUENCE =
OF" would be more appropriate there, not just because the number of OIDs =
grows exponentially (assuming an agreed method for sorting the hashes) =
with the number of hash functions, but for some other reasons:


    On one hand, the use of a "SEQUENCE OF" would replace the presently =
optional field "messageImprint". There is no need for this new field to =
be declared optional since an "empty sequence" may be used. Therefore =
this becomes a wherewithal to reduce optional fields (I can remember =
someone complained about that).


    On the other hand this new structure preserves interoperability; TST =
verification software may not understand an agreed "composite OID" in =
which agreement it did not take part (i.e. a verifier trying to validate =
a token issued by some other TSA that agreed a new OID with ITS =
clients).Not understanding the OID it would be unable to process the =
associated value. It seems more natural to me that a client software =
"scans" a sequence of hashes looking for those it knows and trusts...

bye,

Juan.
____________________________________________
Juan Gonz=E1lez-de-la-Vega
Software Engineer
e-mail: <[e-mail]>
FNMT - F=E1brica Nacional de Moneda y Timbre
Phone: [phone].
Fax: [phone]

------=_NextPart_000_012E_01BE9C78.37430420
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000><FONT size=3D3>Hi there,</FONT></FONT><FONT=20
size=3D3></FONT></DIV>
<DIV><FONT color=3D#000000><FONT size=3D3></FONT></FONT><FONT=20
size=3D3></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000><FONT size=3D3>&nbsp;&nbsp;&nbsp; I would =
like to make=20
use of this new draft announcement to recall an old discussion on the=20
messageImprint field which seems not to have been solved at sigth of =
this new=20
draft:</FONT></FONT></DIV>
<DIV><FONT color=3D#000000><FONT size=3D3></FONT></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; <FONT =
size=3D3>The question of=20
using a SEQUENCE OF MessageImprint instead of the single MessageImprint =
arised=20
on the basis of strenghtening the relation beetwen the digital object to =
be=20
stamped and the representation of that object (i.e. message digests) in =
a way=20
that beared possible weaknesses in one of the hash functions used to =
obtain that=20
representation.</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
size=3D3></FONT>&nbsp;&nbsp;&nbsp; <FONT=20
size=3D3>In order to address this without modifying the syntax, the use =
of=20
&quot;composite&quot; OIDs was proposed (i.e. valid OID could be=20
&quot;SHA1++MD5&quot;), besides this is not specified in the draft, it=20
doesn&acute;t seem to be a very good idea and this is my personal=20
opinion;</FONT></FONT> a structure &quot;SEQUENCE OF&quot; would be more =

appropriate there, not just because the number of OIDs grows =
exponentially=20
(assuming an agreed method for sorting the hashes) with the number of =
hash=20
functions, but for some other reasons:<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; On one hand, the use of a &quot;SEQUENCE =
OF&quot; would=20
replace the presently optional field &quot;messageImprint&quot;. There =
is no=20
need for this new field to be declared optional since an &quot;empty=20
sequence&quot; may be used. Therefore this becomes a wherewithal to =
reduce=20
optional fields (I can remember someone complained about =
that).<BR></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; On the other hand this new structure preserves=20
interoperability; TST verification software may not understand an agreed =

&quot;composite OID&quot; in which agreement it did not take part (i.e. =
a=20
verifier trying to validate a token issued by some other TSA that agreed =
a new=20
OID with ITS clients).Not understanding the OID it would be unable to =
process=20
the associated value. It seems more natural to me that a client software =

&quot;scans&quot; a sequence of hashes looking for those it knows and=20
trusts...</DIV>
<DIV>&nbsp;</DIV>
<DIV>bye,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Juan.</DIV>
<DIV><FONT color=3D#000000=20
size=3D2>____________________________________________<BR>Juan=20
Gonz&aacute;lez-de-la-Vega<BR>Software Engineer<BR>e-mail: &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>FNMT -=20
F&aacute;brica Nacional de Moneda y Timbre<BR>Phone: [phone] =
40.<BR>Fax:=20
[phone]</FONT></DIV></BODY></HTML>

------=_NextPart_000_012E_01BE9C78.37430420--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA09360 for ietf-pkix-bks; Wed, 12 May 1999 02:55:31 -0700 (PDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA09356 for <[e-mail]>; Wed, 12 May 1999 02:55:29 -0700 (PDT)
Received: from lmf.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id LAA14271; Wed, 12 May 1999 11:57:08 +0200 (MET DST)
Received: from lmf.ericsson.se by lmf.lmf.ericsson.se (8.8.8+Sun/SMI-SVR4) id MAA22315; Wed, 12 May 1999 12:56:35 +0300 (EET DST)
Message-ID: <[e-mail]>
Date: Wed, 12 May 1999 12:56:34 +0300
From: Ari Huttunen <[e-mail]>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: X.509 ACs vs. SPKI?
Content-Type: multipart/mixed; boundary="------------0BB4536B87F531E79D7FA3D4"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------0BB4536B87F531E79D7FA3D4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Has someone made a comparison of what can / cannot be done 
in X.509 Attribute Certificates (draft-ietf-pkix-ac509prof-00.txt)
that can be done with SPKI certificates? Would there be some ideas
in SPKI that could be used to enhance X.509 ACs?

My aim here is very pragmatic. I don't observe SPKI as going
forward, so I would like X.509 ACs to be able to do as much as
possible...

For the sake of conversation, here's a proposal how SPKI certificates
could be put inside X.509 ACs. I certainly do not claim that this
works as-is, but it might be made to work.

1) The server checking X.509 ACs is also acting as the CA that
   issues those ACs.

2) The SPKI certificate security fields are mapped as follows:
   Issuer = refers to the X.509 certificate of the server.
   Subject = refers to the X.509 certificate of the client.
   Delegation = ..as in SPKI..
   Authority = ..as in SPKI..
   Validity = attrCertValidityPeriod

Cheers,

   Ari Huttunen
--------------0BB4536B87F531E79D7FA3D4
Content-Type: text/x-vcard; charset=us-ascii;
 name="Ari.Huttunen.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ari Huttunen
Content-Disposition: attachment;
 filename="Ari.Huttunen.vcf"

begin:vcard 
n:Huttunen;Ari
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:L M Ericsson;LMF/T/TK
version:2.1
email;internet:[e-mail]
title:Software Designer
adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland
x-mozilla-cpt:;-30024
fn:Ari Huttunen
end:vcard

--------------0BB4536B87F531E79D7FA3D4--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA08895 for ietf-pkix-bks; Wed, 12 May 1999 01:52:09 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA08891 for <[e-mail]>; Wed, 12 May 1999 01:52:07 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA23690 for <[e-mail]>; Wed, 12 May 1999 10:54:48 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Wed, 12 May 1999 10:54:47 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id KAA12081 for <[e-mail]>; Wed, 12 May 1999 10:54:46 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id KAA15615 for [e-mail]; Wed, 12 May 1999 10:54:46 +0200
Date: Wed, 12 May 1999 10:54:46 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-pkix-time-stamp-01.txt comments
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have forgotten to include the group in the following message.

I profit from the occasion to comment Michael Zolotarev's remarks:

Comment1: The need for a tag had indeed been discussed, but is it
clear at which protocol level a tag is needed, i.e. is this an
issue of some underlying transport protocol, or would the tag be included
in the signature of the response?
  
For example if one uses an e-mail based service, the request would
probably have a message-id in the header and the response may use
an in-reply-to or references. In the ftp case you may need a 
convention what filenames to use.  

Comment2: The sequence number is use when you want a 

 "strictly monotonically increasing Integer from one TimeStampToken
  XXXXXXXX
 to the next."

If you don't have a sequence number, you don't have "strictly".

There is no need to always provide unique time stamps for certain
types of service. The 'stamps' from a real postal service are
within a precision of half an hour or even less for example.  

Comment3: Is there a a De Morgan problem in the wording?

Comment4: Why just 8 bits signed integer for a precision. The encoding
          is just an integer.
          The fractionofSecond definition is not quite nice for
          a display. A power of 10 seems more appropriate. In fact
          I do not see at all why it should be an integer: The
          genTime is a STRING, thus fractionOfSecond would probably
          better be a NumericalString, so a display may simply
          concatenate   genTime '.' franctionOfSecond

          Whether the precision is really needed in this case is
          another matter. Shouldn't it be optional?
               
Comment5: There seems to be some kind of inflation of similar
          protocols (X over Y, Y over X, ...)

Peter 

----- Begin Included Message -----

From: Peter Sylvester <[e-mail]>
Date: Tue, 11 May 1999 20:30:12 +0200
To: [e-mail], [e-mail], [e-mail],
        [e-mail]
Subject: draft-ietf-pkix-time-stamp-01.txt comments

Hi, 

a little bit of nit-picking (and maybe more) :-)


2.1. Requirements of the TSA

The TSA is REQUIRED:
     1. to provide a trusted source of time.
                     trustworthy ?? 

     2. not to include any identification of the requesting entity in 
        the time stamp token.

     3. to include a monotonically incrementing value of the time of day 
        into its time stamp token.
                            tokens.      

     4. to produce a time stamp token upon receiving a valid request 
        from the requester.
What does this mean if the TSA can ignore the request due to overrun?
See security section 4.5 ??

     5. to include within each time stamp token an identifier to 
        uniquely indicate the trust and validation policy under which
        the token was created.
The policy is optional, isn't it?

     6. to only time stamp a hash representation of the datum, i.e. a
        data imprint associated with a one-way collision resistant hash-
        function OID.

     7. to examine the OID of the one-way collision resistant hash-
        function and to verify that this function is "sufficient" (see
        Section 2.4). 
The text later on does not specify what kind of error should be returned.
Shouldn't there be an error code in the PKIFailureInfo? Or is this
badAlg or badRequest ?

     8. not to examine the imprint being time stamped in any way. 
What does THAT mean? If you keep a log of requests/tokens, are you
'examining' the request?  
    
     9. to sign each time stamp token using a key generated exclusively 
        for this purpose and have this property of the key indicated on 
        the corresponding certificate.

    10. to include supplementary temporal information in the time stamp 
        token (from TDA's) if asked by the requester.  If this is not 
        possible, the TSA shall respond with an error message.
Would it be possible to respond with a 'modified answer' 
and simply not including the missing TDAs in the token.
The application could decide how to interprete the result? I don't really
care.  

    11. to provide a signed receipt (i.e. in the form of an 
        appropriately defined time stamp token) to the requester, where 
        appropriate, as defined by policy.

The definition of TSTTime (or TSTInfo) does not say what should
put as time in case of a PKIStatus rejected especially when

    timeNotAvailable {14},
      -- the TSAs time source is not available

A small wording change in the following:

     6. A CA shall normally conduct a test for proof of possession for 
        each user's signing private key (including the TSA/TDA signing 
        private key). However, in some environments, the CA might not 
        perform a proof-of-possession of the private key when issuing 
        certificates. In these instances, in order to prevent certain
        attacks and to properly check the validity of the binding 
        between an end entity and a key pair, a certificate identifier 
        of the TSA/TDA shall be included as a signed attribute.

                                              the signature MUST contain
        an ESSCertID authenticated attribute.

see also the wording in:

certificate that is to be used to verify the token.  This field MAY be 
omitted if the Signing Certificate Attribute has been included as a 
signed attribute.  (See Section 5 of [ESS].)  It MUST be present if the 
ESSCertID Attribute is not used to identify the TSA.


The socket based protocol does not seem to follow the requirements
of not giving non signed responses.
 
In fact, there seems to be some confusion in layers. What is considered
as 'not respond' in a context of http for example. You cut the
connection? You just let the connection time out? 

        produce a valid response before responding, if this is possible.  
        If this is not possible, it MUST ignore the requests and not 
                                    ????????????????????????????????
        respond.
        ???????

It seems to me that the socket based protocol is basically designed
as an internal protocol among a front end transaction based http 
and a back end signing entity for example, thus operated in a different
security context; no problem with that. 

In general I guess it is necessary to make a precise definition what means
'returning a response', 'not returning a response' depending on each
lower layer, especially for http, 'document contains no data' = 0 length
response or time out.  



> A simple MIME object is specified as follows.

>    Content-Type: application/timestamp
>   Content-Transfer-Encoding: base64

>   <<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>
No: An appropriate, content preserving transfer encoding should be used.
Someone can reencode in quoted-printable or whatever. 


Which method should be used in http to send a request. 
(POST ??) PUT?? Don't care?? 


> This MIME object can be sent and received using common HTTP processing
> engines over WWW links and provides a simple browser-server transport
                                               CLIENT
> for Time Stamp messages.

     1. When there is a reason to believe that the TSA/TDA can no longer
        be trusted, the authority's certificate MUST be revoked and 
        placed on the appropriate CRL.  Thus, at any future time the 
        tokens signed with the corresponding key will not be valid.

Tokens with a time superior than the end of validity are not valid.

And telling HOW a ca should act should not be the business of this
text. There might be OCSP for example.


It seems that a paragraph about configuration is missing:

- what URI should be used?
- How do I get a trustworthy certificate

One suggestion that minimises the two parameters into one:

A certificate of a TSA/TDA may contain an AIA with 
id-kp-temporalDataAuthority and an URL. 

and to say that it is a local matter of an application to decide
which time stamp service is 'trustworthy'. 

Appendix A:

For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute 
type.  This attribute type specifies the time stamp token, which MUST be 
                                                                 can
included as a signed attribute of the SignedData object. 


have fun


----- End Included Message -----



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA02671 for ietf-pkix-bks; Tue, 11 May 1999 23:46:14 -0700 (PDT)
Received: from stargate.zergo.com.au ([e-mail] [203.2.208.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA02658 for <[e-mail]>; Tue, 11 May 1999 23:46:04 -0700 (PDT)
Received: from michaelz (dhcp-64.ws.zergo.com.au [192.168.72.64]) by stargate.zergo.com.au (8.9.1/8.8.7) with SMTP id QAA17978; Wed, 12 May 1999 16:49:56 +1000
Reply-To: <[e-mail]>
From: "Michael Zolotarev" <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'PKIX mailing group'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Wed, 12 May 1999 16:46:39 +1000
Message-ID: <000601be9c43$320394f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <01E1D01C12D7D211AFC70090273D20B112BE19@sothmxs06>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comment1.
The new draft does not address the problem of defining an optional 'tag'
field to help associating a stamp with its origin.
The need for the tag has been discussed intensively by the mail group, and I
do not recall anybody arguing against it.
----------------------------------------------------------------------------
------------------------------------------
Comment2
The SerialNumber is defined as OPTIONAL. The need for having it is clear, it
is not anyhow request-specific, or a difficult thing to implement for the
TSA. So why is it optional?
----------------------------------------------------------------------------
--------------------------------------
Comment3
in TSTInfo: "TSA services MAY produce "signed times" which are timestamp
tokens that do not contain a nonce or message imprint and are thus not
linked to any request". Does it mean that a stamp with the imprint but
without a nonce is regarded as a 'signed time'.
----------------------------------------------------------------------------
---------------------------------------
Comment4
The description of the precision field is somehow difficult to understand,
and the name 'precision' is misleading. It is not a precision, it is the
precision factor. I had to guess that 31.25 is actually a product of
division of 1 by 32.
My suggestion would be:
"The precisionFactor field is an 8 bit signed integer. The actual precision
of the clock is calculated as a power(2, precisionFactor). Negative
precisionFactor value produces a precision as a fraction of a second - for
instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec (31ms). This
precisionFactor would account for the 50-Hz (20ms) or 60-Mh (16.67ms)
power-frequency clock, for example. Note that this method defines a
precision of a clock as 'being around the value', not as an exact figure."
----------------------------------------------------------------------------
----------------------------
Comment5.
The socket based protocol is apparently borrowed from the CMP spec. Should
we stop being shy, make one more step forward, and expand the CMP-defined
messages by adding TSA messages? That is, the message will contain a proper
PKIHeader (as defined by the CMP), and the PKIBody with ID=XXX (XXX > 23, as
23 is the last ID reserved by the CMP). The actual PKIBody would be the
DER-encoded TSA message.
This would set a good example for other PKI services, such as AC and Notary.
----------------------------------------------------------------------------
--------------------------------------------
Michael Zolotarev
Technical Architect, Baltimore Technologies Ltd, Australia



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00894 for ietf-pkix-bks; Tue, 11 May 1999 10:10:07 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA00890 for <[e-mail]>; Tue, 11 May 1999 10:10:06 -0700 (PDT)
Received: 	id NAA05143; Tue, 11 May 1999 13:08:59 -0400
Received: by gateway id <J96LDAM6>; Tue, 11 May 1999 13:11:26 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B112BE19@sothmxs06>
From: Robert Zuccherato <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Tue, 11 May 1999 13:11:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would encourage everyone who had comments on the recently expired time
stamping draft to take a look at this new draft that recently appeared.  We
attempted to accommodate the concerns raised since the last draft was
submitted.

At the time of submission, I still had not heard back from IANA concerning
the assignment of a port number for PKIX timestamping.  Since then I have
received a reply.  The assigned port number is 318.  The next version will
be updated to reflect this.

	Robert Zuccherato.

> ----------
> From: 	[e-mail][SMTP:[e-mail]]
> Reply To: 	[e-mail]
> Sent: 	Tuesday, May 11, 1999 9:31 AM
> To: 	IETF-Announce
> Cc: 	[e-mail]
> Subject: 	I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
> 
> <<Message: Microsoft Exchange Message>>
> A New 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 X.509 Public Key Infrastructure Time
> Stamp Protocols
> 	Author(s)	: C. Adams, B. Pinkas, P. Cain, R. Zuccherato
> 	Filename	: draft-ietf-pkix-time-stamp-01.txt
> 	Pages		: 18
> 	Date		: 10-May-99
> 	
> This document describes the format of the data returned by a Time
> Stamp Authority and the protocols to be used when communicating with it.
> The time stamping service can be used as a Trusted Third Party (TTP) as
> one component in building reliable non-repudiation services (see
> [ISONR]).  In order to reduce the amount of trust required of a TSA we
> introduce (in Appendix C) the optional Temporal Data Authority (TDA)
> whose function is to provide further corroborating evidence of the time
> contained in the token.  We also give an example of how to place a
> signature at a particular point in time, from which the appropriate
> certificate status information (e.g. CRLs) may be checked.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-01.txt
> 
> Internet-Drafts are also 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-time-stamp-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-01.txt".
> 	
> NOTE:	The mail server at ietf.org 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.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27581 for ietf-pkix-bks; Tue, 11 May 1999 08:44:09 -0700 (PDT)
Received: from oe8.briank.com (oe8.briank.com [209.133.59.211]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27565 for <[e-mail]>; Tue, 11 May 1999 08:44:04 -0700 (PDT)
Received: from cs.stanford.edu (blatz.briank.com [209.133.59.212]) by oe8.briank.com (8.8.8/8.8.8) with ESMTP id IAA08152; Tue, 11 May 1999 08:46:02 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 11 May 1999 08:46:05 -0700
From: Brian Korver <[e-mail]>
Reply-To: [e-mail]
X-Mailer: Mozilla 4.51 (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Brouwer <[e-mail]>
CC: [e-mail]
Subject: Re: EncapsulatedContentInfo needs clarification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Brouwer wrote:
> 
> In the draft-ietf-smime-cms-13.txt document on page 8, in the
> explanation of "The Fields of type EncapsulatedContentInfo", the
> following sentance appears:
> 
>    eContent is the content itself, carried as an octect string.  The
>    eContent need not be DER encoded.
> 
> What exactly does carried as an octect string mean here.  I know the if
> eContentType is id-data the value octects of the content string are the
> actual data being signed (or digested or authenticated) however if the
> eContentType is id-envelopedData then are the octets of the eContent
> octect string an actual BER encoded EnvelopedData object (starting with
> a SEQUENCE) or are the octects (simular to the id-Data case) the BER
> encoding of the EnvelopedData object without the surrounding SEQUENCE?
> 
> I'm not on this list so I would appriciate if you could CC me on
> replies.

Michael,

Yes, take the entire BER encoded EnvelopedData and put it into
the OCTET STRING.  CMS treats all content types similar to how 
id-data types used to be constructed.

brian
[e-mail]      (play)
[e-mail]  (work)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23103 for ietf-pkix-bks; Tue, 11 May 1999 06:29:12 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23089 for <[e-mail]>; Tue, 11 May 1999 06:29:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26587; Tue, 11 May 1999 09:31:16 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
Date: Tue, 11 May 1999 09:31:16 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New 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 X.509 Public Key Infrastructure Time Stamp Protocols
	Author(s)	: C. Adams, B. Pinkas, P. Cain, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-01.txt
	Pages		: 18
	Date		: 10-May-99
	
This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]).  In order to reduce the amount of trust required of a TSA we
introduce (in Appendix C) the optional Temporal Data Authority (TDA)
whose function is to provide further corroborating evidence of the time
contained in the token.  We also give an example of how to place a
signature at a particular point in time, from which the appropriate
certificate status information (e.g. CRLs) may be checked.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-01.txt

Internet-Drafts are also 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-time-stamp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-01.txt".
	
NOTE:	The mail server at ietf.org 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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-time-stamp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA16406 for ietf-pkix-bks; Tue, 11 May 1999 03:07:11 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA16402 for <[e-mail]>; Tue, 11 May 1999 03:07:09 -0700 (PDT)
Received: from d3-s61-221-telehouse.mistral.co.uk (d3-s61-221-telehouse.mistral.co.uk [195.184.228.221]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id KAA02348; Tue, 11 May 1999 10:09:13 +0100
Received: by d3-s61-221-telehouse.mistral.co.uk with Microsoft Mail id <[e-mail]>; Tue, 11 May 1999 11:04:31 +0100
Message-ID: <[e-mail]>
From: Darren Harter <[e-mail]>
To: "'Xiong Shao Jun'" <[e-mail]>
Cc: "'PKIX Mailing List'" <[e-mail]>
Subject: RE: On key identifier
Date: Tue, 11 May 1999 11:04:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA16403
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

You are correct that the SHA-1 should be done on the DER encoding of the DSA public key, but unfortunately the example encoding in RFC 2459 is not correct.

If the public key is AA98EA.... then the DER encoding of this value begins with 02818100 not 028180 as stated in the examples section of RFC 2459.  RFC 2459 is in error.

You are performing the correct calculation but comparing your result against incorrect data.

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
[phone]
Email: mailto:[e-mail]


-----Original Message-----
From:	Xiong Shao Jun [SMTP:[e-mail]]
Sent:	Tuesday, May 11, 1999 10:43 AM
To:	Darren Harter
Cc:	[e-mail]
Subject:	Re: On key identifier

I think 028180aa98--- is the DER encoded DSA public key. So SHA-1 should be done on
this part. My result was just operated with such calculation.

Best regards,
Xiong Shaojun

Darren Harter wrote:

> Just as a slight aside....
>
> If the public key in this certificate is the POSITIVE integer value 0xAA98EA...... then the DER encoding of it is incorrect as shown in the example.  Integers are encoded as 2's-complement numbers, and the encoding as shown contains a negative number who's 2's-compliment encoding is 0xAA98EA.....
>
> The encoding for any positive integer who's highest bit is set must start with a zero octet.  The correct integer encoding for the public shown would be as follows:
>
> 02 81 81 00 aa 98 ea 13 94 a2 db f1 5b 7f ....
>
> Likewise any negative number with a highest bit clear would start with a 0xFF octet.
>
> This problem affects many of the integer encodings in the example certificates in RFC 2459.
>
> Is it possible that the key identifier in the example has been calculated over the correct integer encoding rather than the one shown?
>
> Regards,
>
> Darren
>
>                            : 55 1d 0e
> 0615 04 16           22: . . . . . OCTET STRING
>                               : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95
> aa d5 ff
>                               : 1c 21 e4 22 75 d6
>
> So, what causes the problem?





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA14937 for ietf-pkix-bks; Tue, 11 May 1999 02:46:47 -0700 (PDT)
Received: from mail0.sse.ie (mail0.sse.ie [193.120.32.47]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA14933 for <[e-mail]>; Tue, 11 May 1999 02:46:46 -0700 (PDT)
Received: from mail2.sse.ie by mail0.sse.ie; Tue, 11 May 1999 10:48:40 +0100
Received: from mail0.sse.ie (mail0.sse.ie) by mail2.sse.ie (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Tue, 11 May 1999 10:48:36 +0100
Received: from baboo.sse.ie ([e-mail] [193.120.32.109]) by mail0.sse.ie (8.9.1a/8.9.1) with ESMTP id KAA23704; Tue, 11 May 1999 10:48:33 +0100 (BST)
Received: from baboo.sse.ie (farrell@baboo [193.120.32.109]) by baboo.sse.ie (8.9.1/8.9.1) with ESMTP id KAA26937; Tue, 11 May 1999 10:48:32 +0100 (BST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.9 8/22/96
To: "Linn, John" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Attributes within PK certs? [RE: I-D ACTION:draft-ietf-pkix-ac509  prof-00.txt]
In-Reply-To: Your message of "Mon, 10 May 1999 15:34:02 EDT." <[e-mail]> 
MIME-Version: 1.0
Date: Tue, 11 May 1999 10:48:32 +0100
From: Stephen Farrell <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

Like the other responses, I guess my gut reaction would be
to try to keep authorization attributes out of public-key
certificates. As you say, there are cases where PKI and
privilege administration & validity overlap, but in our
experience this is the exception, not the typical case.
(Even where we use AC-like things to control remote access to
PKI management functionality!)

Regards,
Stephen.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA14851 for ietf-pkix-bks; Tue, 11 May 1999 02:40:23 -0700 (PDT)
Received: from ns.cmbchina.com ([202.96.161.112]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA14847 for <[e-mail]>; Tue, 11 May 1999 02:40:18 -0700 (PDT)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA16718; Tue, 11 May 1999 17:41:26 -0800
Message-ID: <[e-mail]>
Date: Tue, 11 May 1999 17:42:52 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: Darren Harter <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: On key identifier
References: <01BE9B90.F3BBCE40@DHARTER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think 028180aa98--- is the DER encoded DSA public key. So SHA-1 should be done on
this part. My result was just operated with such calculation.

Best regards,
Xiong Shaojun

Darren Harter wrote:

> Just as a slight aside....
>
> If the public key in this certificate is the POSITIVE integer value 0xAA98EA...... then the DER encoding of it is incorrect as shown in the example.  Integers are encoded as 2's-complement numbers, and the encoding as shown contains a negative number who's 2's-compliment encoding is 0xAA98EA.....
>
> The encoding for any positive integer who's highest bit is set must start with a zero octet.  The correct integer encoding for the public shown would be as follows:
>
> 02 81 81 00 aa 98 ea 13 94 a2 db f1 5b 7f ....
>
> Likewise any negative number with a highest bit clear would start with a 0xFF octet.
>
> This problem affects many of the integer encodings in the example certificates in RFC 2459.
>
> Is it possible that the key identifier in the example has been calculated over the correct integer encoding rather than the one shown?
>
> Regards,
>
> Darren
>
> ------------------------------------------------------------------------
> Darren Harter BSc (Hons) CEng MBCS
> Entegrity Solutions Corp
> http://www.entegrity.co.uk
> [phone]
> Email: mailto:[e-mail]
>
> -----Original Message-----
> From:   Xiong Shao Jun [SMTP:[e-mail]]
> Sent:   Tuesday, May 11, 1999 3:52 AM
> To:     [e-mail]
> Subject:        On key identifier
>
> Hi, folks. I'm working on a PKIX project. A few days ago, when I run a
> test on key identifier, I encounter a problem. In rfc 2459 section
> 4.2.1.2, as to key identifier, it says:
>
> (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value
> of the BIT STRING subjectPublicKey (excluding the tag,  length, and
> number of unused bits).
>
> I get sample data from rfc2459, Example D.1, which is a CA certificate,
> and I think I should
> do SHA-1 on the DER-encoded subjectPublicKey, according to the above
> paragraph, but I
> got a different result. My SHA-1 result is:
> a1d443c9243cfa0587f8a99898ddefc4e7359888
>
> Below is data from rfc2459:
> subjectPublicKey:
> 0452 03 81 84     132: . . . BIT STRING  (0 unused bits)
>                                : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f
> 98 2f 78
>                                : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da
> 3b 4b 13
>                                : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2
> 6b 5c 77
>                                : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb
> 25 bc 91
>                                : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e
> 60 13 ca
>                                : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc
> 71 de cf
>                                : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d
> d0 7b ba
>                                : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83
> 25 4f 14
>                                : aa 71 e1
>
> 0608 30 1d           29: . SEQUENCE
> 0610 06 03             3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
>                               : 55 1d 0e
> 0615 04 16           22: . . . . . OCTET STRING
>                               : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95
> aa d5 ff
>                               : 1c 21 e4 22 75 d6
>
> So, what causes the problem?





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA13642 for ietf-pkix-bks; Tue, 11 May 1999 01:33:23 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA13638 for <[e-mail]>; Tue, 11 May 1999 01:33:21 -0700 (PDT)
Received: from DHARTER (d3-s40-200-telehouse.mistral.co.uk [195.184.228.200]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id IAA18276; Tue, 11 May 1999 08:35:31 +0100
Received: by DHARTER with Microsoft Mail id <01BE9B90.F3BBCE40@DHARTER>; Tue, 11 May 1999 09:30:47 +0100
Message-ID: <01BE9B90.F3BBCE40@DHARTER>
From: Darren Harter <[e-mail]>
To: "'Xiong Shao Jun'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: On key identifier
Date: Tue, 11 May 1999 09:30:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA13639
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just as a slight aside....

If the public key in this certificate is the POSITIVE integer value 0xAA98EA...... then the DER encoding of it is incorrect as shown in the example.  Integers are encoded as 2's-complement numbers, and the encoding as shown contains a negative number who's 2's-compliment encoding is 0xAA98EA.....

The encoding for any positive integer who's highest bit is set must start with a zero octet.  The correct integer encoding for the public shown would be as follows:

02 81 81 00 aa 98 ea 13 94 a2 db f1 5b 7f ....

Likewise any negative number with a highest bit clear would start with a 0xFF octet.

This problem affects many of the integer encodings in the example certificates in RFC 2459.

Is it possible that the key identifier in the example has been calculated over the correct integer encoding rather than the one shown?

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
[phone]
Email: mailto:[e-mail]


-----Original Message-----
From:	Xiong Shao Jun [SMTP:[e-mail]]
Sent:	Tuesday, May 11, 1999 3:52 AM
To:	[e-mail]
Subject:	On key identifier

Hi, folks. I'm working on a PKIX project. A few days ago, when I run a
test on key identifier, I encounter a problem. In rfc 2459 section
4.2.1.2, as to key identifier, it says:

(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value
of the BIT STRING subjectPublicKey (excluding the tag,  length, and
number of unused bits).

I get sample data from rfc2459, Example D.1, which is a CA certificate,
and I think I should
do SHA-1 on the DER-encoded subjectPublicKey, according to the above
paragraph, but I
got a different result. My SHA-1 result is:
a1d443c9243cfa0587f8a99898ddefc4e7359888

Below is data from rfc2459:
subjectPublicKey:
0452 03 81 84     132: . . . BIT STRING  (0 unused bits)
                               : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f
98 2f 78
                               : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da
3b 4b 13
                               : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2
6b 5c 77
                               : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb
25 bc 91
                               : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e
60 13 ca
                               : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc
71 de cf
                               : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d
d0 7b ba
                               : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83
25 4f 14
                               : aa 71 e1

0608 30 1d           29: . SEQUENCE
0610 06 03             3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
                              : 55 1d 0e
0615 04 16           22: . . . . . OCTET STRING
                              : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95
aa d5 ff
                              : 1c 21 e4 22 75 d6

So, what causes the problem?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA06727 for ietf-pkix-bks; Mon, 10 May 1999 23:21:53 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA06696 for <[e-mail]>; Mon, 10 May 1999 23:21:41 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id IAA26375 for <[e-mail]>; Tue, 11 May 1999 08:24:16 +0200
Received: from mega (t3o69p1.telia.com [62.20.145.1]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA75802; Tue, 11 May 1999 08:24:15 +0200
Message-ID: <002401be9b7e$fed8fad0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Linn, John" <[e-mail]>, <[e-mail]>
Subject: Re: Attributes within PK certs? [RE: I-D ACTION:draft-ietf-pkix-ac509prof-00.txt]
Date: Tue, 11 May 1999 08:22:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA06722
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,
I would be less pessimistic on the adoption of ACs as they solve things that public key certificates never will.

If you look on ( http://www.mobilephones-tng.com/v100/dynamiccerts.html ) you will find a scheme for a MAJOR APPLICATION that ALONE could move ACs forward based on pure commercial needs.

Regards
Anders Rundgren
Senior Internet e-commerce Architect

>I'd like to welcome this work to PKIX's scope, and to make a general comment
>relevant to the draft. I believe that attribute certification will be
>valuable and important in broadening the scope of PKI technologies to span
>authorization as well as authentication.  If experience is a guide, however,
>new certification infrastructures can take a long time to become
>established.  With this in mind, I suggest that we decouple the idea of
>certifying authorization attributes from the idea that they must be in ACs
>separate from public-key identity certificates.  As [XPDAM] allows, I
>suggest that PKIX-profiled authorization attributes alternatively be
>representable within subjectDirectoryAttributes of a public-key certificate,
>when CA and AA responsibilities and validity periods overlap appropriately.
>This would imply some change to 2459's description of this attribute (which
>says that it may be used in local environments, but is not recommended as an
>essential part of the 2459 profile), but would allow authorization
>attributes to be incorporated incrementally within CAs' certificates rather
>than necessitating a separate infrastructure. 
>
>--jl
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA17307 for ietf-pkix-bks; Mon, 10 May 1999 19:49:24 -0700 (PDT)
Received: from ns.cmbchina.com ([202.96.161.112]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA17291 for <[e-mail]>; Mon, 10 May 1999 19:49:20 -0700 (PDT)
Received: from cmbchina.com ([10.1.4.27]) by ns.cmbchina.com (Netscape Messaging Server 3.01)  with ESMTP id AAA16519 for <[e-mail]>; Tue, 11 May 1999 10:50:40 -0800
Message-ID: <[e-mail]>
Date: Tue, 11 May 1999 10:52:10 +0800
From: "Xiong Shao Jun" <[e-mail]>
Organization: China Merchants Bank
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: On key identifier
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, folks. I'm working on a PKIX project. A few days ago, when I run a
test on key identifier, I encounter a problem. In rfc 2459 section
4.2.1.2, as to key identifier, it says:

(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value
of the BIT STRING subjectPublicKey (excluding the tag,  length, and
number of unused bits).

I get sample data from rfc2459, Example D.1, which is a CA certificate,
and I think I should
do SHA-1 on the DER-encoded subjectPublicKey, according to the above
paragraph, but I
got a different result. My SHA-1 result is:
a1d443c9243cfa0587f8a99898ddefc4e7359888

Below is data from rfc2459:
subjectPublicKey:
0452 03 81 84     132: . . . BIT STRING  (0 unused bits)
                               : 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f
98 2f 78
                               : e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da
3b 4b 13
                               : 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2
6b 5c 77
                               : 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb
25 bc 91
                               : c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e
60 13 ca
                               : c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc
71 de cf
                               : 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d
d0 7b ba
                               : 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83
25 4f 14
                               : aa 71 e1

0608 30 1d           29: . SEQUENCE
0610 06 03             3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
                              : 55 1d 0e
0615 04 16           22: . . . . . OCTET STRING
                              : 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95
aa d5 ff
                              : 1c 21 e4 22 75 d6

So, what causes the problem?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA08240 for ietf-pkix-bks; Mon, 10 May 1999 18:20:32 -0700 (PDT)
Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA08236 for <[e-mail]>; Mon, 10 May 1999 18:20:31 -0700 (PDT)
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id SAA57470 for <[e-mail]>; Mon, 10 May 1999 18:23:08 -0700
Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id <[e-mail]>; Mon, 10 May 1999 18:22:59 -0700
Received: from apple.com (zoetje2.apple.com [17.205.42.88]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id SAA36070; Mon, 10 May 1999 18:22:49 -0700
Message-Id: <[e-mail]>
Date: Mon, 10 May 1999 18:27:50 -0700
From: Michael Brouwer <[e-mail]>
X-Mailer: Mozilla 4.5 (Macintosh; U; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>, [e-mail]
Subject: EncapsulatedContentInfo needs clarification
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In the draft-ietf-smime-cms-13.txt document on page 8, in the
explanation of "The Fields of type EncapsulatedContentInfo", the
following sentance appears:

   eContent is the content itself, carried as an octect string.  The
   eContent need not be DER encoded.

What exactly does carried as an octect string mean here.  I know the if
eContentType is id-data the value octects of the content string are the
actual data being signed (or digested or authenticated) however if the
eContentType is id-envelopedData then are the octets of the eContent
octect string an actual BER encoded EnvelopedData object (starting with
a SEQUENCE) or are the octects (simular to the id-Data case) the BER
encoding of the EnvelopedData object without the surrounding SEQUENCE?

I'm not on this list so I would appriciate if you could CC me on
replies.

--

Michael Brouwer

Senior Software Engineer
Apple Data Security Group




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA05406 for ietf-pkix-bks; Mon, 10 May 1999 13:55:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA05402 for <[e-mail]>; Mon, 10 May 1999 13:55:31 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id QAA00797 for <[e-mail]>; Mon, 10 May 1999 16:57:57 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id QAA00791 for <[e-mail]>; Mon, 10 May 1999 16:57:57 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id QAA11137 for <[e-mail]>; Mon, 10 May 1999 16:58:04 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id QAA03433 for <[e-mail]>; Mon, 10 May 1999 16:56:24 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 10 May 1999 16:56:24 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Attributes within PK certs?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 0E8v73/AXRS+1leinuh0ow==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Linn, John" <[e-mail]>
> 
>  ...  If experience is a guide, however,
> new certification infrastructures can take a long time to become
> established.  With this in mind, I suggest that we decouple the idea of
> certifying authorization attributes from the idea that they must be in ACs
> separate from public-key identity certificates.  As [XPDAM] allows, I
> suggest that PKIX-profiled authorization attributes alternatively be
> representable within subjectDirectoryAttributes of a public-key certificate,
> when CA and AA responsibilities and validity periods overlap appropriately.

When the program I am associated with began, X.509 was only v1.
Needing to do authorization, but lacking an extension mechanism, we
defined our own algorithmIDs and encoded authorization attributes into
subjectPublicKeyInfo.  This was an X.509-compliant approach, and it
worked.  Now that X.509 v3 is available and ACs are not, we do just as
you suggest, encoding authorization attributes in the
subjectDirectoryAttributes extension, which is no more or less
X.509-compliant than the first approach.

But although algorithm parameters and extensions can both be profiled
to hold attributes within communities of interest, I do not believe it
would be architecturally sound for a community as large as PKIX to
profile such practices.  Instead, PKIX should do everything possible
to encourage the distinction between identification and authorization;
allowing PK certs on the Internet scale to be long-lived and
(relatively) simple.  Standardized authorization structures, wherever
they are carried, will be a long time in coming.  Standardizing the
placement of attributes in PK certs will, IMO, delay the availability
of AC-enabled applications far more than it would accelerate the
availability of cert-based authorization.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA04832 for ietf-pkix-bks; Mon, 10 May 1999 12:26:51 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA04828 for <[e-mail]>; Mon, 10 May 1999 12:26:50 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 10 May 1999 19:28:03 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA09173 for <[e-mail]>; Mon, 10 May 1999 15:27:45 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <KVQTP4ZD>; Mon, 10 May 1999 15:31:37 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: [e-mail]
Subject: Attributes within PK certs? [RE: I-D ACTION:draft-ietf-pkix-ac509 prof-00.txt]
Date: Mon, 10 May 1999 15:34:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'd like to welcome this work to PKIX's scope, and to make a general comment
relevant to the draft. I believe that attribute certification will be
valuable and important in broadening the scope of PKI technologies to span
authorization as well as authentication.  If experience is a guide, however,
new certification infrastructures can take a long time to become
established.  With this in mind, I suggest that we decouple the idea of
certifying authorization attributes from the idea that they must be in ACs
separate from public-key identity certificates.  As [XPDAM] allows, I
suggest that PKIX-profiled authorization attributes alternatively be
representable within subjectDirectoryAttributes of a public-key certificate,
when CA and AA responsibilities and validity periods overlap appropriately.
This would imply some change to 2459's description of this attribute (which
says that it may be used in local environments, but is not recommended as an
essential part of the 2459 profile), but would allow authorization
attributes to be incorporated incrementally within CAs' certificates rather
than necessitating a separate infrastructure. 

--jl


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA02761 for ietf-pkix-bks; Mon, 10 May 1999 08:51:19 -0700 (PDT)
Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02757 for <[e-mail]>; Mon, 10 May 1999 08:51:18 -0700 (PDT)
Received: from brick (dialup-209.244.107.66.SanJose1.Level3.net [209.244.107.66]) by falcon.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA12778 for <[e-mail]>; Mon, 10 May 1999 08:52:31 -0700 (PDT)
Message-ID: <022f01be9afd$06dea310$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "IETF PKIX" <[e-mail]>
Subject: Fw:      Search Engine Privacy Issues
Date: Mon, 10 May 1999 08:51:53 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI - Privacy Issues

----- Original Message -----
From: Dave Sweigert <[e-mail]>
To: <[e-mail]>
Sent: Monday, May 10, 1999 7:39 AM
Subject: Search Engine Privacy Issues


> Note: From www.jya.com
>
> http://www.jya.com
> [crypto fanatic site]
>
> "Web sites are examined continuously by "search engines" which generate
> catalogues of their contents. "Alta Vista" and "Hotbot" are prominent
public
> sites of this kind. NSA similarly employs computer "bots" (robots) to
> collect data of interest. For example, a New York web site known as
JYA.COM
> (http://www.jya.com/cryptome) offers extensive public information on
Sigint,
> Comint and cryptography. The site is frequently updated. Records of access
> to the site show that every morning it is visited by a "bot" from NSA's
> National Computer Security Centre, which looks for new files and makes
> copies of any that it finds."
>
> -- Duncan Campbell in Interception Capabilities 2000, released May 6, 1999
>
> 8 May 1999
>
> This site's host, AOL PrimeHost, has initiated a new snooping feature
which
> we didn't ask for, wasn't consulted on and find obnoxiously
> privacy-invasive: our access log now automatically shows what URL was
> visited just prior to accessing a file here. In the case of those coming
> from search engines, it gives the topics and/or keywords the visitor
entered
> for searching. Here're samples (addresses xxx-ed. The second is the NSA
> daily bot - note its prudent use of a proxy gateway - which is as welcome
as
> meat-hunks):
>
> xxxxx - - [03/May/1999:01:17:55 -0400] "GET /bombmake.htm HTTP/1.1" 200
> 33094
>
"http://infoseek.go.com/Titles?qt=how+to+make+a+bomb&win=_search&oq=bomb+mak
> ing&sv=M6&lk=noframes&col=WW&cll=0&st=10" "Mozilla/4.0 (compatible; MSIE
> 4.01; Windows 98)"
> xxxxx - - [03/May/1999:08:00:39 -0400] "GET /crypto.htm HTTP/1.0" 200
27266
> "" "Mozilla/4.04 [en] (WinNT; U)  via proxy gateway  CERN-HTTPD/3.0
> libwww/2.17"
> Since we don't know who has access to our logs, and have to assume they
are
> many (see below), keep in mind the beneficial use of an anonymizer and
hope
> that the anonymizer is not compromised -- a long shot according to recent
> news reports.
>
> PrimeHost is being bought by Verio we're informed, so it's going to get
> worse as the millionaire-wannabes race to meet "business market demand"
for
> snooping on unwary consumers, having learned the lessons of success while
> pigging out on mega-sales to world's intelligence agencies snooping on
> citizens, like IBM , HP, Lotus, Netscape and Microsoft -- see:
> http://jya.com/ic2000-text.htm.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA00572 for ietf-pkix-bks; Mon, 10 May 1999 04:29:04 -0700 (PDT)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA00567 for <[e-mail]>; Mon, 10 May 1999 04:29:02 -0700 (PDT)
Received: from GK-Portable (unverified [62.188.142.26]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id <[e-mail]>; Mon, 10 May 1999 12:22:40 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 10 May 1999 12:31:36 +0100
To: Hans Nilsson <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Rename Qualified Certificates?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 08:15 07/05/99 +0200, Hans Nilsson wrote:

>I would therefore like to propose that the PKIX term is changed to something
>else, and possibly more descriptive. My suggestion is "identity
>certificates", but there may be other good suggestions.

"Identity" seems reasonable, and more descriptive than "qualified".  But I
note from section 2.1 the draft, it must:

   - Be issued to a natural person (living human being).

To me, this suggests "personal certificate".

If these certificates were to be extended to other legal entities
(companies, etc.) then I think "identity" would be more apposite.

#g

------------
Graham Klyne
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08637 for ietf-pkix-bks; Sun, 9 May 1999 12:59:56 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08633 for <[e-mail]>; Sun, 9 May 1999 12:59:54 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id WAA13008 for <[e-mail]>; Sun, 9 May 1999 22:02:11 +0200
Received: from mega (t2o69p33.telia.com [62.20.144.153]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id WAA49362; Sun, 9 May 1999 22:01:55 +0200
Message-ID: <002a01be9a5e$e65a6640$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Todd S. Glassey - ELN" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Petra Gloeckner" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Need for TSTokens and who should own the effort, was Re: QC "Certificate Overloading"
Date: Sun, 9 May 1999 21:59:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id MAA08634
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,
Comments in line-

>Actually this thread subject, that of using x.509 certs to carry event
>tokens has more higher-level implications I think. What certs were intended
>for was identifying entities, not representing physical events or
>timestamping data elements.

I see nothing fundamentally wrong in using certificates for any kind of certifyable information.

>This is a very important issue and try to use a cert to carry event specific
>data, while it may be technically possible, may not have as many commercial
>uses as we would like to think it does, and this effect may be due to issues
>in law more than anything else.

Should I interprete this as: "Dynamic Certificates" as described by A.R. will be outlawed?

<snip>

>The only question to answer from my perspective, is whether PKIX and the
>IETF is the forum to use to standardize them and if not, then who is?

That is a good question.  Looking on things historically one can find that OBI and SET which will be the dominant PKI-systems in the hot e-commerce sector were developed by closed consortiums that have huge member-fees so if not the IETF acts now I would say it will very soon be too late.  Personally I don't care that much as I am determined to participate in whatever form such an effort will surface :-)

Anders Rundgren
http://www.mobilephones-tng.com




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07536 for ietf-pkix-bks; Sun, 9 May 1999 08:39:53 -0700 (PDT)
Received: from falcon.prod.itd.earthlink.net (falcon.prod.itd.earthlink.net [207.217.120.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07532 for <[e-mail]>; Sun, 9 May 1999 08:39:52 -0700 (PDT)
Received: from brick (dialup-209.244.107.66.SanJose1.Level3.net [209.244.107.66]) by falcon.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id IAA29022; Sun, 9 May 1999 08:42:01 -0700 (PDT)
Message-ID: <003901be9a32$6a75f430$930aff0c@brick>
From: "Todd S. Glassey - ELN" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Petra Gloeckner" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
References: <001601be99d7$99ef0770$[e-mail]>
Subject: Need for TSTokens and who should own the effort, was Re: QC "Certificate Overloading"
Date: Sun, 9 May 1999 08:41:30 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,
Actually this thread subject, that of using x.509 certs to carry event
tokens has more higher-level implications I think. What certs were intended
for was identifying entities, not representing physical events or
timestamping data elements.

This is a very important issue and try to use a cert to carry event specific
data, while it may be technically possible, may not have as many commercial
uses as we would like to think it does, and this effect may be due to issues
in law more than anything else.Potentially, once x.509 certs become more
normalized and their standards, not only agreed upon, but deployed
ubiquitously as well, then this type of use model may be considered. In the
interim however, I think that the token format specifications will cover us
here.

The only question to answer from my perspective, is whether PKIX and the
IETF is the forum to use to standardize them and if not, then who is?

Just my two cents.

Todd Glassey

----- Original Message -----
From: Anders Rundgren <[e-mail]>
To: Denis Pinkas <[e-mail]>; Petra Gloeckner
<[e-mail]>; Stefan Santesson <[e-mail]>
Cc: <[e-mail]>
Sent: Saturday, May 08, 1999 9:51 PM
Subject: QC "Certificate Overloading"


> There have been comments in this list that it is convenient to use
certificates for storing large data objects like biometric templates but
that this is "overloading the mechanism".  I disagree as you should always
go for convenient solutions if they do not have serious drawbacks.
Breaking a tradition is NOT a major drawback.  What I consider a TRUE
example of certificate overloading is the QC sample certificate where
statements of different origin and life-time are sharing a single
certificate:
>
> Registered by: [e-mail]
>    surname: Gloeckner
>    given name: Petra
>    date of birth: October, 14th 1971
>    place of birth: Darmstadt
>    country of citizenship: DE
>    gender: female
>
> + (optionally)
>    photo: hash+URI of photo
>    signature: hash + URI of handwrittten signature
>
> Registered by: [e-mail]
>    organization: GMD
>    role: project manager QC
>
>
> Such a scheme probably requires you to apply for a new ID-card each time
you change occupation!
>
> For a point-by-point comparision between QC sample and the ID-solutions
featured in CyberPhone take a look at the URL:
>
> http://www.mobilephones-tng.com/miscspec/qcvscyber.html
>
> Of course the sample is just a sample but there are signs that the sample
represents what actually is in the works in some places!
>
> Anders Rundgren
> Senior Internet e-commerce Architect
>
>
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA14589 for ietf-pkix-bks; Sat, 8 May 1999 20:51:20 -0700 (PDT)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA14582 for <[e-mail]>; Sat, 8 May 1999 20:51:18 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id FAA04492 for <[e-mail]>; Sun, 9 May 1999 05:53:38 +0200
Received: from mega (t1o69p43.telia.com [62.20.144.43]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id FAA107359; Sun, 9 May 1999 05:53:16 +0200
Message-ID: <001601be99d7$99ef0770$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Petra Gloeckner" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
Subject: QC "Certificate Overloading"
Date: Sun, 9 May 1999 05:51:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id UAA14583
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There have been comments in this list that it is convenient to use certificates for storing large data objects like biometric templates but that this is "overloading the mechanism".  I disagree as you should always go for convenient solutions if they do not have serious drawbacks.   Breaking a tradition is NOT a major drawback.  What I consider a TRUE example of certificate overloading is the QC sample certificate where statements of different origin and life-time are sharing a single certificate:

Registered by: [e-mail] 
   surname: Gloeckner
   given name: Petra
   date of birth: October, 14th 1971
   place of birth: Darmstadt
   country of citizenship: DE
   gender: female

+ (optionally)
   photo: hash+URI of photo
   signature: hash + URI of handwrittten signature

Registered by: [e-mail]
   organization: GMD
   role: project manager QC


Such a scheme probably requires you to apply for a new ID-card each time you change occupation!

For a point-by-point comparision between QC sample and the ID-solutions featured in CyberPhone take a look at the URL:

http://www.mobilephones-tng.com/miscspec/qcvscyber.html

Of course the sample is just a sample but there are signs that the sample represents what actually is in the works in some places!

Anders Rundgren
Senior Internet e-commerce Architect






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11383 for ietf-pkix-bks; Fri, 7 May 1999 08:36:38 -0700 (PDT)
Received: from us-mta2.az05.bull.com (us-mta2.az05.bull.com [141.112.40.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA11378 for <[e-mail]>; Fri, 7 May 1999 08:36:35 -0700 (PDT)
From: [e-mail]
Received: by us-mta2.az05.bull.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 0725676A.0055B7B0 ; Fri, 7 May 1999 08:36:15 -0700
X-Lotus-FromDomain: BULL
To: [e-mail]
cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Blake Greenlee'" <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 7 May 1999 08:33:59 -0700
Subject: one more time on certificate extensions
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

sharon fixed some errors that she felt were too important to be left in the
document to be balloted. to wit:

- makes Annex M normative
- remove the restriction on per authority scope and raises the issue
- change titles of 2 annex M subclauses as requested

i have place the final final version of the Certificate Extension document,
CertExtFPDAMv6, up on the server in Office 97/98, .doc, and .pdf formats at

      ftp://ftp.bull.com/pub/OSIdirectory/Orlando99Output

this will be the version that i will send to the secretariat for ballot at
the end of this week

there are those who have picked up version 5. the editor recommends that
you retrieve version 6.

     hoyt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10033 for ietf-pkix-bks; Fri, 7 May 1999 06:29:42 -0700 (PDT)
Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10029 for <[e-mail]>; Fri, 7 May 1999 06:29:41 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA23966; Fri, 7 May 1999 06:29:32 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 07 May 1999 08:32:16 -0400
To: Hans Nilsson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Rename Qualified Certificates?
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that the name should be changed; however, I really do not like the
one you have proposed.  "Identity certificates" is a commonly used term
meaning that an identity is bound to a public key in a certificate.

Perhaps a merging of the two terms is better: Qualified Identity Certificates.

Russ


At 08:15 AM 5/7/99 +0200, Hans Nilsson wrote:
>Yesterday I attended a meeting with the European Standards Organization CEN,
>where we now are trying to prepare the necessary standardization for
>implementing the EU directive on Electronic Signatures. The work in PKIX is
>regarded as most relevant in this respect, and will be most likely be used
>and referenced a lot. This is also true for the current working draft on
>Qualified Certificates, which is very much in line with the requirements in
>Annex I of the directive.
>
>However, the term Qualified Certiciates is already being used in the
>Directive with a special meaning and definition ("a certifciate that meets
>the requirements laid down in Annex I and is provided by a certification
>service provider that fulfills the requirements laid down in annex II").
>
>Although I am partly responsible for "hijacking" the term QC from the
>directive and using it for our work, I now realise that this was not a very
>good decision, since the EU term also requires that the CA fulfils Annex II.
>We thus two honomyms that mean two different things.
>
>I would therefore like to propose that the PKIX term is changed to something
>else, and possibly more descriptive. My suggestion is "identity
>certificates", but there may be other good suggestions.
>
>Regards
>
>Hans Nilsson
>iD2 Technologies
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA08840 for ietf-pkix-bks; Fri, 7 May 1999 03:51:05 -0700 (PDT)
Received: from popmail.inbox.se (popmail.inbox.se [193.12.72.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA08836 for <[e-mail]>; Fri, 7 May 1999 03:51:03 -0700 (PDT)
Received: from stefan2 (accurata.inbox.se [193.12.72.24]) by popmail.inbox.se (8.9.3/8.9.3) with SMTP id MAA03076; Fri, 7 May 1999 12:04:14 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 07 May 1999 12:53:00 +0200
To: Hans Nilsson <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: Rename Qualified Certificates?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA08837
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hans,

Thank you for encouraging words, but concerning the naming issue... 
I must say that I'm divided in this question. Let me give some pros and cons.

First, as I view it, there really is no conflict in the meaning and use of the
term "Qualified Certificates".

In the PKIX draft the term "Qualified Certificates" denotes a certificate which
is aimed to support digital signatures which are considered functionally
equivalent with handwritten signatures. To do this it is assumed that the
issuing CA and the certificate has to be in conformance with national law.

The proposed EU-directive defines the term:
"qualified certificate" means a certificate which meets the requirements laid
down in Annex I and is provided by a certification service provider that
fulfills the requirements laid down in Annex II.

Still, as I see it, this is a Qualified Certificate ACCORDING to the
EU-directive. A Qualified Certificate within a different legal jurisdiction
would be something else. I don't think it would be wise by the EU commission to
take the term "Qualified Certificate" and say that THIS IS A CERTIFICATE
ACCORDING TO EUROPEAN LAW".

I believe more in the case where we say that "Qualified Certificates" are
certificates aimed to support electronic signatures which are considered
functionally equivalent with handwritten signatures, and then say that WITHIN
EUROPEAN LAW THIS MEANS CONFORMANCE WITH EU-DIRECTIVE ANNEX I AND ANNEX II.

The PKIX QC draft is ONLY a profile which as far as possible should give all
necessary functionality prescribed by any legal framework. So lets look at
EU-directive Annex I and see what functionality they require:

(I give my comments in line in capital letters)

EU-directive Qualified certificates must contain:
(x)     an indication that the certificate is issued as a qualified
certificate;

PROVIDED BY THE POLICY EXTENSION
(a)     the identification and the country of establishment of the
certification
service provider issuing it; 

PROVIDED BY THE ISSUER FIELD IN COMBINATION WITH THE POLICY OID AND OPTIONALLY
THE QC PROFILE OID

(b)     the name of the holder or a pseudonym which shall be identified as
such;


PROVIDED BOTH IN THE SUBJECT FIELD AND THE PERSONAL DATA FIELD

(c)     provision for a specific attribute of the holder to be included if
relevant, depending on the purpose for which the certificate is intended;

PROVIDED BY THE COMBINATION OF STANDARD X.520 ATTRIBUTES, THE KEY USAGE
EXTENSION AND THE POLICY EXTENSION

(d)     a signature verification data which corresponds to a signature creation
data under the control of the holder; 

THIS IS THE PUBLIC KEY

(e)     beginning and end of the period of validity of the certificate;  

THIS IS STANDARD STUFF

(f)     the identity code of the certificate; 

ALSO STANDARD STUFF

(g)     the advanced electronic signature of the certification service provider
issuing it; 

ALSO STANDARD STUFF

(h)     limitations on the scope of use of the certificate, if applicable; and

PROVIDED BY THE KEY USAGE EXTENSION AND THE POLICY EXTENSION
(i)     limitations on the value of transactions for which the certificate can
be used if applicable. 

PROVIDED BY THE POLICY EXTENSION

-------------------------------------------
My remarks show HOW the PKIX QC profile could be used to meet the requirements
of ANNEX I. There may be other ways and there may be other profiles for
"Qualified Certificates". There may also be other profiles which are profiling
the PKIX QC profile into specific national standards.

I say all this only to show that the PKIX use and the EU directive use of the
term "Qualified Certificates" are NOT in conflict. They are only describing
different aspects of the same thing, the legal and the technical.

BUT ON THE OTHER HAND.....

I can also see the problem IF EU tries to make this term an exclusive European
term tied ONLY to the European legal framework.

If so, I think we have to invent another term with the same meaning, but for
International use.

My candidate to another name, If we find that we have to change it, is:

"ES-Certificates"

... having the meaning of "Electronic Signature Certificates". This is to adopt
to the new trend of naming "legal" signatures as "Electronic signatures" while
letting the technical mechanism defined in X.509, remain as "digital
signatures".

/Stefan

At 08:15 AM 5/7/99 +0200, Hans Nilsson wrote:
>Yesterday I attended a meeting with the European Standards Organization CEN,
>where we now are trying to prepare the necessary standardization for
>implementing the EU directive on Electronic Signatures. The work in PKIX is
>regarded as most relevant in this respect, and will be most likely be used
>and referenced a lot. This is also true for the current working draft on
>Qualified Certificates, which is very much in line with the requirements in
>Annex I of the directive.
>
>However, the term Qualified Certiciates is already being used in the
>Directive with a special meaning and definition ("a certifciate that meets
>the requirements laid down in Annex I and is provided by a certification
>service provider that fulfills the requirements laid down in annex II").
>
>Although I am partly responsible for "hijacking" the term QC from the
>directive and using it for our work, I now realise that this was not a very
>good decision, since the EU term also requires that the CA fulfils Annex II.
>We thus two honomyms that mean two different things.
>
>I would therefore like to propose that the PKIX term is changed to something
>else, and possibly more descriptive. My suggestion is "identity
>certificates", but there may be other good suggestions.
>
>Regards
>
>Hans Nilsson
>iD2 Technologies

-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA06207 for ietf-pkix-bks; Fri, 7 May 1999 03:03:15 -0700 (PDT)
Received: from mb04.swip.net (mb04.swip.net [193.12.122.208]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA06203 for <[e-mail]>; Fri, 7 May 1999 03:03:12 -0700 (PDT)
Received: from [130.244.41.221] (dialup40-2-32.swipnet.se [130.244.40.96])  by mb04.swip.net (8.8.8/8.8.8) with ESMTP  id MAA04199 for <[e-mail]>;  Fri, 7 May 1999 12:05:29 +0200 (MET DST)
X-Sender: [e-mail]
Message-Id: <l03102807b3585380ed00@[130.244.41.221]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Fri, 7 May 1999 10:30:37 +0200
To: [e-mail]
From: Arne Nilsson <[e-mail]>
Subject: Re: Rename Qualified Certificates?
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA06204
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Hans Nilsson's suggestion to rename the PKIX Qualified
Certificate. It seems to me that EU plans to stipulate requirements on a
certificates and their issuance for them to qualify as Qualified
Certificates. This is an Certificate Policy issue, rather than a
Certificate profile issue. In the end EU may publish a Qualified
Certificate Certificate Policy under a seperate OID and possibly take some
responsibility for the auditing of CA:s claiming adherance to this policy.

/Arne Nilsson

_____________________________________________________________

Internet mail:	[e-mail]
Physical mail:	Abstracon
		Arne Nilsson
		Fyradalersgatan 9
		S-413 19 Göteborg
		SWEDEN
Tel. & fax no.:	[phone]
Mobile:		[phone]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA01128 for ietf-pkix-bks; Thu, 6 May 1999 23:13:54 -0700 (PDT)
Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA01124 for <[e-mail]>; Thu, 6 May 1999 23:13:53 -0700 (PDT)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.1960.3) id <K2GZSW3J>; Fri, 7 May 1999 08:15:26 +0200
Message-ID: <[e-mail]>
From: Hans Nilsson <[e-mail]>
To: [e-mail]
Subject: Rename Qualified Certificates?
Date: Fri, 7 May 1999 08:15:25 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yesterday I attended a meeting with the European Standards Organization CEN,
where we now are trying to prepare the necessary standardization for
implementing the EU directive on Electronic Signatures. The work in PKIX is
regarded as most relevant in this respect, and will be most likely be used
and referenced a lot. This is also true for the current working draft on
Qualified Certificates, which is very much in line with the requirements in
Annex I of the directive.

However, the term Qualified Certiciates is already being used in the
Directive with a special meaning and definition ("a certifciate that meets
the requirements laid down in Annex I and is provided by a certification
service provider that fulfills the requirements laid down in annex II").

Although I am partly responsible for "hijacking" the term QC from the
directive and using it for our work, I now realise that this was not a very
good decision, since the EU term also requires that the CA fulfils Annex II.
We thus two honomyms that mean two different things.

I would therefore like to propose that the PKIX term is changed to something
else, and possibly more descriptive. My suggestion is "identity
certificates", but there may be other good suggestions.

Regards

Hans Nilsson
iD2 Technologies



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27754 for ietf-pkix-bks; Thu, 6 May 1999 05:12:02 -0700 (PDT)
Received: from getafix.fcpl.co.in (Getafix.fcpl.co.in [196.1.104.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27747 for <[e-mail]>; Thu, 6 May 1999 05:11:58 -0700 (PDT)
Received: from risk ([196.1.104.25]) by getafix.fcpl.co.in (post.office MTA v2.0 0613 ID# 291-17719) with SMTP id AAA187 for <[e-mail]>; Thu, 6 May 1999 17:42:02 +0530
Message-ID: <003501be97ba$8cde9060$[e-mail]>
From: "Parag Namjoshi" <[e-mail]>
To: <[e-mail]>
Subject:  A data certification server question.
Date: Thu, 6 May 1999 17:48:28 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi All,

I have a question about DCS (Data certification server)
(draft-ietf-pkix-dcs-00.txt) .
(Same issue applies to the time-stamp draft too.)

The (now expired but the latest that I know of ) draft says,

   "The DCS signing key MUST be of a sufficient length to allow for
    a sufficiently long lifetime.  Even if this is done, the key
     will have a finite lifetime.  Thus, any token signed by the DCS
    SHOULD be time stamped (if authentic copies of old CRLs
    are available) or certified again (if they aren't) at a later
    date to renew the trust that exists in the DCS's signature.
    Data certification tokens could also be kept with an Evidence
    Recording Authority [ISONR] to maintain this trust."

This signifies that when DCS / TS certificate expires, the request must
be sent again. This poses two problems :

1.  Token holder must go through the process each time when DCS / TS
certificate
     will expire . Another related problem would be keeping track of which
tokens would
     be expiring and when. If left to human agencies,it would be error prone
(you would
     probably end up having expired tokens ) and done automatically (say one
day after
     the certificate expired) could result in flooding the server.

2.  Even worse, the time in the token ( DCSTime or the timestamp ) will bear
newer time.This
     would probably not be acceptable in many situations.

I would like to suggest addtional request that would take previously issued
token & issue
a new one. The server should be required to have access to its older
certificates . Then  it
can verify the older token & issue new token but containing same time as the
previous
token.

Considering long term nature of DCS / timestamp  protocols  (For example it
could be years
since token was issued that it needs to be verified.) it would be a leap of
faith to assume that
authentic copies of the old CRL's would be assesible but it would be
certainly be feasible
for the DCS/TS to store/have access to their older certificates.  I think
the reissuing of token
requests would address both the problems .

Thanks with regards,
Parag Namjoshi



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA15001 for ietf-pkix-bks; Wed, 5 May 1999 20:02:59 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA14992 for <[e-mail]>; Wed, 5 May 1999 20:02:57 -0700 (PDT)
Received: 	id XAA15815; Wed, 5 May 1999 23:02:36 -0400
Received: by gateway id <J96LCJPQ>; Wed, 5 May 1999 23:04:58 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B113C70C@sothmxs06>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Blake Greenlee'" <[e-mail]>
Cc: "'Hoyt Kesterson'" <[e-mail]>
Subject: X.509 FPDAM available
Date: Wed, 5 May 1999 23:04:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The final version of the X.509 Certificate Extension
document, CertExtFPDAMv5, is up on the Bull server in Office 97/98, .doc,
and
.pdf formats at

      ftp://ftp.bull.com/pub/OSIdirectory/Orlando99Output

this will be the version that will be sent to the ISO secretariat this week
for ballot. 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA07201 for ietf-pkix-bks; Wed, 5 May 1999 18:35:04 -0700 (PDT)
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA07197 for <[e-mail]>; Wed, 5 May 1999 18:35:03 -0700 (PDT)
Received: from default (207-172-49-26.s26.tnt14.ann.va.dialup.rcn.com [207.172.49.26]) by smtp2.erols.com (8.8.8/8.8.5) with SMTP id VAA01356 for <[e-mail]>; Wed, 5 May 1999 21:38:40 -0400 (EDT)
From: "edward sestak" <[e-mail]>
To: <[e-mail]>
Subject: mail delivery has stopped
Date: Wed, 5 May 1999 21:35:20 -0400
Message-ID: <01be9760$b476ed20$1a31accf@default>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01BE973F.2D654D20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01BE973F.2D654D20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Since, 3 May pkix mail has stopped; please re-start; Thks
Ed Sestak=20
[e-mail]=20

------=_NextPart_000_001A_01BE973F.2D654D20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Since, 3 May pkix mail has stopped; =
please=20
re-start; Thks</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Ed Sestak&nbsp;</FONT></DIV>
<DIV><FONT color=3D#000000=20
size=3D2>[e-mail]&nbsp;</FONT></DIV></BODY></HTML>

------=_NextPart_000_001A_01BE973F.2D654D20--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA23209 for ietf-pkix-bks; Tue, 4 May 1999 13:45:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA23205 for <[e-mail]>; Tue, 4 May 1999 13:45:21 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA05773; Tue, 4 May 1999 16:47:22 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0bb354d96976fe@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a03b354c34f454b@[128.89.0.110]>
Date: Tue, 4 May 1999 16:48:05 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OSCP BIG BANG
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

>>
>> The change from MAY to MUST was intentional. The notion is that a CA is
>> considered as OCSP compliant only if it is capable of putting the AIA
>> extension, with OCSP-specific values, into certs that it generates.
>
>What do you mean here ? He is capable to do it, but it does not  ? This is
>a very
>odd concept to me.

Yes, I do mean that the CA must be capable of generating such certs, but it
is a local matter as to whether such certs are, in fact, generated.  We are
manadting a capability for a compliant product, not usage constraints on
the product.

<snip>

>> To maximize interoperability, we want it to be the case that if a CA
>> asserts OCSP compliance, then it MUST be able to generate certs that will
>> point to an OCSP server.
>
>I cannot understand the above sentence. Do you mean " MUST generate certs that
>will point to an OCSP server" or "MAY chose not to generate certs that
>will point
>to an OCSP server " ?

I mean MUST be capable of generating such certs, as explained above.  Of
course the CA may choose not to do so, as a matter of local policy.  Again,
we are discussing what a product MUST be able to do in order to be
compliant, not how someone operating the CA must behave.

>> Also, remember the difference between the CA being
>> ABLE to generate this extension, and actually puttiong it in certs. Only
>> the capability is required of the CA to be compliant; the election to  ake
>> use of the facilility is a local matter.  A CA that does not support this
>> use of AIA can still be PKIX compliant re 2459, just not compliant with the
>> OCSP RFC.
>
>The first question is whether a certificate, whose status may be queried using
>OCSP, MUST always contain this extension or not. What is the answer ?

A CA may choose to not insert the extension in a cert, which presumes that
the clients will have local config info that allows them to locate one ore
more OCSP servers that they choose to rely on.  For example,

>Then, according to this answer, the second question is : does this solve
>the "BIG
>BANG" situation ?

No, I have to admit that none of this addresses the BIG BANG scenario, any
more than that scenario was addressed in the initial OCSP draft.  Depending
on the environment, this may be a big problem, or it may be easy.  As John
Linn mentioned in his message, if the CA deals with a closed community,
then the local config option for clients can ease the transition and the CA
can issue new certs with the extension on a gradual basis.  A massive
reissuance may be needed in a completely open PKI, but that can be effected
in various ways, not just revocation of all the EE certs, e.g., one might
revoke the CA cert and reissue it as well as all of the EE certs.  One
might introduce new EE certs with the extension, and continue to maintain
CRLs, to smooth the transition.

So, unless the WG feels that the BIG BANG scenario is sufficiently critical
as to warrant a move of the AIA extension to the CA cert, from EE certs, I
feel that we should not re-open this issue.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA16977 for ietf-pkix-bks; Tue, 4 May 1999 10:00:24 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16973 for <[e-mail]>; Tue, 4 May 1999 10:00:21 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id TAA18458; Tue, 4 May 1999 19:01:22 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id TAA25324; Tue, 4 May 1999 19:01:22 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Tue, 04 May 1999 19:02:50 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: OSCP BIG BANG
References: <v04020a15b34509844f3d@[128.33.238.34]> <v04020a25b34641c27a7f@[128.33.238.34]> <v04020a0ab354d340045e@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

As explained by John, the problem is NOT simply moving the AIA extension for
OCSP servers from an EE cert to a CA cert. The problem is to avoid the BIG
BANG situation. It can simply be avoided by not mandating CAs to support that
extension in leaf certificates.

Regards,

Denis


> Denis,
>
> I appreciate the arguments you make in favor of moving the AIA extension
> for OCSP servers from an EE cert to a CA cert.  However, in reopening WG
> last call, we are addressing only the changes made to the document after
> its was approved by the WG and the IESG. No other changes are on the table
> now.
>
> Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA16939 for ietf-pkix-bks; Tue, 4 May 1999 09:55:55 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16935 for <[e-mail]>; Tue, 4 May 1999 09:55:52 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id SAA39978; Tue, 4 May 1999 18:56:54 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id SAA21848; Tue, 4 May 1999 18:56:53 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Tue, 04 May 1999 18:58:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: OSCP BIG BANG
References: <v04020a03b354c34f454b@[128.89.0.110]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

My reply is along the lines.

> John,
>
> >I think that another point remains from Denis' comment, independent of the
> >suggestion to move information from leaf certificates to the CA certificate.
> >This concerns the CA conformance level for ability to include OCSP
> >accessLocation and accessMethod information in generated certificates, which
> >changed from MAY in -07 to MUST in -08.  Since the case of OCSP
> >accessLocations being locally configured, without need for
> >certificate-resident indicators, is explicitly allowed, I read the first
> >paragraph of 4.1 as appropriately conditional, not mandating that a CA be
> >able to include AIA extensions within environments where OCSP
> >accessLocations are to be configured locally.  I believe that the same
> >conditionality should apply to the second paragraph as well, covering
> >specific contents within the AIA, which -08 states as covering all CAs that
> >support OCSP services.
>
> The change from MAY to MUST was intentional. The notion is that a CA is
> considered as OCSP compliant only if it is capable of putting the AIA
> extension, with OCSP-specific values, into certs that it generates.

What do you mean here ? He is capable to do it, but it does not  ? This is a very
odd concept to me.

>  All
> compliant OCSP clients MUST be locally configurable re OCSP servers, but
> this is independent of what a CA does re OCSP, e.g., even if the CA puts in
> the OCSP server pointer, the client is free to ignore it.

The case of OCSP client is different but is not the center of the discussion.

> To maximize interoperability, we want it to be the case that if a CA
> asserts OCSP compliance, then it MUST be able to generate certs that will
> point to an OCSP server.

I cannot understand the above sentence. Do you mean " MUST generate certs that
will point to an OCSP server" or "MAY chose not to generate certs that will point
to an OCSP server " ?


> Also, remember the difference between the CA being
> ABLE to generate this extension, and actually puttiong it in certs. Only
> the capability is required of the CA to be compliant; the election to  ake
> use of the facilility is a local matter.  A CA that does not support this
> use of AIA can still be PKIX compliant re 2459, just not compliant with the
> OCSP RFC.

The first question is whether a certificate, whose status may be queried using
OCSP, MUST always contain this extension or not. What is the answer ?

Then, according to this answer, the second question is : does this solve the "BIG
BANG" situation ?

Denis

> Steve



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA16528 for ietf-pkix-bks; Tue, 4 May 1999 09:47:22 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA16524 for <[e-mail]>; Tue, 4 May 1999 09:47:20 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA19464; Tue, 4 May 1999 12:49:21 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a0ab354d340045e@[128.89.0.110]>
In-Reply-To: <[e-mail]>
References: <v04020a15b34509844f3d@[128.33.238.34]> <v04020a25b34641c27a7f@[128.33.238.34]>
Date: Tue, 4 May 1999 12:42:11 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OSCP BIG BANG
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I appreciate the arguments you make in favor of moving the AIA extension
for OCSP servers from an EE cert to a CA cert.  However, in reopening WG
last call, we are addressing only the changes made to the document after
its was approved by the WG and the IESG. No other changes are on the table
now.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15833 for ietf-pkix-bks; Tue, 4 May 1999 09:27:21 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15828 for <[e-mail]>; Tue, 4 May 1999 09:27:19 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA15646; Tue, 4 May 1999 12:29:20 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04020a03b354c34f454b@[128.89.0.110]>
In-Reply-To:  <[e-mail]>
Date: Tue, 4 May 1999 12:26:11 -0400
To: "Linn, John" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: OSCP BIG BANG
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John,

>I think that another point remains from Denis' comment, independent of the
>suggestion to move information from leaf certificates to the CA certificate.
>This concerns the CA conformance level for ability to include OCSP
>accessLocation and accessMethod information in generated certificates, which
>changed from MAY in -07 to MUST in -08.  Since the case of OCSP
>accessLocations being locally configured, without need for
>certificate-resident indicators, is explicitly allowed, I read the first
>paragraph of 4.1 as appropriately conditional, not mandating that a CA be
>able to include AIA extensions within environments where OCSP
>accessLocations are to be configured locally.  I believe that the same
>conditionality should apply to the second paragraph as well, covering
>specific contents within the AIA, which -08 states as covering all CAs that
>support OCSP services.

The change from MAY to MUST was intentional. The notion is that a CA is
considered as OCSP compliant only if it is capable of putting the AIA
extension, with OCSP-specific values, into certs that it generates.  All
compliant OCSP clients MUST be locally configurable re OCSP servers, but
this is independent of what a CA does re OCSP, e.g., even if the CA puts in
the OCSP server pointer, the client is free to ignore it.

To maximize interoperability, we want it to be the case that if a CA
asserts OCSP compliance, then it MUST be able to generate certs that will
point to an OCSP server. Also, remember the difference between the CA being
ABLE to generate this extension, and actually puttiong it in certs. Only
the capability is required of the CA to be compliant; the election to  ake
use of the facilility is a local matter.  A CA that does not support this
use of AIA can still be PKIX compliant re 2459, just not compliant with the
OCSP RFC.

Steve


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA15829 for ietf-pkix-bks; Tue, 4 May 1999 09:27:20 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA15823 for <[e-mail]>; Tue, 4 May 1999 09:27:18 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA00209; Tue, 4 May 1999 18:29:20 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 4 May 1999 18:29:20 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA19367; Tue, 4 May 1999 18:29:19 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA12636; Tue, 4 May 1999 18:29:19 +0200
Date: Tue, 4 May 1999 18:29:19 +0200
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: OSCP BIG BANG
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Peter,
> 
> The subject certificate in this context is the certificate that is being
> validated.

Do you mean 'As if the corresponding subject cert would
have an AIA with these parameters.'

If the certificate really HAS the extension, then the verifier
could probably go directly to the service. 

If not, I think a good way to publish the location of a
service provider is to have it directly in an extension
with an oid of id-ocsp and the syntax of accessLocation
directly in a CA cert or in an OCSP responder cert. For
the CA this indicates the url of an OCSP responder for
all certificates issued by that CA, for an OCSP
responder cert it indicate the service to verify certs
signed by the CA.

This would resolve in an elgant way Denis concerns,
This can happen either in self signed CA certs or
in any non self signed CA cert. 

This is not just a method for OCSP, but a general technique 
that can be used for *ANY* service where you would have a
pointer in an EE AIA signed by the authority in question
to avoid fat EE certificates.  

In earlier drafts of PKIX there had just been EEInfoaccess
and CAInfoaccess, they are obviously not necessary
as extensions, but the functionality is useful

EE and CA can be distinguished by the nature of the cert.
==> you end with ONE feature. 
Now, whenever someone defines an accessMethod oid to be
usable in an AIA, one can directly define an extension
with that oid and accessLocation as a value telling the
obvious rather obvious thing if it is used in a CA
certificate. 

For a "service" certificate the interpretation
differs slightly. If one doesn't like id-ocsp extension,
in a service certificate, one could also
have an servicelocator extension in such a server cert.

"My issuer tells that I am the service locator
 for Name, and here is the URL." 

I wonder whether some text should be included
in OCSP or in an updated version of 2459, or
in an independant document. 

Peter









Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13339 for ietf-pkix-bks; Tue, 4 May 1999 08:22:57 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13335 for <[e-mail]>; Tue, 4 May 1999 08:22:57 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA01253; Tue, 4 May 1999 08:20:24 -0700 (PDT)
Received: from newman.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA26278; Tue, 4 May 1999 08:24:30 -0700 (PDT)
Received: by newman.verisign.com with Internet Mail Service (5.5.2448.0) id <J6LWY02N>; Tue, 4 May 1999 08:24:31 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, Michael Myers <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: OSCP BIG BANG
Date: Tue, 4 May 1999 08:24:30 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

The subject certificate in this context is the certificate that is being
validated.

Mike

> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Tuesday, May 04, 1999 8:16 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: OSCP BIG BANG
> 
> 
> Question: 
> 
> What is the 'subject certificate' in the following description. 
> 
> - EE cert to be validated ? 
> - The OCSP cert of a responder? 
> - A CA certificate? 
> 
> 
> 5.4.6  Service Locator
> 
>    An OCSP server may be operated in a mode whereby the 
> server receives
>    a request and routes it to the OCSP server which is known to be
>    authoritative for the identified certificate.  The serviceLocator
>    request extension is defined for this purpose.  This extension is
>    included as one of the singleRequestExtensions in requests.
> 
>    id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { 
> id-pkix-ocsp 7 }
> 
>    ServiceLocator ::= SEQUENCE {
>        issuer    Name,
>        locator   AuthorityInfoAccessSyntax OPTIONAL }
> 
>    Values for these fields are obtained from the 
> corresponding fields in
>    the subject certificate.
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13117 for ietf-pkix-bks; Tue, 4 May 1999 08:17:56 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA13113 for <[e-mail]>; Tue, 4 May 1999 08:17:55 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 4 May 1999 15:18:43 UT
Received: from exna01.securitydynamics.com (exna01.securitydynamics.com [10.100.8.39]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA01395; Tue, 4 May 1999 11:14:11 -0400 (EDT)
Received: by exna01.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <JK3RKFK4>; Tue, 4 May 1999 11:15:20 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, Michael Myers <[e-mail]>
Cc: Stephen Kent <[e-mail]>, [e-mail]
Subject: RE: OSCP BIG BANG
Date: Tue, 4 May 1999 11:20:11 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think that another point remains from Denis' comment, independent of the
suggestion to move information from leaf certificates to the CA certificate.
This concerns the CA conformance level for ability to include OCSP
accessLocation and accessMethod information in generated certificates, which
changed from MAY in -07 to MUST in -08.  Since the case of OCSP
accessLocations being locally configured, without need for
certificate-resident indicators, is explicitly allowed, I read the first
paragraph of 4.1 as appropriately conditional, not mandating that a CA be
able to include AIA extensions within environments where OCSP
accessLocations are to be configured locally.  I believe that the same
conditionality should apply to the second paragraph as well, covering
specific contents within the AIA, which -08 states as covering all CAs that
support OCSP services.

--jl


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12997 for ietf-pkix-bks; Tue, 4 May 1999 08:15:39 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12993 for <[e-mail]>; Tue, 4 May 1999 08:15:37 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA26503; Tue, 4 May 1999 17:16:13 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Tue, 4 May 1999 17:16:13 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id RAA18268; Tue, 4 May 1999 17:16:07 +0200
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id RAA12608; Tue, 4 May 1999 17:16:07 +0200
Date: Tue, 4 May 1999 17:16:07 +0200
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OSCP BIG BANG
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Question: 

What is the 'subject certificate' in the following description. 

- EE cert to be validated ? 
- The OCSP cert of a responder? 
- A CA certificate? 


5.4.6  Service Locator

   An OCSP server may be operated in a mode whereby the server receives
   a request and routes it to the OCSP server which is known to be
   authoritative for the identified certificate.  The serviceLocator
   request extension is defined for this purpose.  This extension is
   included as one of the singleRequestExtensions in requests.

   id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }

   ServiceLocator ::= SEQUENCE {
       issuer    Name,
       locator   AuthorityInfoAccessSyntax OPTIONAL }

   Values for these fields are obtained from the corresponding fields in
   the subject certificate.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA02319 for ietf-pkix-bks; Tue, 4 May 1999 02:56:11 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA02315 for <[e-mail]>; Tue, 4 May 1999 02:56:07 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id LAA47116; Tue, 4 May 1999 11:57:05 +0200
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA31356; Tue, 4 May 1999 11:57:04 +0200 (DFT)
Message-ID: <[e-mail]>
Date: Tue, 04 May 1999 11:58:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: OSCP BIG BANG
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Denis,
>
> I understand Steve is on vacation this week.  But I do wish to clarify -08
> against your request.
>
> You are restating a request for a requirement that we discussed during the
> original last call.  Namely, a mandated relocation of AIA information from
> the subject certificate to the CA certificate.

There has never been such a request, i.e. a *mandated* relocation of AIA
information from
the subject certificate to the CA certificate.

The current text is in fact advocating *against* the adoption of conformant CAs
supporting OCSP. If we keep the current text we will be faced with two
situations:

a) not conformant CAs, supporting OCSP,
b) conformant CAs, not supporting OCSP.

Either situation would not be very good. :-(

Denis


> We debated this issue on the
> list during the original last call with the resolution that the text remains
> as written.  In constrast, Steve asked for additional clarity and precision
> regarding an existing requirement; this we responded to.
>
> We are not in the mode at this very late stage of introducing new
> requirements or reopening issues which were previously resolved.  That work
> has been done.  My thanks to all who provided their time and energy to the
> effort.
>
> Mike
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 28, 1999 6:45 AM
> > To: Stephen Kent
> > Cc: [e-mail]
> > Subject: OSCP BIG BANG
> >
> >
> > The original title was "Re: WG Last call, redux".
> >
> > Steve,
> >
> > Thanks for giving the hint for the change. :-)
> >
> > In the previous text, as it will be explained in detail, we
> > were somewhat
> > inconsistent having a SHALL followed by a MAY.
> >
> > The new text is proposing to keep the SHALL and change the
> > MAY into a MUST.
> > I am basically proposing to change the SHALL into a SHOULD
> > and keep the MAY.
> >
> > Both solutions are consistent. :-)
> >
> > It seems now the Pandora box is re-opened  :-) and we have a
> > chance to fix the
> > issue.
> >
> > First, let me duplicate the section from the version 08 so
> > that people may save
> > time, if they wish to follow this thread.
> >
> > In version -08
> >
> > 4.  Functional Requirements
> >
> > 4.1  Certificate Content
> >
> > In order to convey to OCSP clients a well-known point of
> > information access,
> > CAs SHALL provide the capability to include the
> > AuthorityInfoAccess extension
> > (defined in [RFC 2459], section 4.2.2.1) in certificates that
> > can be checked
> > using OCSP.  Alternatively, the accessLocation for the OCSP
> > provider may be
> > configured locally at the OCSP client.
> >
> > CAs that support an OCSP service, either hosted locally or
> > provided by an
> > Authorized Responder, MUST provide for the inclusion of a value for a
> > uniformResourceIndicator (URI) accessLocation and the OID
> > value id-ad-ocsp for
> > the accessMethod in the AccessDescription SEQUENCE.
> >
> > The value of the accessLocation field in the subject
> > certificate defines the
> > transport (e.g. HTTP) used to access the OCSP responder and
> > may contain other
> > transport dependent information (e.g. a URL).
> >
> >
> > In version 07 we had:
> >
> >
> > 4.  Functional Requirements
> >
> > 4.1  Certificate Content
> >
> > In order to convey to OCSP clients a well-known point of
> > information access,
> > CAs SHALL provide the capability to include the
> > AuthorityInfoAccess extension
> > (defined in [PKIX1], section 4.2.2.1) in certificates that
> > can be checked using
> > OCSP.  Alternatively, the accessLocation for the OCSP provider may be
> > configured locally at the OCSP client.
> >
> > CAs that support an OCSP service, either hosted locally or
> > provided by an
> > Authorized Responder, MAY provide a value for a
> > uniformResourceIndicator (URI) accessLocation and the OID
> > value id-ad-ocsp for
> > the accessMethod in the AccessDescription SEQUENCE.
> >
> > The value of the accessLocation field in the subject
> > certificate defines the
> > transport (e.g. HTTP) used to access the OCSP responder and
> > may contain other
> > transport dependent information (e.g. a URL).
> >
> > (...)
> >
> > The « MAY » in the second paragraph has been changed into a « MUST ».
> >
> > Leaving the text out for a moment, let us consider the
> > following scenario:
> >
> > A CA is started up with a CRL scheme. After one year of
> > operation, the CA
> > wishes to offer an *additional* service available for *all*
> > the certificates,
> > i.e. an On-line Certificate Status (OCS) Service.
> >
> > For doing so, there is one single option: to revoke all the current
> > certificates and re-issue new certificates with the
> > appropriate extension.
> >
> > This is a BIG BANG situation. :-(
> >
> > The consequences are quite important, among them, the size of
> > the CRLs is going
> > to increase dramatically (there is no reason to stop that service).
> >
> > The concern is that a smooth transition cannot occur. What
> > can we do ? Is there
> > a panacea to this problem ?
> >
> > Let us now take a closer look at the text. The last sentence
> > of the fist
> > paragraph from 4.1 says: « Alternatively, the accessLocation
> > for the OCSP
> > provider *may* be configured locally at the OCSP client. ».
> > If this is the
> > case, then the extension is not used. If someone wanted to
> > deploy a system by
> > configuring locally the system, CAs would nevertheless be
> > mandated to support
> > the extension.  :-(
> >
> > This is one argument for having SHALL changed into SHOULD,
> > i.e. « In order to
> > convey to OCSP clients a well-known point of information
> > access, CAs SHOULD
> > provide the capability to include the AuthorityInfoAccess extension »
> >
> > When the local configuration is NOT used, let us now attempt
> > to solve the BIG
> > BANG issue, and let us take a look at the text from RFC 2459.
> >
> > « 4.2.2.1  Authority Information Access
> >
> > The authority information access extension indicates how to access CA
> > information and services for the issuer of the certificate in
> > which the
> > extension appears. Information and services may include
> > on-line validation
> > services and CA policy data.  (The location of CRLs is not
> > specified in this
> > extension; that information is provided by the cRLDistributionPoints
> > extension.)  This extension may be included in subject or CA
> > certificates, and
> > it MUST be non-critical. »
> >
> > The text allows the extension to be placed in CA certificate.
> > To my knowledge,
> > a self-signed certificate is also a CA certificate. So it is
> > possible to have
> > that extension is a self-signed certificate. The advantage is
> > two folds:
> >
> > 1) the content of a self-signed certificate may change
> > without affecting the
> > content of the leaf certificates or of the cross-certificates.
> >
> > 2) since the extension is not in a leaf certificate, then it
> > makes leaf
> > certificates smaller (remember low-fat leaf certificates ?)
> >
> > We have defined in CMP a protocol to allow a certificate
> > rollover for trust
> > points, so we know how to handle the renewal of a self-signed
> > certificate.
> >
> > Now, I still guess that some people would like the current
> > text when a CA is
> > started from the very beginning with an OCS service or when
> > that service is
> > gradually offered to renewed certificates. So I would now
> > propose some text
> > that handles all the three cases. Here is the new proposal
> > for a text to fit
> > under 4.1.
> >
> >
> > « 4.1  Certificate Content
> >
> >  In order to convey to OCSP clients a well-known point of
> > information access,
> > CAs SHOULD provide the capability to include the
> > AuthorityInfoAccess extension
> > (defined in [RFC2459], section 4.2.2.1) either in every
> > certificate that can be
> > checked using OCSP or in a self-signed certificate.
> > Alternatively, the
> > accessLocation for the OCSP provider may be configured
> > locally at the OCSP
> > client.
> >
> > CAs that support an OCSP service, either hosted locally or
> > provided by an
> > Authorized Responder, MAY provide for the inclusion of a value for a
> > uniformResourceIndicator (URI) accessLocation and the OID
> > value id-ad-ocsp for
> > the accessMethod in the AccessDescription SEQUENCE.
> >
> > The value of the accessLocation field in the subject
> > certificate defines the
> > transport (e.g. HTTP) used to access the OCSP responder and
> > may contain other
> > transport dependent information (e.g. a URL). »
> >
> >
> > Note: the other major change around this topic is in section 5.2.2.2
> > Authorized Responders:
> >
> >
> > In version 08 we have:
> >
> >  (...)
> >
> > 5.2.2.2  Authorized Responders
> >
> >    The key that signs a certificate's status information need
> > not be the
> >    same key that signed the certificate. It is necessary however to
> >    ensure that the entity signing this information is authorized to do
> >    so.  Therefore, a certificate's issuer MUST either sign the OCSP
> >    responses itself or it MUST explicitly designate this authority to
> >    another entity.  OCSP signing delegation SHALL be designated by the
> >    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
> >    extension included in the OCSP response signer's certificate.  This
> >    certificate MUST be issued directly by the CA that issued the
> >    certificate in question.
> >
> >
> >    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> >
> >    Systems or applications that rely on OCSP responses MUST be capable
> >    of detecting and enforcing use of the id-ad-ocspSigning value as
> >    described above. They MAY provide a means of locally
> > configuring one
> >    or more OCSP signing authorities, and specifying the set of CAs for
> >    which each signing authority is trusted. They MUST reject the
> >    response if the certificate required to validate the
> > signature on the
> >    response fails to meet at least one of the following criteria:
> >
> >    1. Matches a local configuration of OCSP signing authority for the
> >     certificate in question; or
> >
> >    2. Is the certificate of the CA that issued the certificate in
> >     question; or
> >
> >    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
> >     extension and is issued by the CA that issued the certificate in
> >     question."
> >
> >    Additional acceptance or rejection criteria may apply to either the
> >    response itself or to the certificate used to validate the
> > signature
> >    on the response.
> >
> >
> > While in version -07 we have:
> >
> > 5.2.2.2  Authorized Responders
> >
> >    The key that signs a certificate's status information need
> > not be the
> >    same key that signed the certificate. A certificate's issuer MAY
> >    explicitly delegate OCSP signing authority by issuing a certificate
> >    including an extendedKeyUsage extension in the OCSP signer's
> >    certificate containing the value id-kp-OCSPSigning.
> >
> >    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> >
> >
> > Denis
> >
> >
> > > Several folks pointed out that I made the re-opening of
> > last call into a
> > > treasure hunt!  Sorry 'bout that.  I am away from the
> > office and not easily
> > > able to provide a diff, but I can describe the goal for the
> > changes, which
> > > resulted in both editorial and sunstantive modifications to
> > the text.
> > >
> > > The concern I raised with the OCSP authors was that it was
> > not clear what
> > > the hard and fast requirements were for CAs and clients
> > with regard to
> > > supporting three different ways that OCSP can be "enabled."
> > I felt it
> > > important to ensure that CAs and clients that claim
> > comformance would
> > > provide a set of confuguration controls that would allow
> > interoperability,
> > > if properly configured. So, the resvied text tries to make
> > this perfectly
> > > clear. The final form of the requirements, with some abstraction, is
> > > sumarized below:
> > >
> > >         - an OCSP-compliant CA SHALL be capable of issuing
> > OCSP responses
> > > that are signed ditrectly by the CA, and MUST be able to
> > designate an OCSP
> > > responder by issuing an appropriately marked certificate
> > directly to the
> > > responder.  the choice or direct vs. delegated OCSP
> > responses is a local,
> > > administrative option. the CA also SHALL be capable of
> > putting the AIA
> > > extension into certs when it is the intent that these certs
> > will be checked
> > > via OCSP, and MUST be capable of populating this extension
> > with the OID
> > > specifying OCSP access method and a URI for such access.
> > (This last part
> > > was changed from a MAy to a MUST, which seems reasonable to
> > ensure the goal
> > > cited above.)
> > >
> > >         - an OCSP-compliant client MUST be able to accept
> > OCSP responses
> > > via three different means: responses signed by the CA that
> > issued the cert
> > > in question, responses signed by a responder directly
> > designated by that
> > > CA, or via a locally designated responder.  It is a local
> > administrative
> > > choice as to which of these options if enabled. If local
> > designation is
> > > enabled, vendors have choices as to how fancy it gets,
> > e.g., how many OCSP
> > > responders are specified, how one knows which ones are authorized to
> > > provide status for which sets of certs, etc.
> > >
> > > Steve
> >



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA19775 for ietf-pkix-bks; Mon, 3 May 1999 05:42:32 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA19771 for <[e-mail]>; Mon, 3 May 1999 05:42:30 -0700 (PDT)
Received: 	id IAA10324; Mon, 3 May 1999 08:40:55 -0400
Received: by gateway id <J96LBZ34>; Mon, 3 May 1999 08:43:18 -0400
Message-ID: <01E1D01C12D7D211AFC70090273D20B113C6E5@sothmxs06>
From: Sharon Boeyen <[e-mail]>
To: "'Alan Lloyd'" <[e-mail]>, Sharon Boeyen <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Blake Greenlee'" <[e-mail]>
Subject: RE: Summary from April X.509 meeting 
Date: Mon, 3 May 1999 08:43:09 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There was no requirement raised in the meeting for indicating in a CRL that
it covers certs issued under a given policy and there isn't any extension
that would provide that currently in a CRL.

The editing process that is finishing up now is restricted to ensuring that
the agreements reached at the meeting are properly reflected in the
document. Any new requirements would need to be submitted as ballot comments
for the next round. These can be submitted as national comments through ISO
bodies or as comments from official liaison organizations, including IETF.

Sharon


-----Original Message-----
From: Alan Lloyd [mailto:[e-mail]]
Sent: Sunday, May 02, 1999 8:26 PM
To: 'Sharon Boeyen'; '[e-mail]'; '[e-mail]'; 'Blake
Greenlee'
Subject: RE: Summary from April X.509 meeting 


Sharon - thanks for that - its very useful.

One area that may have been covered in the items below - but could you
confirm. 
We can apply Application type policies to certificate management -
therefore creating a logical, policy based environment for issueance,
validation and usage. However, a CRL does not seem to have anyway of
relating it to a  certificate policy - therefore one cannot include a
policy based revocation environment. ie. only process the CRLs that
relate to the issueance and usage certificate policy.

509 1997 - 12.2.2 - Only permits the cert extension Auth Key Id to be
used in CRLs and the other existing CRL exts are not policy related.

Is this a requirement or has been covered below ?

regards and thanks alan

> -----Original Message-----
> From:	Sharon Boeyen 
> Sent:	Saturday, May 01, 1999 2:42 AM
> To:	'[e-mail]'; '[e-mail]'; 'Blake Greenlee'
> Subject:	Summary from April X.509 meeting 
> 
> As you know, the meeting that resolved ballot comments on the PDAM to
> X.509
> was held a couple of weeks ago. I'm still making the final revisions
> to the
> text, based on meeting participant feedback to my drafts. The final
> text
> that will be sent out for FPDAM (Final Proposed Draft Amendment) will
> be
> available mid - late next week. In an effort to improve the flow of
> communication between the X.509 group and other groups interested in
> that
> work, I'm sending this as an INFORMAL summary of some of the changes
> to the
> PDAM resulting from that meeting. Because the document is still under
> review
> by attendees it is possible that the end result may differ slightly
> from the
> way I've recorded here, but I think these are fairly representative
> (editorial and other minor changes excluded).
> 
> Also, at the end I'll provide a summary of the defect reports
> currently
> against X.509. I'm hoping to have the formal defect reports and the
> formal
> Draft Technical Corrigenda (DTC) for all of these also available
> within a
> week. You will notice that some of these defect reports are very old
> and
> resolutions were agreed two years ago. However, some have not yet been
> formally balloted as DTCs yet. 
> 
> ISO ballots on the FPDAM and on all DTCs for outstanding defect
> reports are
> expected to be conducted over the summer months and resolution of
> those
> ballots is expected to occur in October. 
> 
> When the documents have been completed and are available on a server,
> I'll
> post a notice indicating where they can be found. 
> 
> ------------------------------------------------------
> FPDAM major changes:
> 1. X.509 will be re-titled "Public-Key and Attribute Certificate
> Frameworks". It will be re-structured into 4 major sections: i)
> General
> Introduction ii) Public-key certificate framework iii) Attribute
> certificate
> framework iv) Directory use of public-key and attribute certificate
> frameworks. Annex B will be deleted. 
> 
> 2. CRLs - Clarified a number of issues relevant to 97 delta CRLs:
>     - cert placed on hold and subsequently released (both on deltas) -
> nothing need be carried forward to new base
>     - cert revoked on delta and expires prior to issuance of new base
> -
> revocation gets carried forward to new base
>     - base crl pointed to be delta crl must be complete for given
> scope (ie
> can be a full and complete CRL, distribution pt CRL etc)
>    New enhancements in the area of delta CRLs
>     - can issue delta CRLs for a base that was not published as a CRL
> complete for scope  ('virtual' complete for scope CRL would be locally
> constructed from published CRLs)
>     - can identify base crl by its update time and/or crl number
>     - new 'stream identifier' extension to enable unique
> identification of a
> CRL among all CRLs issued by a particular issuer
>    General CRL handling 
>     - Annex M updated to align with new agreements and new extensions
> including:
>          - if basicConstraints extension is absent in a v3 cert it is
> an
> end-entity cert (previously was type unknown)
>          - no special case situation for ca or key compromise reason
> codes -
> relying party checks crls for reason codes of interest - dependent on
> policy
>    - Clarified text to state that revocation may be done directly by
> the
> authority that issued the certs, indirectly by an authorized entity,
> or not
> at all. Also clarified that CRLs are one mechanism but others are
> possible
> (however they are outside the scope of 509)
> (You'll find most of these changes reflected in the crlScope extension
> and
> its description, revised description of deltaCRLIndicator extension,
> new
> clause 12.6.4, revised annex M and new annex O) 
>    
> 3. The syntax for privilegePolicy will not be standardized. Rather
> privilegepolicy can be identified by an OID. The syntax from the PDAM
> and
> corresponding SPIF syntax will both be included in an information
> annex
> (Annex N) as examples only.
> 
> 4. New certificate extensions defined (some of these are for privilege
> management others are related to public-key certs in the 'traditional'
> sense):
> - delegator attribute identifier
> - CRL stream identifier
> - indirect issuer
> - user notice
> - SOA identifier
> - base update time
> - acceptable cert policies
> 
> 5. New object class defined:
> -  CP CPS
> 
> 6. New attributes defined:
> - attribute descriptor certificate
> - certification practice statement
> - certificate policy
> 
> 7. New matching rules defined:
> - owner issuer match
> - authority ID match
> - indirect issuer match
> - delegator attribute id match
> - owner attribute id match
> - basic att constraints match
> - attribute name constraints match
> - time spec match
> - attribute descriptor match
> - acceptable cert policies match
> - SOA id match
> 
> 8. Assigned an oid to the special value "any policy" to be used in
> certs
> issued from one CA to another CA.
> 
> 9. Raised an issue regarding duplicate names and how to handle this
> problem
> (mapping internal to external names raised in the issue to help
> generate
> input)
> 
> 10. Attribute certificate syntax - for v2 attribute certs owner and
> issuer
> changed from CHOICE to SEQUENCE and constructs moved from inline to
> separate
> constructs. Although in most cases a claimant will present both their
> attribute cert and their public key cert that authenticates them, for
> those
> cases where both are not provided, this change allows an attribute
> cert to
> point to a public-key cert but also include general names that could
> help a
> verifier find the public key cert in a repository.
> 
> 11. Delegation path validation text re-written to accommodate new
> extensions
> and provide a more comprehensive description of the role the
> extensions play
> in the path validation.
> 
> ---------------------------------------------------------
> Defect reports - for ALL of these, resolutions have been agreed
> (either at
> previous meetings or at this one) and will be documented as DTCs for
> ballot
> shortly, or have already completed and are formally approved: (DR ##
> is the
> Defect Report number, TC means completed ballot and formally approved,
> DTC
> means approved for ballot). I'm only listing those against the 97
> edition
> 
> DR 169  permutable property for PKCS  DTC 2
> DR 183  public key usage                    TC 1
> DR 184  certification path                     Rejected - no change
> DR 185  forward & reverse certificates   DTC 4 
> DR 200  crl dp & full crls                      DTC 3
> DR 201  issuing dist pt                        DTC 3
> DR 204  crl and expired revoked cert    DTC 5
> DR 207  algorithm object class            DTC 6
> DR 212  crl matching rules                  DTC 3
> DR 213  crl matching rules                  DTC 3
> DR 214  use of term 'canonical'            DTC 6
> DR 216  certificate assertion                Rejected - no change
> DR 218  certificate policy match           DTC 3
> DR 219  absence of basic constraints   DTC 3
> DR 220  crl version number                   DTC 3
> DR 222  policy mapping                       DTC 7
> 
> On DR 219 and 220, I know these are of particular interest to PKIX. I
> haven't written 
> the formal documents yet, but to summarize:
> 
> DR 219 - the resolution agreed for ballot is that for a version 3
> certificate, if the certificate does not contain a basicConstraints
> extension, the certificate is to be considered an end-entity
> certificate. We
> decided that the goal can be achieved with this resolution and that we
> won't
> unnecessarily force the 'fattening' of ALL v3 certs by mandating the
> extension always be present (we see that as the role of profiles).
> 
> DR 220 - In the list of notes following the ASN.1 in clause 11.2, note
> 3
> will be modified so that rather than mandating that the version
> component
> "shall" be absent if a CRL contains no critical extensions, the
> version
> component "may" be absent....
> 
> Apologies for the length of this message, but I hope the information
> is
> helpful to people who did not attend the 509 meeting when reviewing
> its
> output. Also, I've most certainly forgotten some other technical
> changes
> that were made so if something isn't listed here it isn't that I don't
> think
> it was important, but that the memory is fading........
> 
> Sharon
>  
> 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26396 for ietf-pkix-bks; Sun, 2 May 1999 17:24:25 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26390 for <[e-mail]>; Sun, 2 May 1999 17:24:08 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <K1RBH1Q8>; Mon, 3 May 1999 10:25:39 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC0BE9AF@DSG1>
From: Alan Lloyd <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Blake Greenlee'" <[e-mail]>
Subject: RE: Summary from April X.509 meeting 
Date: Mon, 3 May 1999 10:25:38 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon - thanks for that - its very useful.

One area that may have been covered in the items below - but could you
confirm. 
We can apply Application type policies to certificate management -
therefore creating a logical, policy based environment for issueance,
validation and usage. However, a CRL does not seem to have anyway of
relating it to a  certificate policy - therefore one cannot include a
policy based revocation environment. ie. only process the CRLs that
relate to the issueance and usage certificate policy.

509 1997 - 12.2.2 - Only permits the cert extension Auth Key Id to be
used in CRLs and the other existing CRL exts are not policy related.

Is this a requirement or has been covered below ?

regards and thanks alan

> -----Original Message-----
> From:	Sharon Boeyen 
> Sent:	Saturday, May 01, 1999 2:42 AM
> To:	'[e-mail]'; '[e-mail]'; 'Blake Greenlee'
> Subject:	Summary from April X.509 meeting 
> 
> As you know, the meeting that resolved ballot comments on the PDAM to
> X.509
> was held a couple of weeks ago. I'm still making the final revisions
> to the
> text, based on meeting participant feedback to my drafts. The final
> text
> that will be sent out for FPDAM (Final Proposed Draft Amendment) will
> be
> available mid - late next week. In an effort to improve the flow of
> communication between the X.509 group and other groups interested in
> that
> work, I'm sending this as an INFORMAL summary of some of the changes
> to the
> PDAM resulting from that meeting. Because the document is still under
> review
> by attendees it is possible that the end result may differ slightly
> from the
> way I've recorded here, but I think these are fairly representative
> (editorial and other minor changes excluded).
> 
> Also, at the end I'll provide a summary of the defect reports
> currently
> against X.509. I'm hoping to have the formal defect reports and the
> formal
> Draft Technical Corrigenda (DTC) for all of these also available
> within a
> week. You will notice that some of these defect reports are very old
> and
> resolutions were agreed two years ago. However, some have not yet been
> formally balloted as DTCs yet. 
> 
> ISO ballots on the FPDAM and on all DTCs for outstanding defect
> reports are
> expected to be conducted over the summer months and resolution of
> those
> ballots is expected to occur in October. 
> 
> When the documents have been completed and are available on a server,
> I'll
> post a notice indicating where they can be found. 
> 
> ------------------------------------------------------
> FPDAM major changes:
> 1. X.509 will be re-titled "Public-Key and Attribute Certificate
> Frameworks". It will be re-structured into 4 major sections: i)
> General
> Introduction ii) Public-key certificate framework iii) Attribute
> certificate
> framework iv) Directory use of public-key and attribute certificate
> frameworks. Annex B will be deleted. 
> 
> 2. CRLs - Clarified a number of issues relevant to 97 delta CRLs:
>     - cert placed on hold and subsequently released (both on deltas) -
> nothing need be carried forward to new base
>     - cert revoked on delta and expires prior to issuance of new base
> -
> revocation gets carried forward to new base
>     - base crl pointed to be delta crl must be complete for given
> scope (ie
> can be a full and complete CRL, distribution pt CRL etc)
>    New enhancements in the area of delta CRLs
>     - can issue delta CRLs for a base that was not published as a CRL
> complete for scope  ('virtual' complete for scope CRL would be locally
> constructed from published CRLs)
>     - can identify base crl by its update time and/or crl number
>     - new 'stream identifier' extension to enable unique
> identification of a
> CRL among all CRLs issued by a particular issuer
>    General CRL handling 
>     - Annex M updated to align with new agreements and new extensions
> including:
>          - if basicConstraints extension is absent in a v3 cert it is
> an
> end-entity cert (previously was type unknown)
>          - no special case situation for ca or key compromise reason
> codes -
> relying party checks crls for reason codes of interest - dependent on
> policy
>    - Clarified text to state that revocation may be done directly by
> the
> authority that issued the certs, indirectly by an authorized entity,
> or not
> at all. Also clarified that CRLs are one mechanism but others are
> possible
> (however they are outside the scope of 509)
> (You'll find most of these changes reflected in the crlScope extension
> and
> its description, revised description of deltaCRLIndicator extension,
> new
> clause 12.6.4, revised annex M and new annex O) 
>    
> 3. The syntax for privilegePolicy will not be standardized. Rather
> privilegepolicy can be identified by an OID. The syntax from the PDAM
> and
> corresponding SPIF syntax will both be included in an information
> annex
> (Annex N) as examples only.
> 
> 4. New certificate extensions defined (some of these are for privilege
> management others are related to public-key certs in the 'traditional'
> sense):
> - delegator attribute identifier
> - CRL stream identifier
> - indirect issuer
> - user notice
> - SOA identifier
> - base update time
> - acceptable cert policies
> 
> 5. New object class defined:
> -  CP CPS
> 
> 6. New attributes defined:
> - attribute descriptor certificate
> - certification practice statement
> - certificate policy
> 
> 7. New matching rules defined:
> - owner issuer match
> - authority ID match
> - indirect issuer match
> - delegator attribute id match
> - owner attribute id match
> - basic att constraints match
> - attribute name constraints match
> - time spec match
> - attribute descriptor match
> - acceptable cert policies match
> - SOA id match
> 
> 8. Assigned an oid to the special value "any policy" to be used in
> certs
> issued from one CA to another CA.
> 
> 9. Raised an issue regarding duplicate names and how to handle this
> problem
> (mapping internal to external names raised in the issue to help
> generate
> input)
> 
> 10. Attribute certificate syntax - for v2 attribute certs owner and
> issuer
> changed from CHOICE to SEQUENCE and constructs moved from inline to
> separate
> constructs. Although in most cases a claimant will present both their
> attribute cert and their public key cert that authenticates them, for
> those
> cases where both are not provided, this change allows an attribute
> cert to
> point to a public-key cert but also include general names that could
> help a
> verifier find the public key cert in a repository.
> 
> 11. Delegation path validation text re-written to accommodate new
> extensions
> and provide a more comprehensive description of the role the
> extensions play
> in the path validation.
> 
> ---------------------------------------------------------
> Defect reports - for ALL of these, resolutions have been agreed
> (either at
> previous meetings or at this one) and will be documented as DTCs for
> ballot
> shortly, or have already completed and are formally approved: (DR ##
> is the
> Defect Report number, TC means completed ballot and formally approved,
> DTC
> means approved for ballot). I'm only listing those against the 97
> edition
> 
> DR 169  permutable property for PKCS  DTC 2
> DR 183  public key usage                    TC 1
> DR 184  certification path                     Rejected - no change
> DR 185  forward & reverse certificates   DTC 4 
> DR 200  crl dp & full crls                      DTC 3
> DR 201  issuing dist pt                        DTC 3
> DR 204  crl and expired revoked cert    DTC 5
> DR 207  algorithm object class            DTC 6
> DR 212  crl matching rules                  DTC 3
> DR 213  crl matching rules                  DTC 3
> DR 214  use of term 'canonical'            DTC 6
> DR 216  certificate assertion                Rejected - no change
> DR 218  certificate policy match           DTC 3
> DR 219  absence of basic constraints   DTC 3
> DR 220  crl version number                   DTC 3
> DR 222  policy mapping                       DTC 7
> 
> On DR 219 and 220, I know these are of particular interest to PKIX. I
> haven't written 
> the formal documents yet, but to summarize:
> 
> DR 219 - the resolution agreed for ballot is that for a version 3
> certificate, if the certificate does not contain a basicConstraints
> extension, the certificate is to be considered an end-entity
> certificate. We
> decided that the goal can be achieved with this resolution and that we
> won't
> unnecessarily force the 'fattening' of ALL v3 certs by mandating the
> extension always be present (we see that as the role of profiles).
> 
> DR 220 - In the list of notes following the ASN.1 in clause 11.2, note
> 3
> will be modified so that rather than mandating that the version
> component
> "shall" be absent if a CRL contains no critical extensions, the
> version
> component "may" be absent....
> 
> Apologies for the length of this message, but I hope the information
> is
> helpful to people who did not attend the 509 meeting when reviewing
> its
> output. Also, I've most certainly forgotten some other technical
> changes
> that were made so if something isn't listed here it isn't that I don't
> think
> it was important, but that the memory is fading........
> 
> Sharon
>  
> 
>