Re: Comment on AttributeCertificate draft

[[e-mail]]

Andres,

Sorry for the late answer. See below:

Regards,
Ron.

>Ron
>
><snip>
>>X.509 certificates can be used as SPKI certificates and therefore there is no
limit.
>>However, the typical application of PKI was for a long time thought to be
where
>>a user has a (i.e. single) PKC, as you call it. This PKC is posted in a
>>directory with a name to certificate mapping and the certificate contained no
>>authorizations. Granted, this is just a typical application.
>
>A single PKC is IMO a very good thing for the user.  I only have one
credit-card
>and it allows me to pay in 99% of all credit-card-enabled shops.  Why would I
get "the other brand" as well?
>Would be a waste of wallet-space.
>

What I mean is that a single certificate will normally not be enough; that's why
 you came up with ACs.
In general, even more than one PKC might be required, for example: (i) CA1 of
organization 1 is not trusted in organization 2, and (ii) organization 2 needs a
different DN to be on that certificate for it to be useful.
While there can be a solution to both problems, (ii) cannot be solved in a
globally - scalable fashion (see SPKI theory).

>To post the certificate in a public directory is on the other hand a bad thing
due
>to privacy reasons.  An unnesseary as well unless it is posted together with
other
>subject data which would be even more privacy-depriving.  Individual RP's
>may though put certificates in directories occassionaly.

Exactly what SPKI theory notes!

>>Its also clear that this type of communication needs to be secure on the
network
>>layer as well as the application layer. IP traffic will need to be authorized
>>first to go through. After that the application layer, say an XML parser,
would
>>decide whether the specifically requested operation is authorized to the
>>key-holder since IP layer cannot necessarily make this decision.
>>What was suggested below means that the communication on the IP level is not
>secured, as this is what I understand.
>
>I don't follow this.  SSL-level security with server (receiver)-authentication
should be
>enough for transmitting signed XML-documents.  This is at least what is used
>commercially today.

SSL uses certificates. For proper security, both sides use certificates.
However, for additional granularity in security, XML may embed additional
certificates for operation-level authorization. These certificates must be
issued crossing organizational boundaries.
Also, a general purpose approach would allow secure transport of peers behind
firewalls e.g. through IPSec security gateways, with an IPSec tunnel. This means
that both the application(s) and the gateway(s) may require several different
certificates to achieve high granularity in security.

>>Another example is where QoS guarantees need to be made on RSVPed  traffic
>>flowing from a user connected to an ISP to an organization. Also consider a
>>small regional office of an organization with a broadband connection to a
local
>>ISP. How about extranet access? It could be a video conference, IP telephony.
>>Would you imagine not being able to speak on the phone with anyone outside
your
>>organization? SPKI claims that doing this "conservatively" would not be
>>scalable.
>
>Question: Is this in conflict with organization-signed XML-documents over SSL?

I assume that they use today the same certificate for SSL and XML authentication
 (if any).

The conflict is in the scalability and the possible non-reachable nature of a an
Attribute Authority outside its organization: it would be typically behind the
firewall, even if it was reachable, it would not be able to handle outsiders
because it does not know anything about the DN in their Certificates. A solution
might be for the organization to issue PKCs to these welcomed outsiders. In any
case, ACLs can grow humongous and DNs as global identifiers would be
meaningless, i.e. not scalable.

>>Authorizations cross organizational boundaries, as traffic does. That's the
>>nature of the internet. So, I do not think it would be rare.
>>Let us avoid the pitfalls outlined in SPKI theory and come up with something
>>which can scale globally
>
>Which XML-documents (containing authorizations, credentials) signed by
organizations
>should be able to do.

Yes, with only the scalability issue above. Also consider non XML traffic.

>The thing that make PKI not scale is the totally obsolete idea saying that you
must have an unbroken
>"PKI-connection" from an individual belonging to one organization
authenticating to another organization.
>
>That idea made SET (Safe Electronic Transaction) kill itself under its own
weight.   VISA has fortunately
>abandoned SET 1.0 in favour of a solution that deviates from classic PKI that
will (soon) prove that PKI
>scales well if not implemented exactly as it is written in the book (X500).
>
>PKI-approaches like VISA's make ACs (and SPKI) less likely to succeed.
Particularly
>when augmented with XML schemas.  The latter BTW makes ASN.1 look like
stone-age.

I did not follow (not familiar with SET).
I note that SPKI is PKI and that soon or later the global identification issue
(currently using DNs) and other scalability issues will surface; let us get
ready today, let us learn from the work of others.





Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13892 for <[e-mail]>; Wed, 27 Sep 2000 19:17:13 -0700 (PDT)
From: [e-mail]
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e8S2JFL13325; Wed, 27 Sep 2000 19:19:15 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e8S2Jbu01011; Wed, 27 Sep 2000 19:19:37 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256968.000CF892 ; Wed, 27 Sep 2000 19:21:40 -0700
X-Lotus-FromDomain: 3COM
To: "Anders Rundgren" <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 27 Sep 2000 19:19:30 -0700
Subject: Re: Comment on AttributeCertificate draft
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Andres,

Sorry for the late answer. See below:

Regards,
Ron.

>Ron
>
><snip>
>>X.509 certificates can be used as SPKI certificates and therefore there is no
limit.
>>However, the typical application of PKI was for a long time thought to be
where
>>a user has a (i.e. single) PKC, as you call it. This PKC is posted in a
>>directory with a name to certificate mapping and the certificate contained no
>>authorizations. Granted, this is just a typical application.
>
>A single PKC is IMO a very good thing for the user.  I only have one
credit-card
>and it allows me to pay in 99% of all credit-card-enabled shops.  Why would I
get "the other brand" as well?
>Would be a waste of wallet-space.
>

What I mean is that a single certificate will normally not be enough; that's why
 you came up with ACs.
In general, even more than one PKC might be required, for example: (i) CA1 of
organization 1 is not trusted in organization 2, and (ii) organization 2 needs a
different DN to be on that certificate for it to be useful.
While there can be a solution to both problems, (ii) cannot be solved in a
globally - scalable fashion (see SPKI theory).

>To post the certificate in a public directory is on the other hand a bad thing
due
>to privacy reasons.  An unnesseary as well unless it is posted together with
other
>subject data which would be even more privacy-depriving.  Individual RP's
>may though put certificates in directories occassionaly.

Exactly what SPKI theory notes!

>>Its also clear that this type of communication needs to be secure on the
network
>>layer as well as the application layer. IP traffic will need to be authorized
>>first to go through. After that the application layer, say an XML parser,
would
>>decide whether the specifically requested operation is authorized to the
>>key-holder since IP layer cannot necessarily make this decision.
>>What was suggested below means that the communication on the IP level is not
>secured, as this is what I understand.
>
>I don't follow this.  SSL-level security with server (receiver)-authentication
should be
>enough for transmitting signed XML-documents.  This is at least what is used
>commercially today.

SSL uses certificates. For proper security, both sides use certificates.
However, for additional granularity in security, XML may embed additional
certificates for operation-level authorization. These certificates must be
issued crossing organizational boundaries.
Also, a general purpose approach would allow secure transport of peers behind
firewalls e.g. through IPSec security gateways, with an IPSec tunnel. This means
that both the application(s) and the gateway(s) may require several different
certificates to achieve high granularity in security.

>>Another example is where QoS guarantees need to be made on RSVPed  traffic
>>flowing from a user connected to an ISP to an organization. Also consider a
>>small regional office of an organization with a broadband connection to a
local
>>ISP. How about extranet access? It could be a video conference, IP telephony.
>>Would you imagine not being able to speak on the phone with anyone outside
your
>>organization? SPKI claims that doing this "conservatively" would not be
>>scalable.
>
>Question: Is this in conflict with organization-signed XML-documents over SSL?

I assume that they use today the same certificate for SSL and XML authentication
 (if any).

The conflict is in the scalability and the possible non-reachable nature of a an
Attribute Authority outside its organization: it would be typically behind the
firewall, even if it was reachable, it would not be able to handle outsiders
because it does not know anything about the DN in their Certificates. A solution
might be for the organization to issue PKCs to these welcomed outsiders. In any
case, ACLs can grow humongous and DNs as global identifiers would be
meaningless, i.e. not scalable.

>>Authorizations cross organizational boundaries, as traffic does. That's the
>>nature of the internet. So, I do not think it would be rare.
>>Let us avoid the pitfalls outlined in SPKI theory and come up with something
>>which can scale globally
>
>Which XML-documents (containing authorizations, credentials) signed by
organizations
>should be able to do.

Yes, with only the scalability issue above. Also consider non XML traffic.

>The thing that make PKI not scale is the totally obsolete idea saying that you
must have an unbroken
>"PKI-connection" from an individual belonging to one organization
authenticating to another organization.
>
>That idea made SET (Safe Electronic Transaction) kill itself under its own
weight.   VISA has fortunately
>abandoned SET 1.0 in favour of a solution that deviates from classic PKI that
will (soon) prove that PKI
>scales well if not implemented exactly as it is written in the book (X500).
>
>PKI-approaches like VISA's make ACs (and SPKI) less likely to succeed.
Particularly
>when augmented with XML schemas.  The latter BTW makes ASN.1 look like
stone-age.

I did not follow (not familiar with SET).
I note that SPKI is PKI and that soon or later the global identification issue
(currently using DNs) and other scalability issues will surface; let us get
ready today, let us learn from the work of others.




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08440 for <[e-mail]>; Wed, 27 Sep 2000 14:39:14 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 27 Sep 2000 14:42:32 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 27 Sep 2000 14:42:31 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <TYA3K3DB>; Wed, 27 Sep 2000 14:41:14 -0700
Content-return: allowed
Date: Wed, 27 Sep 2000 14:41:14 -0700
From: Peter Williams <[e-mail]>
Subject: RE: 2459 disapproved by MSFT and VeriSign?
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/signed;	protocol="application/x-pkcs7-signature"; micalg=SHA1;	boundary="----=_NextPart_000_0000_01C02891.7D280E80"

This is a multi-part message in MIME format.

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



Anders,
 
http://www.microsoft.com/WINDOWS2000/guide/server/solutions/EIM.asp
for some forward thinking to dwell on. It bridges the early
Netscape-vision
of https and PKIX, and goes beyond PKIX author's apparently
somewhat limited  infrastructure vision to make PKI useful for 
relationship-oriented security.

Peter.




>Steve, now this deviation between a (rather late) standard-2-be and 
>its likely implementation is very close to be happening
>once again (right in front of thousands of PKIX-list users):
>
>The s.c. "Permanent Identifiers" that is in draft format is IMO a 
>real candidate for similar deficiencies and ambiguities due
>to this rather rigid view of what a DN is and must be.  How come?
>
>1.  Permanent Identifiers have been in active use for quite some 
>time (5y+).  There are even commercially available products from
>TTPs like VeriSign/eccellerate (organization certificates with DUNS 
>numbers) and from the Swedish Post Office (ID-certificates
>with citizen registration numbers).  And AFAIK these products use 
>the subject DN as the place to put the PI info
>(The use of Subject Alt Name except *maybe* for e-mail is still 
>considered "exotic" and its value is not fully understood).

<edit out>

>2. The PI-draft will give a new "home" for these permanent 
>identifiers.  Problem solved? Well, not really.
>Due to the already existing use of PIs in DNs, and an increasing use 
>of mapping software, the "old" scheme will (MUST)
>continue to live FOREVER.  I.e. the new "standardized" PI home will 
>contain duplicate (=REDUNDANT) information.
>
>Solution: IMO The PI-draft should have specified a non-critical 
>extension that points out what components of
>a DN that constitutes the PI.  I.e. a DN "filter" formula that the 
>RP may understand or not.  Such that a CA can
>introduce it at any time without breaking any code or changing 
>existing (by a minority perceived as bad) habits.

Thanks for your opinion.  I'll leave it to Denis to address details 
of your comments during last call.

Steve

------=_NextPart_000_0000_01C02891.7D280E80
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE4TCCBN0w
ggSHoAMCAQICCmFGnFQAAAAABDAwDQYJKoZIhvcNAQEFBQAwgZsxIDAeBgkqhkiG9w0BCQEWEXdp
bGRpZEB3aWxkaWQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEPMA0GA1UE
BxMGVmVuaWNlMQ8wDQYDVQQKEwZXaWxkSUQxIjAgBgNVBAsTGVRvdGFsbHkgRnJlZSBEaWdpdGFs
IEkuRC4xDzANBgNVBAMTBldpbGRJRDAeFw0wMDA4MzAwMTQ4MzZaFw0wMDA5MjkwMTU4MzZaMGAx
IjAgBgkqhkiG9w0BCQEWE3BldGVyd0B2YWxpY2VydC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTEQMA4GA1UEBxMHRnJlbW9udDEOMAwGA1UEAxMFUGV0ZXIwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAMW8EUTQVXAVF9IVzKUUd8qetmKkvqT9/Dxnp1E0lIvdogzbS4Jh8bvROju4C6gG
Ep/pBHHX+2i7JoDhisXTXXy0PEqW3yg0hQyEOQiOlAFqs+DAOizlR9RVOWsNgMtWAOLUVlt69ZGi
2aUWMpqpKCwZo/zIpnofu5CQPujOBvXRAgMBAAGjggKhMIICnTAOBgNVHQ8BAf8EBAMCBPAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR0Yezt69JX/BHQFUJcfE8nuFvm
xTCB1wYDVR0jBIHPMIHMgBQVLSR/WI70zcWFy2Vw0MyXTdFFP6GBoaSBnjCBmzEgMB4GCSqGSIb3
DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVl
IERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEghBYYc07qTXLu0dEUcR2pp/pMIGRBgNVHR8E
gYkwgYYwQKA+oDyGOmh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5y
b2xsL1dpbGRJRC5jcmwwQqBAoD6GPGZpbGU6Ly9cXGRhbDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4u
Y29tXENlcnRFbnJvbGxcV2lsZElELmNybDCB3gYIKwYBBQUHAQEEgdEwgc4wZAYIKwYBBQUHMAKG
WGh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5yb2xsL2RhbDAwMjA4
MDN3MDAxLmRhdGFyZXR1cm4uY29tX1dpbGRJRC5jcnQwZgYIKwYBBQUHMAKGWmZpbGU6Ly9cXGRh
bDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4uY29tXENlcnRFbnJvbGxcZGFsMDAyMDgwM3cwMDEuZGF0
YXJldHVybi5jb21fV2lsZElELmNydDANBgkqhkiG9w0BAQUFAANBAAtW+yr27kv/q5QxjuQgPtJ7
r/8S5HnBAma0qADwKk3As4Z6xi7Kj4ajN3nqr/sZnNHL2g5nxsyue2Oslzy5+04xggKuMIICqgIB
ATCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMw
EQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAG
A1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEAgphRpxUAAAA
AAQwMAkGBSsOAwIaBQCgggFZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDkyNzIxNDQ1MFowIwYJKoZIhvcNAQkEMRYEFE+ri6hMe4j5Bz52i79JE5vYF7b1MDwG
CSqGSIb3DQEJDzEvMC0wBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcN
AgUwgbsGCSsGAQQBgjcQBDGBrTCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5j
b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzAN
BgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UE
AxMGV2lsZElEAgphRpxUAAAAAAQwMA0GCSqGSIb3DQEBAQUABIGAVJHwviaaJrAmarfT5aBquvLC
B4OkHhtCYWsqgrHZTLyxEE2zRG6y1eZHSGfXgSP8+070WYCMuXe4b632HJahF0ngOfy3l404+0Pq
SkFiQYimL26ZdHxU/y8nN0fKg6TEVdSzMLXe2CdTO6iSQBxxZhr4jbQlXAUbZsDjlXP1u/wAAAAA
AAA=

------=_NextPart_000_0000_01C02891.7D280E80--



Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05399 for <[e-mail]>; Wed, 27 Sep 2000 12:54:34 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA96302; Wed, 27 Sep 2000 15:57:37 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id PAA87100; Wed, 27 Sep 2000 15:57:55 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256967.006DA5A7 ; Wed, 27 Sep 2000 15:57:38 -0400
X-Lotus-FromDomain: IBMUS
To: Nada Kapidzic Cicovic <[e-mail]>
cc: "Bob Jueneman" <[e-mail]>, [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 27 Sep 2000 15:57:38 -0400
Subject: Re: Certificates by e-mail address in directory schemas
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     It is possible to populate the MAIL (actually rfc822Mailbox) attribute
with the contents of the SubjectAltName's rfc822Name, of course, and that
would be a possibility as the standard technique.  However, I still have a
few questions:
1 -  Unless PKIX standardizes a publication location, how could an RP
decide between the use of this directory attribute and PKCS#9's
emailAddress attribute?
2 -  How does an RP find out which directory (not which entry within a
directory) supports a given set of e-mail addresses?  Searches of the
global directory for values of an attribute which doesn't form part of the
name seem likely to be impractical.

          Tom Gindin


Nada Kapidzic Cicovic <[e-mail]> on 09/27/2000
04:14:52 AM

To:   Tom Gindin/Watson/IBM@IBMUS, "Bob Jueneman" <[e-mail]>
cc:   [e-mail], [e-mail]
Subject:  Re: Certificates by e-mail address in directory schemas



At 07:45 PM 9/25/00 -0400, [e-mail] wrote:
>      Since PKIX suggests that e-mail addresses be placed in the
>SubjectAltName extension, and much relying party software would find
>looking certificates up by e-mail address highly useful, what publication
>technique is endorsed which would allow relying party software to find
>certificates in a directory using the e-mail address as the primary input
>to their "find heuristic"?  Irrespective of where in the certificate the
>e-mail address should go, relying parties are interested in where in the
>directory they can find the certificate.  This does not imply that there
is
>anything wrong with having S/MIME, TLS, or CMS send the originator's
>certificate (IMO that is perfectly reasonable), but that many applications
>want to discover a potential recipient's e-mail certificate without having
>to rely on a previous message sent by that user.
>      I am not sure whether it should be part of the PKIX LDAP schema work
>to define where in the directory CA's who wish to publish a certificate
>under its e-mail address should put it, or whether that work belongs in
the
>S/MIME WG, but shouldn't the location be defined within one of those
>efforts?


A way (the way ?) for doing this is for the CA to populate MAIL attribute
of the EE directory entry with the e-mail address from the subjectAltName
at the same time when it populates userCertificate attribute with the
certificate. In this way users have the possibility to search the directory
tree based on the e-mail addresses, while the naming and directory schema
is not destroyed by having e-mail as one of the RDNs.

Regards,
Nada


>      BTW, In view of some of the reasons why e-mail addresses are
>deprecated within DN's, I am fairly sure that the MPEG of your cat would
be
>better placed in SubjectDirectoryAttributes.
>
>           Tom Gindin
>
>P.S. These opinions are mine personally, and not necessarily those of my
>employer.
>

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technical Director

Entegrity Solutions AB

phone:  + 46 (0)8 477 77 37
cell:   + 46 (0)70 495 09 03
fax:    + 46 (0)8 477 77 31

Finlandsgatan 60, SE-164 74 Kista, Sweden




Received: from dtctxexch10.ins.com ([208.164.93.45]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00609 for <[e-mail]>; Wed, 27 Sep 2000 09:00:21 -0700 (PDT)
From: [e-mail]
Received: from C991473C (C991473-C [208.164.89.231]) by dtctxexch10.ins.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TNQFVYW8; Wed, 27 Sep 2000 11:03:26 -0500
Message-ID: <004a01c0289c$51502530$e759a4d0@C991473C>
Reply-To: <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Wed, 27 Sep 2000 11:02:14 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C02872.64C52B80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C02872.64C52B80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

unsubscribe

------=_NextPart_000_0040_01C02872.64C52B80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>unsubscribe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0040_01C02872.64C52B80--



Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25157 for <[e-mail]>; Wed, 27 Sep 2000 07:58:20 -0700 (PDT)
Received: from [171.78.60.78] (dc078.bbn.com [171.78.60.78]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA27539; Wed, 27 Sep 2000 11:01:39 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220802b5f7553564e9@[171.78.60.86]>
In-Reply-To: <003e01c026db$f5f23b40$[e-mail]>
References: <003e01c026db$f5f23b40$[e-mail]>
Date: Wed, 27 Sep 2000 11:01:57 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

>Steve,
>
><snip>
>
>  >Anyway, the reality is that VS and other CAs put e-mail addresses 
>into DNs when there were no other standard places to put them, 
>and >Netscape and MS, also eager to support such identifiers in 
>their products (S/MIME in browsers) coordinated their products to 
>make it all >work. That was understandable when there were no other 
>choices, but we have moved on. I think 2459 does a reasonable job of 
>explaining >the situation and stating why the preferred approach, 
>going forward, is to make use of the designated alt subject name 
>type to represent this >information. if one did not take a strong 
>position on this issue, where would be the motivation to change?
>
>I.e. you think it is reasonable to insist on changing an existing 
>already widely used scheme for reasons that are not that obvious for
>most users (including some PKI-professionals as well)?

It is not the goal of the WG to endorse implementation decisions 
that, though understandable at the time, were not even consistent 
with the original base standard (X.509), and which are not consistent 
with current X.509 (v3) standards.

>Steve, now this deviation between a (rather late) standard-2-be and 
>its likely implementation is very close to be happening
>once again (right in front of thousands of PKIX-list users):
>
>The s.c. "Permanent Identifiers" that is in draft format is IMO a 
>real candidate for similar deficiencies and ambiguities due
>to this rather rigid view of what a DN is and must be.  How come?
>
>1.  Permanent Identifiers have been in active use for quite some 
>time (5y+).  There are even commercially available products from
>TTPs like VeriSign/eccellerate (organization certificates with DUNS 
>numbers) and from the Swedish Post Office (ID-certificates
>with citizen registration numbers).  And AFAIK these products use 
>the subject DN as the place to put the PI info
>(The use of Subject Alt Name except *maybe* for e-mail is still 
>considered "exotic" and its value is not fully understood).

We have a fundamental disagreement about the purpose of this WG, 
which I alluded to above. I don't think I can make it any clearer.

>2. The PI-draft will give a new "home" for these permanent 
>identifiers.  Problem solved? Well, not really.
>Due to the already existing use of PIs in DNs, and an increasing use 
>of mapping software, the "old" scheme will (MUST)
>continue to live FOREVER.  I.e. the new "standardized" PI home will 
>contain duplicate (=REDUNDANT) information.
>
>Solution: IMO The PI-draft should have specified a non-critical 
>extension that points out what components of
>a DN that constitutes the PI.  I.e. a DN "filter" formula that the 
>RP may understand or not.  Such that a CA can
>introduce it at any time without breaking any code or changing 
>existing (by a minority perceived as bad) habits.

Thanks for your opinion.  I'll leave it to Denis to address details 
of your comments during last call.

Steve



Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14888 for <[e-mail]>; Wed, 27 Sep 2000 01:12:28 -0700 (PDT)
Received: from cooper.entegrity.com (dave.cost.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RQJ8K8TQ; Wed, 27 Sep 2000 01:09:36 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 27 Sep 2000 10:14:52 +0200
To: [e-mail], "Bob Jueneman" <[e-mail]>
From: Nada Kapidzic Cicovic <[e-mail]>
Subject: Re: Certificates by e-mail address in directory schemas
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 07:45 PM 9/25/00 -0400, [e-mail] wrote:
>      Since PKIX suggests that e-mail addresses be placed in the
>SubjectAltName extension, and much relying party software would find
>looking certificates up by e-mail address highly useful, what publication
>technique is endorsed which would allow relying party software to find
>certificates in a directory using the e-mail address as the primary input
>to their "find heuristic"?  Irrespective of where in the certificate the
>e-mail address should go, relying parties are interested in where in the
>directory they can find the certificate.  This does not imply that there is
>anything wrong with having S/MIME, TLS, or CMS send the originator's
>certificate (IMO that is perfectly reasonable), but that many applications
>want to discover a potential recipient's e-mail certificate without having
>to rely on a previous message sent by that user.
>      I am not sure whether it should be part of the PKIX LDAP schema work
>to define where in the directory CA's who wish to publish a certificate
>under its e-mail address should put it, or whether that work belongs in the
>S/MIME WG, but shouldn't the location be defined within one of those
>efforts?


A way (the way ?) for doing this is for the CA to populate MAIL attribute 
of the EE directory entry with the e-mail address from the subjectAltName 
at the same time when it populates userCertificate attribute with the 
certificate. In this way users have the possibility to search the directory 
tree based on the e-mail addresses, while the naming and directory schema 
is not destroyed by having e-mail as one of the RDNs.

Regards,
Nada


>      BTW, In view of some of the reasons why e-mail addresses are
>deprecated within DN's, I am fairly sure that the MPEG of your cat would be
>better placed in SubjectDirectoryAttributes.
>
>           Tom Gindin
>
>P.S. These opinions are mine personally, and not necessarily those of my
>employer.
>

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technical Director

Entegrity Solutions AB

phone:  + 46 (0)8 477 77 37
cell:   + 46 (0)70 495 09 03
fax:    + 46 (0)8 477 77 31

Finlandsgatan 60, SE-164 74 Kista, Sweden



Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04145 for <[e-mail]>; Tue, 26 Sep 2000 17:29:27 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA232146; Tue, 26 Sep 2000 20:32:26 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id UAA35900; Tue, 26 Sep 2000 20:32:44 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256967.0002FACB ; Tue, 26 Sep 2000 20:32:32 -0400
X-Lotus-FromDomain: IBMUS
To: "Bob Jueneman" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 26 Sep 2000 20:25:54 -0400
Subject: Re: Certificates by e-mail address in directory schemas
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA04146

     Responses below.  However, IMHO letting RP software know where the
certificate for a given e-mail address would be published if the subject
and/or CA chose to make it searchable by e-mail address would be a very
useful thing.  Is there any standard location which I have missed?
     Neither the CA nor the subject are under any obligation to make
certificates searchable in that way, of course.  That is why I didn't
address "whether", but merely "where" a certificate should be indexed.

          Tom Gindin


"Bob Jueneman" <[e-mail]> on 09/26/2000 12:40:07 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <[e-mail]>
Subject:  Re: Certificates by e-mail address in directory schemas




Good questions, Tom. And in response I promise not to include  an MPEG of
my cat in the DN of the certificate, OR in the subjectAltName,  although
I'm still considering whether it deserves to be enshrined in
subjectDirectoryAttributes. I'll have to ask the cat -- after all, pets
have  privacy rights too, don't they? :-)

More seriously, the issue of how,  and whether, to look up a certificate
deserves a lot of thought.

I  have you listed in my address book as "Tom Gindin," and if I had your
certificate I would probably look it up that way. But if you weren't in my
personal address book or frequent contact list, would I really want to
automatically look up your certificate by e-mail address, prior to sending
you  an encrypted message? Would I even know who you were well enough to
send you a  sensitive message in the first place?

[Tom] If you were responding to an unencrypted message, you might.  In any
case, you do have my e-mail address and I don't think you know the OU in my
DN.  For people with more common names than mine, that could matter.

One of the risks here is that  I somehow mistype a name, and automatically
I get the wrong certificate, as well  as the wrong addressee. I'm sure that
we've all heard of the executive who sent  her lover an e-mail telling him
exactly and explicitly what she was going to do  to him the next time they
got together. Unfortunately, when she typed the first part of his name, the
auto-complete function filled in the rest, and without  looking she
accidentally sent it off to an "all hands" list instead of the  intended.
Embarrassing, to say the very least.

The only thing worse  would have been to send off such a message in
encrypted form to the wrong person  or list. (Well, I guess that digitally
signing it would have been even worse --  without her signature she could
perhaps claim that someone was forging mail from  her account to embarrass
her.)

[Tom] Actually, looking up a certificate for an all-hands list probably
would have produced a warning (no certificate for this entry) and she would
have avoided a lot of embarrassment.

So although I would very much like to get  out of the practice of always
sending my entire certificate chain to the same  person over and over
again, just because I signed the message, I not so sure  that I want to
automatically look up someone's certificate in a directory prior  to
sending them an encrypted message, because I'm not sure that have a
suitably  established basis for TRUST.

[Tom] I'm a little confused here.  I didn't think that sending an encrypted
e-mail demonstrated trust in the recipient of the message, in comparison to
sending him a clear e-mail.  It's more like demonstrating distrust in the
system administrator of his ISP.  It does imply some trust in the
recipient's CA.

An exception would be the case for a  legitimate all-hands encrypted
message, using the S/MIME v3 ESS capability for  sending an encrypted
message to a secure mail list server, and having that  server look up the
certificates of everyone on that list and send them an  encrypted copy. But
I think that is a special case.

Note that I am not  arguing about the desirability of looking up a
certificate in a directory. I  just want to be a little careful how I use
that capability.

[Tom] The two e-mail clients I know best require you to manually select
encryption for any message you wish to encrypt.  If you have a client like
that and you're sending to a set of named individuals, a user who chooses
encryption presumably wants the recipients' certificates acquired.

Bob

Robert R. Jueneman
Security Architect
Novell -- the leading supplier of Net services software.


>>>< [e-mail] > 09/25/00  05:45PM >>>
Since PKIX suggests that e-mail addresses be placed in  the
SubjectAltName extension, and much relying party software would find
looking certificates up by e-mail address highly useful, what publication
technique is endorsed which would allow relying party software to find
certificates in a directory using the e-mail address as the primary input
to their "find heuristic"? Irrespective of where in the certificate the
e-mail address should go, relying parties are interested in where in the
directory they can find the certificate. This does not imply that there is
anything wrong with having S/MIME, TLS, or CMS send the originator's
certificate (IMO that is perfectly reasonable), but that many applications
want to discover a potential recipient's e-mail certificate without having
to rely on a previous message sent by that user.
I am not sure whether  it should be part of the PKIX LDAP schema work
to define where in the  directory CA's who wish to publish a certificate
under its e-mail address  should put it, or whether that work belongs in
the
S/MIME WG, but shouldn't  the location be defined within one of those
efforts?
BTW, In view of  some of the reasons why e-mail addresses are
deprecated within DN's, I am  fairly sure that the MPEG of your cat would
be
better placed in  SubjectDirectoryAttributes.

Tom Gindin

P.S. These opinions are  mine personally, and not necessarily those of my
employer.





Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00725 for <[e-mail]>; Tue, 26 Sep 2000 14:15:50 -0700 (PDT)
Received: from [171.78.60.86] (dc086.bbn.com [171.78.60.86]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id RAA02457; Tue, 26 Sep 2000 17:09:37 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b5f6bff3938b@[171.78.60.86]>
In-Reply-To: <011a01c02733$2582fa50$020aff0c@tsg1>
References: <A681CAA9AC8BD4119F0300B0D03D205F05D86F@MAIL> <v0422080db5eed6f03d27@[128.33.238.22]> <011a01c02733$2582fa50$020aff0c@tsg1>
Date: Tue, 26 Sep 2000 17:07:19 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Correction - Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

The suggestion that the ACTS document become a standards track, 
historical RFC seems at odds with the criteria we apply to such 
documents. For ACTS to become standards track, NIST would have to 
formally cede control to the IETF.  Also, since ACTS is not 
Internet-specific, one could question whether it belongs as an IETF 
standard at all.  I suggest you review the criteria associated with 
different categories of RFCs before proposing this change, which will 
surely be challenged.

Steve


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA23760 for <[e-mail]>; Tue, 26 Sep 2000 09:37:40 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 26 Sep 2000 10:40:13 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 26 Sep 2000 10:40:07 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Certificates by e-mail address in directory schemas
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_2D75C97D.36573217"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_2D75C97D.36573217
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Good questions, Tom. And in response I promise not to include an MPEG of =
my cat in the DN of the certificate, OR in the subjectAltName, although =
I'm still considering whether it deserves to be enshrined in subjectDirecto=
ryAttributes. I'll have to ask the cat -- after all, pets have privacy =
rights too, don't they? :-)=20

More seriously, the issue of how, and whether, to look up a certificate =
deserves a lot of thought.=20

I have you listed in my address book as "Tom Gindin," and if I had your =
certificate I would probably look it up that way. But if you weren't in my =
personal address book or frequent contact list, would I really want to =
automatically look up your certificate by e-mail address, prior to sending =
you an encrypted message? Would I even know who you were well enough to =
send you a sensitive message in the first place?=20

One of the risks here is that I somehow mistype a name, and automatically =
I get the wrong certificate, as well as the wrong addressee. I'm sure that =
we've all heard of the executive who sent her lover an e-mail telling him =
exactly and explicitly what she was going to do to him the next time they =
got together. Unfortunately, when she typed the first part of his name, =
the auto-complete function filled=20
in the rest, and without looking she accidentally sent it off to an "all =
hands" list instead of the intended. Embarrassing, to say the very =
least.=20

The only thing worse would have been to send off such a message in =
encrypted form to the wrong person or list. (Well, I guess that digitally =
signing it would have been even worse -- without her signature she could =
perhaps claim that someone was forging mail from her account to embarrass =
her.)=20

So although I would very much like to get out of the practice of always =
sending my entire certificate chain to the same person over and over =
again, just because I signed the message, I not so sure that I want to =
automatically look up someone's certificate in a directory prior to =
sending them an encrypted message, because I'm not sure that have a =
suitably established basis for TRUST.=20

An exception would be the case for a legitimate all-hands encrypted =
message, using the S/MIME v3 ESS capability for sending an encrypted =
message to a secure mail list server, and having that server look up the =
certificates of everyone on that list and send them an encrypted copy. But =
I think that is a special case.=20

Note that I am not arguing about the desirability of looking up a =
certificate in a directory. I just want to be a little careful how I use =
that capability.=20

Bob=20

Robert R. Jueneman=20
Security Architect=20
Novell -- the leading supplier of Net services software.=20


>>>< [e-mail] > 09/25/00 05:45PM >>>=20
Since PKIX suggests that e-mail addresses be placed in the=20
SubjectAltName extension, and much relying party software would find=20
looking certificates up by e-mail address highly useful, what publication=
=20
technique is endorsed which would allow relying party software to find=20
certificates in a directory using the e-mail address as the primary =
input=20
to their "find heuristic"? Irrespective of where in the certificate the=20
e-mail address should go, relying parties are interested in where in =
the=20
directory they can find the certificate. This does not imply that there =
is=20
anything wrong with having S/MIME, TLS, or CMS send the originator's=20
certificate (IMO that is perfectly reasonable), but that many applications=
=20
want to discover a potential recipient's e-mail certificate without =
having=20
to rely on a previous message sent by that user.=20
I am not sure whether it should be part of the PKIX LDAP schema work=20
to define where in the directory CA's who wish to publish a certificate=20
under its e-mail address should put it, or whether that work belongs in =
the=20
S/MIME WG, but shouldn't the location be defined within one of those=20
efforts?=20
BTW, In view of some of the reasons why e-mail addresses are=20
deprecated within DN's, I am fairly sure that the MPEG of your cat would =
be=20
better placed in SubjectDirectoryAttributes.=20

Tom Gindin=20

P.S. These opinions are mine personally, and not necessarily those of =
my=20
employer.=20

--=_2D75C97D.36573217
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 8pt MS Sans Serif; MARGIN-LEFT: =
2px">
<DIV><FONT size=3D2>Good questions, Tom. And in response I promise not to =
include=20
an MPEG of my cat in the DN of the certificate, OR in the subjectAltName,=
=20
although I'm still considering whether it deserves to be enshrined in=20
subjectDirectoryAttributes. I'll have to ask the cat -- after all, pets =
have=20
privacy rights too, don't they? :-) <BR><BR>More seriously, the issue of =
how,=20
and whether,&nbsp;to look up a certificate deserves a lot of thought. =
<BR><BR>I=20
have you listed in my address book as "Tom Gindin," and if I had your=20
certificate I would probably look it up that way. But if you weren't in =
my=20
personal address book or frequent contact list, would I really want to=20
automatically look up your certificate by e-mail address, prior to sending =
you=20
an encrypted message? Would I even know who you were well enough to send =
you a=20
sensitive message in the first place? <BR><BR>One of the risks here&nbsp;is=
 that=20
I somehow mistype a name, and automatically I get the wrong certificate, =
as well=20
as the wrong addressee. I'm sure that we've all heard of the executive who =
sent=20
her lover an e-mail telling him exactly and explicitly what she was going =
to do=20
to him the next time they got together. Unfortunately, when she typed the =
first=20
part of his name, the auto-complete function filled <BR>in the rest, and =
without=20
looking she accidentally sent it off to an "all hands" list instead of =
the=20
intended. Embarrassing, to say the very least. <BR><BR>The only thing =
worse=20
would have been to send off such a message in encrypted form to the wrong =
person=20
or list. (Well, I guess that digitally signing it would have been even =
worse --=20
without her signature she could perhaps claim that someone was forging =
mail from=20
her account to embarrass her.) <BR><BR>So although I would very much like =
to get=20
out of the practice of always sending my entire certificate chain to the =
same=20
person over and over again, just because I signed the message, I not so =
sure=20
that I want to automatically look up someone's certificate in a directory =
prior=20
to sending them an encrypted message, because I'm not sure that have a =
suitably=20
established basis for TRUST. <BR><BR>An exception would be the case for =
a=20
legitimate all-hands encrypted message, using the S/MIME v3 ESS capability =
for=20
sending an encrypted message to a secure mail list server, and having =
that=20
server look up the certificates of everyone on that list and send them =
an=20
encrypted copy. But I think that is a special case. <BR><BR>Note that I am =
not=20
arguing about the desirability of looking up a certificate in a directory. =
I=20
just want to be a little careful how I use that capability. <BR><BR>Bob=20
<BR><BR>Robert R. Jueneman <BR>Security Architect <BR><FONT=20
color=3D#ff0000><STRONG>Novell</STRONG> </FONT>-- the leading supplier of =
<FONT=20
color=3D#ff0000><STRONG>N</STRONG></FONT>et services software.</FONT>=20
<BR><BR><BR>&gt;&gt;&gt;&lt;<U> <A=20
href=3D"mailto:[e-mail]">[e-mail]</A></U> &gt; =
09/25/00=20
05:45PM &gt;&gt;&gt; <BR>Since PKIX suggests that e-mail addresses be =
placed in=20
the <BR>SubjectAltName extension, and much relying party software would =
find=20
<BR>looking certificates up by e-mail address highly useful, what =
publication=20
<BR>technique is endorsed which would allow relying party software to =
find=20
<BR>certificates in a directory using the e-mail address as the primary =
input=20
<BR>to their "find heuristic"? Irrespective of where in the certificate =
the=20
<BR>e-mail address should go, relying parties are interested in where in =
the=20
<BR>directory they can find the certificate. This does not imply that =
there is=20
<BR>anything wrong with having S/MIME, TLS, or CMS send the originator's=20=

<BR>certificate (IMO that is perfectly reasonable), but that many =
applications=20
<BR>want to discover a potential recipient's e-mail certificate without =
having=20
<BR>to rely on a previous message sent by that user. <BR>I am not sure =
whether=20
it should be part of the PKIX LDAP schema work <BR>to define where in =
the=20
directory CA's who wish to publish a certificate <BR>under its e-mail =
address=20
should put it, or whether that work belongs in the <BR>S/MIME WG, but =
shouldn't=20
the location be defined within one of those <BR>efforts? <BR>BTW, In view =
of=20
some of the reasons why e-mail addresses are <BR>deprecated within DN's, I =
am=20
fairly sure that the MPEG of your cat would be <BR>better placed in=20
SubjectDirectoryAttributes. <BR><BR>Tom Gindin <BR><BR>P.S. These opinions =
are=20
mine personally, and not necessarily those of my <BR>employer.=20
<BR><BR></DIV></BODY></HTML>

--=_2D75C97D.36573217--


Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23486 for <[e-mail]>; Tue, 26 Sep 2000 09:31:13 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA26983 for <[e-mail]>; Tue, 26 Sep 2000 12:17:19 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 26 Sep 2000 12:28:22 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Correction - Re: Fw: The need for two grades of time data.
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: daR+LQTxAJ83KultEJ2R9Q==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

There would seem to be a conflict between "standards track" and
"historical".  Widely-used protocols that are not the product of an
IETF working group (S/MIME v2, PKCS #1,5,7,10) are generally documented as
Informational RFCs.  (I could have sworn there was an Informational RFC
for SSL v3, but I can't find it now.)  Standards Track RFCs are used
for specifications under development by a working group (TLS, S/MIME
v3).

Is the ACTS specification going to become a PKIX work item?  What role
will any IETF working group have in standardizing ACTS, given the
description "This document then, is filed for historical purposes on
the already widely used, publicly available ACTS time service
protocol." ?





> From: "todd glassey" <[e-mail]>
> 
> Hi all - some minor corrections to the ACTS information.
> 
> The intent of refiling ACTS to get it into the Standards Track so that it
> will proceed automatically to standard status for historical purposes. To
> accomplish this the draft was re-filed in full conformance with the RFC2026
> ss 10, and was done so on the STANDARDS TRACK, not the Informational one.
> I initially resubmitted the original draft and the updated one has the
> correct email
> and telephone contact info as well. The updated draft was sent to the
> Draft's
> submission email address and is now in the mill so to speak.
> 
> Todd Glassey



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27408 for <[e-mail]>; Mon, 25 Sep 2000 16:55:57 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA112380; Mon, 25 Sep 2000 19:58:47 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id TAA60964; Mon, 25 Sep 2000 19:59:04 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256965.0083BD4E ; Mon, 25 Sep 2000 19:58:56 -0400
X-Lotus-FromDomain: IBMUS
To: "Bob Jueneman" <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 25 Sep 2000 19:45:04 -0400
Subject: Certificates by e-mail address in directory schemas
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA27409

     Since PKIX suggests that e-mail addresses be placed in the
SubjectAltName extension, and much relying party software would find
looking certificates up by e-mail address highly useful, what publication
technique is endorsed which would allow relying party software to find
certificates in a directory using the e-mail address as the primary input
to their "find heuristic"?  Irrespective of where in the certificate the
e-mail address should go, relying parties are interested in where in the
directory they can find the certificate.  This does not imply that there is
anything wrong with having S/MIME, TLS, or CMS send the originator's
certificate (IMO that is perfectly reasonable), but that many applications
want to discover a potential recipient's e-mail certificate without having
to rely on a previous message sent by that user.
     I am not sure whether it should be part of the PKIX LDAP schema work
to define where in the directory CA's who wish to publish a certificate
under its e-mail address should put it, or whether that work belongs in the
S/MIME WG, but shouldn't the location be defined within one of those
efforts?
     BTW, In view of some of the reasons why e-mail addresses are
deprecated within DN's, I am fairly sure that the MPEG of your cat would be
better placed in SubjectDirectoryAttributes.

          Tom Gindin

P.S. These opinions are mine personally, and not necessarily those of my
employer.


"Bob Jueneman" <[e-mail]> on 09/22/2000 11:38:34 AM

To:   <[e-mail]>
cc:   <[e-mail]>
Subject:  Certificate vs. directory DN schemas




Anders,

As someone who was once rather infamous for suggesting that I  could
include an MPEG movie of me playing with my cat in the  DN of my
certificate and still be in conformance with  X.509, I feel your pain.

(I would point out that such a bizarre usage would be a  syntactically and
semantically valid RDN, as opposed to  stuffing an RFC822 name into a
commonName, or inscribing  liability statements in OUs.  That sort of
egregious  mistyping of RDN components should have disappeared with X.509
version 1.)

I think we can easily agree that matching the directory and  certificate DN
schemas is pretty easy for a CA -- if they  don't like the proposed DN,
they won't issue the  certificate.

But I'm more interested in your thoughts about the role that  the directory
plays for the relying party.

At present, of course, virtually all of the protocol standards  are at best
agnostic and at worst verging on hostile to the  notion of a directory, and
so SSL and S/MIME implementations  insist on wasting bandwidth and in some
cases storage, sending the same certificates down the line over and over
again, instead  of looking them up as required.  (The inappropriate use  of
real-time validation protocols such as OCSP instead of  cacheable CRLs make
this problem even worse, but that is a  different discussion.)

But you said:

>In IIS (MS Webserver), you can apply "rules"
>to DN  interpretation which of course is due to the fact that there seldom
is
>a  clean 1-1 match between a DN and OS user, customer etc. etc.
>By using  such mechanisms an RP can BTW handle a lot of certificates
>and CAs  WITHOUT having all DN components in directories.  Just the
"important"  ones.
>(For encryption purposes you have to store the entire certificate  blob
though)

I'd be quite interested to learn what kinds of applications or  servers are
in fact starting to handle such certificates,  and to use directories to
store them in, as well as any  emerging trends you might be seeing.

Are these certificates being used for authentication and  access control,
primarily, or is something closer to true  digital
signatures/nonrepudiation involved?  Likewise, you mentioned encryption --
are you seeing applications other than  standard e-mail packages making use
of encryption for end users?

Where do you think this is going, and when is it going to have  a
noticeable impact on commerce and/or the use of  directories?

Moreover, are you (or anyone else) seeing this across the  board, or is it
more common in certain countries than  others, or with certain servers,
platforms, or  applications?

Regards,

Bob

Robert R. Jueneman
Security Architect

Novell -- the  leading provider of Net services  software.

>>> "Anders Rundgren"  <[e-mail]> 09/21/00 05:03PM >>>
Phil et  al.

> We are all agreed upon
>what the architecture SHOULD look  like. The question is simply one of
>how we migrate towards that  architecture.


Regarding this architecture that we all should migrate  to:

There is AFAIK no standard set of attributes that CAs always  support
which IMO means that DN components is a deployment issue and
are  usually profiled for specific uses.  Due to this lack of  conformance
each certificate class/type needs its own directory  structure.
This assuming that the DN is a multi-valued pointer into a  directory tree
which is definitely not always true.  In IIS (MS  Webserver), you can apply
"rules"
to DN interpretation which of course is due  to the fact that there seldom
is
a clean 1-1 match between a DN and OS user,  customer etc. etc.
By using such mecanisms an RP can BTW handle a lot of  certificates
and CAs WITHOUT having all DN components in directories.   Just the
"important" ones.
(For encryption purposes you have to store the  entire certificate blob
though)

Such solutions were maybe not what the  X509 designers had in mind but this
is where we are.  And it actually  works!

Permanent Identifiers (today usually extracted from DNs and in the  future
implemented through the
coming PI draft) ease this process even more.  And of course diminish the
connection between
a certificate DN and a matching  (X500) directory entry even further.
X509.v3 certificates are  maybe
slowly (but surely) moving away from their original architectural  home?

That CAs usually store certificates in directories exactly matching  their
issued certificates
is natural and easy to do compared to the situation  for RPs that usually
outnumber their CAs by
several orders of magnitude.

<snip>

>My VeriSign Certificate has the email address  encoded in SubjectAltName
>and not in the DN. So we certainly have the  ability to support 2459.
>The 'problem' seems to be that we also support  other profiles if
>the customer selects them.


If the custumer  orders a VeriSign class #1 certificate or uses the MS
CertSrv
(that does not  support the 2459 e-mail solution except by forcing the
customer
to write  their own policy module), you really don't have this option.

Note: I  don't complain about neither VeriSign or MSFT.  It is just an
observation  which
I tried to map on 2459 with limited success.

Regards
Anders





Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26300 for <[e-mail]>; Mon, 25 Sep 2000 16:03:29 -0700 (PDT)
Received: from tsg1 ([12.72.64.37]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000925230613.MGNE14966.mtiwmhc27.worldnet.att.net@tsg1>; Mon, 25 Sep 2000 23:06:13 +0000
Message-ID: <012401c02745$2e813420$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: "IETF-PXIX" <[e-mail]>
References: <[e-mail]>
Subject: Re: (Re-sent) Response to the comments raised by Russ Housley 
Date: Mon, 25 Sep 2000 15:58:01 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Denis

>
> 2. Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says
> that the client SHOULD make the check, but that the client MAY elect to
> skip the check.  The checking requirement is either a SHOULD or a MAY, it
> cannot be both.
>
> RESOLUTION: The second sentence which contains the MAY has been deleted
> (i.e. "The client MAY ignore this field if that is acceptable for the
> intended application".)

Actually doesn't it seem to you that there are a number of sentences that
should be looked at under the same conceptual rule, and perhaps changed to
one that says something like "Provides optional or user selectable
functionality"

Again a AD would help tremendously for anyone's end-use model or method.

>
> 3. Section 2.4.1, reqPolicy Discussion.  I do not think that a reference
to
> RFC 2459 is adequate.

It may not be. Depends on what the use mdels for the TSP Services are.

> First, I do not believe that a certification policy
> and a TSA policy are equivalent.

I disagree. They are almost idenitcal, but the TSA's is more complex.  How
could they not be? If the TSA does not insure what it does, then its
worthless in the commercial environment. So, as a basic operating model the
TSA needs a CPS for its internal trust services as well as its external TPS
and RPA documents.

> At a minimum, the TSA Policy and TSA
> Practice Statement will have significantly different content.

A TSA is a trust service agent that says something digitally happened with a
PKI authenticated or other identity. The Certificate Authority is a
inedemnity provider service agency that identifies individuals and entities.
The TSA is exactly this and provides insurance around what time the event
occured.

The TPS or Timing Practices Statement is actually a superset of the CPS
since it has to also address the same issues as the CA as well as the audit
trail and certification of its timebase and time management processes.  I
can testify to this 'first hand' having participated  in the creation of
CertifiedTime's SLA and its TPS (Timing Practices Statement) & RPA's
(Relying Party Agrements ).


Todd



Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23842 for <[e-mail]>; Mon, 25 Sep 2000 13:54:23 -0700 (PDT)
Received: from tsg1 ([12.72.64.37]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000925205707.KIBA14966.mtiwmhc27.worldnet.att.net@tsg1>; Mon, 25 Sep 2000 20:57:07 +0000
Message-ID: <011a01c02733$2582fa50$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Mathew  Butler" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <A681CAA9AC8BD4119F0300B0D03D205F05D86F@MAIL> <v0422080db5eed6f03d27@[128.33.238.22]>
Subject: Correction - Re: Fw: The need for two grades of time data.
Date: Mon, 25 Sep 2000 13:54:15 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Hi all - some minor corrections to the ACTS information.

The intent of refiling ACTS to get it into the Standards Track so that it
will proceed automatically to standard status for historical purposes. To
accomplish this the draft was re-filed in full conformance with the RFC2026
ss 10, and was done so on the STANDARDS TRACK, not the Informational one.
I initially resubmitted the original draft and the updated one has the
correct email
and telephone contact info as well. The updated draft was sent to the
Draft's
submission email address and is now in the mill so to speak.

Todd Glassey





Received: from mtiwmhc27.worldnet.att.net (mtiwmhc27.worldnet.att.net [204.127.131.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22794 for <[e-mail]>; Mon, 25 Sep 2000 13:00:28 -0700 (PDT)
Received: from tsg1 ([12.72.64.37]) by mtiwmhc27.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000925200311.JMMC14966.mtiwmhc27.worldnet.att.net@tsg1>; Mon, 25 Sep 2000 20:03:11 +0000
Message-ID: <00fe01c0272b$9ce69cd0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Mathew  Butler" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <A681CAA9AC8BD4119F0300B0D03D205F05D86F@MAIL> <v0422080db5eed6f03d27@[128.33.238.22]>
Subject: Re: Fw: The need for two grades of time data.
Date: Mon, 25 Sep 2000 12:17:07 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Hi all - some minor corrections to the ACTS information.

The intent of refiling ACTS to get it into the Standards Track so that it
will proceed automatically to standard status for historical purposes. To
accomplish this the draft was re-filed in full conformance with the RFC2026
ss 10, and was done so on the STANDARDS TRACK, not the Informational one.

The ACTS protocol is in the public domain and so the standards track is the
right place for it and should proceed onward unless there are some unknown
IP rights not yet disclosed to us, but as far as I know its is free and
clear.

I have spoken with NIST and others about this and all are inline with this
creation of the "ACTS Standard" since there are now only a few million ACTS
clients distributed about the world.

Todd Glassey

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "Mathew Butler" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 20, 2000 2:06 PM
Subject: RE: Fw: The need for two grades of time data.


> Mat,
>
> >Small problem here: Is PKIX not a customer of NTP, for its time
information?
>
> Not necessarily.  A TSA could use WWV (in the U.S.) or GPS, ACTS
> (which Todd described in a recent, Informational RFC), or some other,
> non-Internet means of acquiring time.
>
> Steve
>
>



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01187 for <[e-mail]>; Mon, 25 Sep 2000 02:31:31 -0700 (PDT)
Received: from mega (t4o69p16.telia.com [62.20.145.136]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id LAA06653; Mon, 25 Sep 2000 11:33:59 +0200 (CEST)
Message-ID: <003e01c026db$f5f23b40$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
Cc: "Philip Hallam-Baker" <[e-mail]>, <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Date: Mon, 25 Sep 2000 12:32:49 +0200
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 ns.secondary.com id CAA01189

Steve,

<snip>

>Anyway, the reality is that VS and other CAs put e-mail addresses into DNs when there were no other standard places to put them, and >Netscape and MS, also eager to support such identifiers in their products (S/MIME in browsers) coordinated their products to make it all >work. That was understandable when there were no other choices, but we have moved on. I think 2459 does a reasonable job of explaining >the situation and stating why the preferred approach, going forward, is to make use of the designated alt subject name type to represent this >information. if one did not take a strong position on this issue, where would be the motivation to change?

I.e. you think it is reasonable to insist on changing an existing already widely used scheme for reasons that are not that obvious for
most users (including some PKI-professionals as well)?

Steve, now this deviation between a (rather late) standard-2-be and its likely implementation is very close to be happening
once again (right in front of thousands of PKIX-list users):

The s.c. "Permanent Identifiers" that is in draft format is IMO a real candidate for similar deficiencies and ambiguities due
to this rather rigid view of what a DN is and must be.  How come?

1.  Permanent Identifiers have been in active use for quite some time (5y+).  There are even commercially available products from
TTPs like VeriSign/eccellerate (organization certificates with DUNS numbers) and from the Swedish Post Office (ID-certificates
with citizen registration numbers).  And AFAIK these products use the subject DN as the place to put the PI info
(The use of Subject Alt Name except *maybe* for e-mail is still considered "exotic" and its value is not fully understood).

2. The PI-draft will give a new "home" for these permanent identifiers.  Problem solved? Well, not really.
Due to the already existing use of PIs in DNs, and an increasing use of mapping software, the "old" scheme will (MUST)
continue to live FOREVER.  I.e. the new "standardized" PI home will contain duplicate (=REDUNDANT) information.

Solution: IMO The PI-draft should have specified a non-critical extension that points out what components of
a DN that constitutes the PI.  I.e. a DN "filter" formula that the RP may understand or not.  Such that a CA can
introduce it at any time without breaking any code or changing existing (by a minority perceived as bad) habits. 

Anders




Received: from mail.nanospace.com ([e-mail] [209.213.199.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA07392 for <[e-mail]>; Sun, 24 Sep 2000 08:17:29 -0700 (PDT)
Received: (qmail 22803 invoked by uid 74); 24 Sep 2000 15:20:27 -0000
Received: from [e-mail] by mail with scan4virus-0.19 (Clean. Processed in 3.171209 secs); 24/09/2000 08:20:23
Received: from ppp-209-213-195-41.nanospace.com (HELO nanospace.com) (209.213.195.41) by mail.nanospace.com with SMTP; 24 Sep 2000 15:20:23 -0000
Message-ID: <[e-mail]>
Date: Sun, 24 Sep 2000 08:19:11 -0700
From: J Johnen <[e-mail]>
X-Mailer: Mozilla 4.04 [en] (Win95; U)
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

unsubscribe



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16154 for <[e-mail]>; Fri, 22 Sep 2000 14:06:10 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA26915; Fri, 22 Sep 2000 17:08:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080eb5f175f6670d@[171.78.30.107]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Fri, 22 Sep 2000 17:01:40 -0400
To: Philip Hallam-Baker <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: 2459 disapproved by MSFT and VeriSign?
Cc: Philip Hallam-Baker 	 <[e-mail]>, [e-mail]
Content-Type: multipart/alternative; boundary="============_-1242465447==_ma============"

--============_-1242465447==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Phil,

>  > Phil,
>  >
>  > We obviously differ in our views of what constitutes the right way to
>  > make tradeoffs wrt Internet standards.  My bias comes from serving on
>  > the IAB for over a decade, and from having been involved in the
>  > development of Internet protocols for over 20 years.  I'm comfortable
>  > with that basis for making the tradeoff. Jon Postel's oft quoted
>  > phrase is a good one, and I discussed the implications of it in
>  > security contexts on many occasions.  We didn't always agree :-), but
>  > Jon was certainly a big supporter of architectural purity.
>  >
>  > Steve
>
>I don't think we have such a wide disagreement. We are all agreed upon
>what the architecture SHOULD look like. The question is simply one of
>how we migrate towards that architecture.
>
>Suggestions that VeriSign should ONLY issue certificates that don't
>work with X% or of the deployed base for the sake of 'architectural
>purity' are plain silly if X is 50% and more reasonable if X is 0.05%.

>My VeriSign Certificate has the email address encoded in SubjectAltName
>and not in the DN. So we certainly have the ability to support 2459.
>The 'problem' seems to be that we also support other profiles if
>the customer selects them.

PKIX is not telling VeriSign what to do. VeriSign does what it deems 
appropriate, based on market requirements, or on perceived 
requirement created by astute marketing folks :-). (VeriSign is such 
a dominant force in the public PKI space that it has the ability to 
set customer expectations, which blurs the distinction.)  PKIX is 
just saying what constitutes the preferred way to represent certain 
ID forms, and what qualifies as conforming to its standards.

Anyway, the reality is that VS and other CAs put e-mail addresses 
into DNs when there were no other standard places to put them, and 
Netscape and MS, also eager to support such identifiers in their 
products (S/MIME in browsers) coordinated their products to make it 
all work.  That was understandable when there were no other choices, 
but we have moved on.  I think 2459 does a reasonable job of 
explaining the situation and stating why the preferred approach, 
going forward, is to make use of the designated alt subject name type 
to represent this information. if one did not take a strong position 
on this issue, where would be the motivation to change?

>Today every ISP supports IPV4. That is not taken as a statement from
>those ISPs that they do not intend to use IPV6. On the contrary, we
>all know that eventually there will be a migration but before the
>ISPs can move the customers need to be able to buy robust IPV6
>platforms.

True, but IPv4 was and is still an IETF standard; the e-mail address 
representation convention we're debating was not adopted as a 
standard by the IETF and thus is not an ideal analogy.

Steve

--============_-1242465447==_ma============
Content-Type: text/enriched; charset="us-ascii"

Phil,


<excerpt>> Phil,

> 

> We obviously differ in our views of what constitutes the right way to

> make tradeoffs wrt Internet standards.  My bias comes from serving on

> the IAB for over a decade, and from having been involved in the 

> development of Internet protocols for over 20 years.  I'm comfortable

> with that basis for making the tradeoff. Jon Postel's oft quoted 

> phrase is a good one, and I discussed the implications of it in 

> security contexts on many occasions.  We didn't always agree :-), but

> Jon was certainly a big supporter of architectural purity.

> 

> Steve


I don't think we have such a wide disagreement. We are all agreed upon

what the architecture SHOULD look like. The question is simply one of

how we migrate towards that architecture.


Suggestions that VeriSign should ONLY issue certificates that don't 

work with X% or of the deployed base for the sake of 'architectural

purity' are plain silly if X is 50% and more reasonable if X is 0.05%.

</excerpt>

<excerpt>My VeriSign Certificate has the email address encoded in
SubjectAltName

and not in the DN. So we certainly have the ability to support 2459.

The 'problem' seems to be that we also support other profiles if

the customer selects them.

</excerpt>

PKIX is not telling VeriSign what to do. VeriSign does what it deems
appropriate, based on market requirements, or on perceived requirement
created by astute marketing folks :-). (VeriSign is such a dominant
force in the public PKI space that it has the ability to set customer
expectations, which blurs the distinction.)  PKIX is just saying what
constitutes the preferred way to represent certain ID forms, and what
qualifies as conforming to its standards.


Anyway, the reality is that VS and other CAs put e-mail addresses into
DNs when there were no other standard places to put them, and Netscape
and MS, also eager to support such identifiers in their products
(S/MIME in browsers) coordinated their products to make it all work. 
That was understandable when there were no other choices, but we have
moved on.  I think 2459 does a reasonable job of explaining the
situation and stating why the preferred approach, going forward, is to
make use of the designated alt subject name type to represent this
information. if one did not take a strong position on this issue, where
would be the motivation to change?


<excerpt>Today every ISP supports IPV4. That is not taken as a
statement from

those ISPs that they do not intend to use IPV6. On the contrary, we

all know that eventually there will be a migration but before the

ISPs can move the customers need to be able to buy robust IPV6

platforms.

</excerpt>

True, but IPv4 <underline>was</underline> and <underline>is</underline>
still an IETF standard; the e-mail address representation convention
we're debating was not adopted as a standard by the IETF and thus is
not an ideal analogy.


Steve

--============_-1242465447==_ma============--


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15515 for <[e-mail]>; Fri, 22 Sep 2000 13:46:23 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA24852; Fri, 22 Sep 2000 16:49:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080db5f17305b628@[171.78.30.107]>
In-Reply-To: <008b01c02351$97ceced0$020aff0c@tsg1>
References:  <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107 ]><012e01c021a2$3aa00cc0$020aff0c@tsg1><v0422080eb5ec195cd7b0@[171.78.30.1 07]><002201c021cd$09a42ae0$020aff0c@tsg1> <[e-mail]><016401c022c8$8dfc0000$020aff0c@tsg1> <v04220801b5eeb2a2cd6d@[128.33.238.45]> <008b01c02351$97ceced0$020aff0c@tsg1>
Date: Fri, 22 Sep 2000 16:44:10 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>----- Original Message -----
>From: "Stephen Kent" <[e-mail]>
>To: "todd glassey" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Wednesday, September 20, 2000 12:55 PM
>Subject: Re: Fw: The need for two grades of time data.
>
>Come on Steve -
>
>  >
>  > >Read the first sentence of the 2nd paragraph of the WG
>  > >Description on the WG's homepage It's quoted below:
>  > >----
>  > >"The working group is now embarking on additional standards work to
>develop
>  > >protocols that are either integral to PKI management, or that are
>otherwise
>  > >closely related to PKI use."
>  > >----
>  > >Time and its services are clearly members of this set.
>  >
>  > Time is covered under this when it is intrinsic to PKI management or
>  > use, as is the case for a time stamping protocol.  There are many
>  > ways for a  PKI user to acquire time for use in cert processing.
>
>Steve I think you are wrong here. What this is really all about is the
>difference in using time as content and in using "what time it is" as part
>of the control process.

We disagree.

Also, it doesn't help that you continue to employ vague terms and 
phrases in your messages, even though they are not well defined nor 
widely understood in the context where this discourse is taking 
place.  Recent examples include: "proofing and comparison-based 
decision support systems," " digital trust processes," "removing 
human culpability from the process stages internal to the transaction 
processes," and above, "control process."  Your messages are littered 
with these phrases and with the Prominent Use of Upper Case, as 
though such capitalization made the words in question more 
intelligible or identified them as well-known terms.  This does not 
help.

Steve



Received: from web3403.mail.yahoo.com (web3403.mail.yahoo.com [204.71.203.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA12433 for <[e-mail]>; Fri, 22 Sep 2000 10:54:01 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [207.5.63.61] by web3403.mail.yahoo.com; Fri, 22 Sep 2000 13:56:25 EDT
Date: Fri, 22 Sep 2000 13:56:25 -0400 (EDT)
From: Jim Mallen <[e-mail]>
Reply-To: [e-mail]
Subject: unsubscribe
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1037127828-969645385=:8025"

--0-1037127828-969645385=:8025
Content-Type: text/plain; charset=us-ascii

unsubscribe


---------------------------------
Do You Yahoo!?
Get your free @yahoo.ca address at Yahoo! Mail.

--0-1037127828-969645385=:8025
Content-Type: text/html; charset=us-ascii

<STRONG>unsubscribe</STRONG><p><br><hr size=1><b>Do You Yahoo!?</b><br>Get your free @yahoo.ca address at <a href="http://mail.yahoo.ca/">Yahoo! Mail</a>.<br>
--0-1037127828-969645385=:8025--


Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA12100 for <[e-mail]>; Fri, 22 Sep 2000 10:46:49 -0700 (PDT)
Received: (qmail 6436 invoked from network); 22 Sep 2000 17:38:36 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 22 Sep 2000 17:38:36 -0000
Message-ID: <[e-mail]>
Date: Fri, 22 Sep 2000 18:51:12 +0100
From: Miguel Soares <[e-mail]>
Organization: SIBS
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Received: from smtp.scotland.net (plug.sol.co.uk [194.247.64.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11160; Fri, 22 Sep 2000 09:52:43 -0700 (PDT)
Received: from e2h2p31.scotland.net ([148.176.238.32] helo=JOHNVARSYSTEM) by smtp.scotland.net with smtp (Exim 3.14 #10) id 13cW6N-0007Nu-00; Fri, 22 Sep 2000 17:55:07 +0100
From: "John Ross" <[e-mail]>
To: "ietf-pkix@imc. org" <[e-mail]>, "Ietf distribution list" <[e-mail]>
Subject: ETSI documents for open comment
Date: Fri, 22 Sep 2000 17:54:34 +0100
Message-ID: <[e-mail]>
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 IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

Three draft standards which relate to IETF work items in PKIX and S/MIME
have been posted on the ETSI El Sign Web-site for comments. Comments are
requested on these documents by 13th October 2000 to the ETSI El Sign e-mail
list [e-mail].

To register with the EL-SIGN list and download the draft documents see:
http://www.etsi.org/sec/el-sign.htm

The three documents are:

1.  Qualified Certificate Profile: Please put "QC profile" in the front of
the Subject field of all
submissions to the e-mail list on this topic.

2. Time Stamping Profile: Please put "TS profile" in the front of the
Subject field of all submissions
to the e-mail list on this topic.

3. Revised Electronic Signature Formats: Please put "ES Formats" in the
front of the Subject field of all submissions to the e-mail list on this
topic.

Regards

György Endersz, Telia Research AB.  [e-mail]
Denis Pinkas, Bull.                 [e-mail]
Stefan Santesson, AddTrust.	      [e-mail]
John Ross, Security & Standards.    [e-mail]





Received: from qmail.arl.qwestip.net (qmail.qwestip.net [205.171.7.14]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA10464 for <[e-mail]>; Fri, 22 Sep 2000 09:29:14 -0700 (PDT)
Received: (qmail 4782 invoked from network); 22 Sep 2000 16:30:56 -0000
Received: from ns.klerer.net (HELO dell450nt) ([63.146.136.63]) (envelope-sender <[e-mail]>) by mail.qwestisp.net (qmail-ldap-1.03) with SMTP for <[e-mail]>; 22 Sep 2000 16:30:56 -0000
Message-ID: <004301c024b2$b7381b20$[e-mail]>
From: "Robert Klerer" <[e-mail]>
To: <[e-mail]>
References: <001501c02420$1d3b68c0$[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Date: Fri, 22 Sep 2000 12:32:35 -0400
Organization: Crosshair Communications Corporation
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.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Please forgive my input on a debate that some feel is long past closed, but
Anders does bring up an interesting issue that has been annoying me lately.

That is the fact that in many current implementations of pki, we have
mapping mechanisms for names.  If the name in the certificate must be
translated for use by the  Relaying Parties, whether they be human or
software, does that infer some doubt in it veracity of the certificate?

Robert


----- Original Message -----
From: "Anders Rundgren" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>; "'Stephen Kent'"
<[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, September 21, 2000 7:03 PM
Subject: Re: 2459 disapproved by MSFT and VeriSign?


> Phil et al.
>
> > We are all agreed upon
> >what the architecture SHOULD look like. The question is simply one of
> >how we migrate towards that architecture.
>
>
> Regarding this architecture that we all should migrate to:
>
> There is AFAIK no standard set of attributes that CAs always support
> which IMO means that DN components is a deployment issue and
> are usually profiled for specific uses.  Due to this lack of conformance
> each certificate class/type needs its own directory structure.
> This assuming that the DN is a multi-valued pointer into a directory tree
> which is definitely not always true.  In IIS (MS Webserver), you can apply
"rules"
> to DN interpretation which of course is due to the fact that there seldom
is
> a clean 1-1 match between a DN and OS user, customer etc. etc.
> By using such mecanisms an RP can BTW handle a lot of certificates
> and CAs WITHOUT having all DN components in directories.  Just the
"important" ones.
> (For encryption purposes you have to store the entire certificate blob
though)
>
> Such solutions were maybe not what the X509 designers had in mind but this
> is where we are.  And it actually works!
>
> Permanent Identifiers (today usually extracted from DNs and in the future
implemented through the
> coming PI draft) ease this process even more. And of course diminish the
connection between
> a certificate DN and a matching (X500) directory entry even further.
X509.v3 certificates are maybe
> slowly (but surely) moving away from their original architectural home?
>
> That CAs usually store certificates in directories exactly matching their
issued certificates
> is natural and easy to do compared to the situation for RPs that usually
outnumber their CAs by
> several orders of magnitude.
>
> <snip>
>
> >My VeriSign Certificate has the email address encoded in SubjectAltName
> >and not in the DN. So we certainly have the ability to support 2459.
> >The 'problem' seems to be that we also support other profiles if
> >the customer selects them.
>
>
> If the custumer orders a VeriSign class #1 certificate or uses the MS
CertSrv
> (that does not support the 2459 e-mail solution except by forcing the
customer
> to write their own policy module), you really don't have this option.
>
> Note: I don't complain about neither VeriSign or MSFT.  It is just an
observation which
> I tried to map on 2459 with limited success.
>
> Regards
> Anders
>
>




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA09554 for <[e-mail]>; Fri, 22 Sep 2000 08:36:14 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 22 Sep 2000 09:38:35 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 22 Sep 2000 09:38:34 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Certificate vs. directory DN schemas
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_0D55F2EB.CAABC271"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_0D55F2EB.CAABC271
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Anders,

As someone who was once rather infamous for suggesting that I could =
include an MPEG movie of me playing with my cat in the DN of my certificate=
 and still be in conformance with X.509, I feel your pain.

(I would point out that such a bizarre usage would be a syntactically and =
semantically valid RDN, as opposed to stuffing an RFC822 name into a =
commonName, or inscribing liability statements in OUs.  That sort of =
egregious mistyping of RDN components should have disappeared with X.509 =
version 1.)

I think we can easily agree that matching the directory and certificate DN =
schemas is pretty easy for a CA -- if they don't like the proposed DN, =
they won't issue the certificate.

But I'm more interested in your thoughts about the role that the directory =
plays for the relying party.

At present, of course, virtually all of the protocol standards are at best =
agnostic and at worst verging on hostile to the notion of a directory, and =
so SSL and S/MIME implementations insist on wasting bandwidth and in some =
cases storage, sending the same certificates down the line over and over =
again, instead of looking them up as required.  (The inappropriate use of =
real-time validation protocols such as OCSP instead of cacheable CRLs make =
this problem even worse, but that is a different discussion.)

But you said:

>In IIS (MS Webserver), you can apply "rules"
>to DN interpretation which of course is due to the fact that there seldom =
is
>a clean 1-1 match between a DN and OS user, customer etc. etc.
>By using such mechanisms an RP can BTW handle a lot of certificates
>and CAs WITHOUT having all DN components in directories.  Just the =
"important" ones.
>(For encryption purposes you have to store the entire certificate blob =
though)

I'd be quite interested to learn what kinds of applications or servers are =
in fact starting to handle such certificates, and to use directories to =
store them in, as well as any emerging trends you might be seeing.

Are these certificates being used for authentication and access control, =
primarily, or is something closer to true digital signatures/nonrepudiation=
 involved?  Likewise, you mentioned encryption -- are you seeing applicatio=
ns other than standard e-mail packages making use of encryption for end =
users?

Where do you think this is going, and when is it going to have a noticeable=
 impact on commerce and/or the use of directories?

Moreover, are you (or anyone else) seeing this across the board, or is it =
more common in certain countries than others, or with certain servers, =
platforms, or applications?

Regards,

Bob

Robert R. Jueneman
Security Architect

Novell -- the leading provider of Net services software.

>>> "Anders Rundgren" <[e-mail]> 09/21/00 05:03PM >>>
Phil et al.

> We are all agreed upon
>what the architecture SHOULD look like. The question is simply one of
>how we migrate towards that architecture.


Regarding this architecture that we all should migrate to:

There is AFAIK no standard set of attributes that CAs always support
which IMO means that DN components is a deployment issue and
are usually profiled for specific uses.  Due to this lack of conformance
each certificate class/type needs its own directory structure.
This assuming that the DN is a multi-valued pointer into a directory tree
which is definitely not always true.  In IIS (MS Webserver), you can apply =
"rules"
to DN interpretation which of course is due to the fact that there seldom =
is
a clean 1-1 match between a DN and OS user, customer etc. etc.
By using such mecanisms an RP can BTW handle a lot of certificates
and CAs WITHOUT having all DN components in directories.  Just the =
"important" ones.
(For encryption purposes you have to store the entire certificate blob =
though)

Such solutions were maybe not what the X509 designers had in mind but this
is where we are.  And it actually works!

Permanent Identifiers (today usually extracted from DNs and in the future =
implemented through the
coming PI draft) ease this process even more. And of course diminish the =
connection between
a certificate DN and a matching (X500) directory entry even further.  =
X509.v3 certificates are maybe
slowly (but surely) moving away from their original architectural home?

That CAs usually store certificates in directories exactly matching their =
issued certificates
is natural and easy to do compared to the situation for RPs that usually =
outnumber their CAs by
several orders of magnitude.=20

<snip>

>My VeriSign Certificate has the email address encoded in SubjectAltName
>and not in the DN. So we certainly have the ability to support 2459.
>The 'problem' seems to be that we also support other profiles if
>the customer selects them.


If the custumer orders a VeriSign class #1 certificate or uses the MS =
CertSrv
(that does not support the 2459 e-mail solution except by forcing the =
customer
to write their own policy module), you really don't have this option.

Note: I don't complain about neither VeriSign or MSFT.  It is just an =
observation which
I tried to map on 2459 with limited success. =20

Regards
Anders

--=_0D55F2EB.CAABC271
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 8pt MS Sans Serif; MARGIN-LEFT: =
2px">
<DIV><FONT size=3D1></FONT><FONT size=3D2>Anders,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>As someone who was once rather infamous for suggesting =
that I=20
could </FONT><FONT size=3D2>include an MPEG movie of me playing with my =
cat in the=20
DN of&nbsp;my certificate</FONT><FONT size=3D2> and still be in conformance=
 with=20
X.509</FONT><FONT size=3D2>, I feel your pain.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>(I would point out that such a bizarre usage would be =
a=20
syntactically </FONT><FONT size=3D2>and semantically valid RDN, as opposed =
to=20
stuffing an RFC822 name into a </FONT><FONT size=3D2>commonName, or =
inscribing=20
liability statements in OUs.&nbsp; That sort of </FONT><FONT size=3D2>egreg=
ious=20
mistyping of RDN components should have disappeared with </FONT><FONT=20
size=3D2>X.509 version 1.)</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I think we can easily agree that matching the =
directory and=20
certificate DN </FONT><FONT size=3D2>schemas is pretty easy for a CA -- if =
they=20
don't like the proposed DN, </FONT><FONT size=3D2>they won't issue the=20
certificate.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>But I'm more interested in your thoughts about the =
role that=20
the directory plays </FONT><FONT size=3D2>for the relying party.</FONT></DI=
V>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>At present, of course, virtually all of the protocol =
standards=20
are at best agnostic </FONT><FONT size=3D2>and at worst verging on hostile =
to the=20
notion of a directory, and so SSL and </FONT><FONT size=3D2>S/MIME =
implementations=20
insist on wasting bandwidth and in some cases storage, </FONT><FONT=20
size=3D2>sending the same certificates down the line over and over again, =
instead=20
of </FONT><FONT size=3D2>looking them up as required.&nbsp; (The inappropri=
ate use=20
of real-time validation </FONT><FONT size=3D2>protocols such as OCSP =
instead of=20
cacheable CRLs make this problem even </FONT><FONT size=3D2>worse, but =
that is a=20
different discussion.)</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>But you said:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&gt;In IIS (MS Webserver), you can apply "rules"<BR>&gt=
;to DN=20
interpretation which of course is due to the fact that there seldom =
is<BR>&gt;a=20
clean 1-1 match between a DN and OS user, customer etc. etc.<BR>&gt;By =
using=20
such mechanisms an RP can BTW handle a lot of certificates<BR>&gt;and =
CAs=20
WITHOUT having all DN components in directories.&nbsp; Just the "important"=
=20
ones.<BR>&gt;(For encryption purposes you have to store the entire =
certificate=20
blob though)</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I'd be quite interested to learn what kinds of =
applications or=20
servers are in fact </FONT><FONT size=3D2>starting to handle such =
certificates,=20
and to use directories to store them in, as well </FONT><FONT size=3D2>as =
any=20
emerging trends you might be seeing.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Are these certificates being used for authentication =
and=20
access control, primarily, </FONT><FONT size=3D2>or is something closer to =
true=20
digital signatures/nonrepudiation involved?&nbsp; Likewise, </FONT><FONT=20=

size=3D2>you mentioned encryption -- are you seeing applications other =
than=20
standard e-mail packages making use of encryption for end users?</FONT></DI=
V>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Where do you think this is going, and when is it going =
to have=20
a noticeable </FONT><FONT size=3D2>impact on commerce and/or the use of=20
directories?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Moreover, are you (or anyone else) seeing this across =
the=20
board, or is it </FONT><FONT size=3D2>more common in certain countries =
than=20
others, or with certain servers, </FONT><FONT size=3D2>platforms, or=20
applications?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bob</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Robert R. Jueneman</FONT></DIV>
<DIV><FONT size=3D2>Security Architect</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><STRONG><FONT color=3D#ff0000>Novell</FONT></STRONG> =
-- the=20
leading provider of <STRONG><FONT color=3D#ff0000>N</FONT></STRONG>et =
services=20
software.</FONT><BR><BR>&gt;&gt;&gt; "Anders Rundgren"=20
&lt;[e-mail]&gt; 09/21/00 05:03PM &gt;&gt;&gt;<BR>Phil =
et=20
al.<BR><BR>&gt; We are all agreed upon<BR>&gt;what the architecture SHOULD =
look=20
like. The question is simply one of<BR>&gt;how we migrate towards that=20
architecture.<BR><BR><BR>Regarding this architecture that we all should =
migrate=20
to:<BR><BR>There is AFAIK no standard set of attributes that CAs always=20
support<BR>which IMO means that DN components is a deployment issue =
and<BR>are=20
usually profiled for specific uses.&nbsp; Due to this lack of=20
conformance<BR>each certificate class/type needs its own directory=20
structure.<BR>This assuming that the DN is a multi-valued pointer into =
a=20
directory tree<BR>which is definitely not always true.&nbsp; In IIS (MS=20
Webserver), you can apply "rules"<BR>to DN interpretation which of course =
is due=20
to the fact that there seldom is<BR>a clean 1-1 match between a DN and OS =
user,=20
customer etc. etc.<BR>By using such mecanisms an RP can BTW handle a lot =
of=20
certificates<BR>and CAs WITHOUT having all DN components in directories.&nb=
sp;=20
Just the "important" ones.<BR>(For encryption purposes you have to store =
the=20
entire certificate blob though)<BR><BR>Such solutions were maybe not what =
the=20
X509 designers had in mind but this<BR>is where we are.&nbsp; And it =
actually=20
works!<BR><BR>Permanent Identifiers (today usually extracted from DNs and =
in the=20
future implemented through the<BR>coming PI draft) ease this process even =
more.=20
And of course diminish the connection between<BR>a certificate DN and a =
matching=20
(X500) directory entry even further.&nbsp; X509.v3 certificates are=20
maybe<BR>slowly (but surely) moving away from their original architectural=
=20
home?<BR><BR>That CAs usually store certificates in directories exactly =
matching=20
their issued certificates<BR>is natural and easy to do compared to the =
situation=20
for RPs that usually outnumber their CAs by<BR>several orders of magnitude.=
=20
<BR><BR>&lt;snip&gt;<BR><BR>&gt;My VeriSign Certificate has the email =
address=20
encoded in SubjectAltName<BR>&gt;and not in the DN. So we certainly have =
the=20
ability to support 2459.<BR>&gt;The 'problem' seems to be that we also =
support=20
other profiles if<BR>&gt;the customer selects them.<BR><BR><BR>If the =
custumer=20
orders a VeriSign class #1 certificate or uses the MS CertSrv<BR>(that =
does not=20
support the 2459 e-mail solution except by forcing the customer<BR>to =
write=20
their own policy module), you really don't have this option.<BR><BR>Note: =
I=20
don't complain about neither VeriSign or MSFT.&nbsp; It is just an =
observation=20
which<BR>I tried to map on 2459 with limited success.&nbsp;=20
<BR><BR>Regards<BR>Anders<BR><BR></DIV></BODY></HTML>

--=_0D55F2EB.CAABC271--


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04706 for <[e-mail]>; Fri, 22 Sep 2000 07:59:47 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA34072; Fri, 22 Sep 2000 17:07:42 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA40178; Fri, 22 Sep 2000 17:02:10 +0200
Message-ID: <[e-mail]>
Date: Fri, 22 Sep 2000 17:02:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: IETF-PXIX <[e-mail]>
Subject: TSP: (Re-sent) Response to the comments raised by Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is a re-sent because of the number of CR/LF in the previous message.
*************************************************************************

Russ,

Here are proposed resolutions for the 24 comments you sent during
the IESG last call period for the document:
<draft-ietf-pkix-time-stamp-09.txt>

Would you tell us if you are satisfied with these resolutions ?

Denis 

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


Note the comments have been numbered so that it is easier to refer to them.


TECHNICAL

1. Section 2.1, 6th requirement.  I do not understand "hash-function 
OID."  OIDs, when managed correctly, are collision free.  I think we need 
to be discussing the one-way hash function, not its OID.  The selected 
one-way hash function must be uniquely identified by an OID.

RESOLUTION: Changed the text into: 

   to only time stamp a hash representation of the datum, i.e.
   a data imprint associated with a one-way collision resistant 
   hash-function uniquely identified by an OID.

2. Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says 
that the client SHOULD make the check, but that the client MAY elect to 
skip the check.  The checking requirement is either a SHOULD or a MAY, it 
cannot be both.

RESOLUTION: The second sentence which contains the MAY has been deleted 
(i.e. "The client MAY ignore this field if that is acceptable for the 
intended application".)

3. Section 2.4.1, reqPolicy Discussion.  I do not think that a reference to 
RFC 2459 is adequate.  First, I do not believe that a certification policy 
and a TSA policy are equivalent.  At a minimum, the TSA Policy and TSA 
Practice Statement will have significantly different content.  These 
differences need to be discussed.  Second, I would prefer syntax without 
qualifiers.  What value do they add in the TSA context?

RESOLUTION: The current wording is as follows: " The reqPolicy field, 
if included, indicates the policy under which the TimeStampToken 
SHOULD be provided. PolicyInformation is defined in Section 4.2.1.5 
of [RFC2459]."
The second sentence only means that the ASN1 syntax of PolicyInformation 
is defined in this document. It is true that a certification policy and 
a TSA policy are fairly different but it is not intended here to go 
into more details. A separate document on TSA policy would certainly 
be useful. Such a work item is being initiated by ETSI. The results 
will be presented to the IETF when available, so that, if the WG agrees, 
an RFC can be issued. Unless a proposal is made to clarify the wording, 
it is believed that no change is necessary.

4. Section 2.4.1, nonce Discussion.  Please replace "shall" with "MUST."

RESOLUTION: Done.

5. Section 2.4.2, 3rd paragraph.  The text does not match the comments in the 
ASN.1 structure.  I assume that the comments are correct.  Please 
rewrite.  I suggest:
  When status contains the value zero or one, a Time Stamp Token
  MUST be present.  When status contains a value other than zero or
  one, a Time Stamp Token MUST NOT be present.  One of the following
  values MUST be contained in status:"

RESOLUTION: It is a good catch for the missing "or one". The rest is a 
clarification which has been incorporated

6. Section 2.4.2, 11th paragraph (counting paragraphs is difficult since the 
ASN.1 fragments are not indented).   Please replace "shall" with "MUST."

RESOLUTION: Done.

7. Section 2.4.2, serialNumber Discussion.  Please reword the last sentence to 
include a MUST.  I suggest: "This property MUST be preserved even after an 
interruption in service (e.g. crash)."

RESOLUTION: Done.

8. Section 2.4.2, genTime Discussion.  Please replace "shall" with 
"MUST."  There are at least five occurrences.

RESOLUTION: Done.

9. Section 3.1.  How does the MIME type distinguish a time stamp request from 
a time stamp token?  The recipient must either decode a TimeStampReq or a 
ContentInfo, and this does not provide enough information to determine 
which operation to perform.

RESOLUTION: While the direction of flow should indicate which content 
type to expect, it would probably make things easier if there were 
two content types.  Thus, Section 3.1 has been changed to read:

This section specifies a means for conveying ASN.1-encoded messages 
for the protocol exchanges described in Section 2 and Appendix D via 
Internet mail.

Two MIME objects are specified as follows:

   Content-Type: application/timestamp-request
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp request message, base64-encoded>>

   Content-Type: application/timestamp-response
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp response message, base64-encoded>>

These MIME objects can be sent and received using common MIME processing 
engines and provides a simple Internet mail transport for Time Stamp 
messages.

10. Section 3.2.  It would be helpful to specify file extensions for a time 
stamp request and a time stamp token.  Such extensions would permit the 
recipient to determine which decode to perform.

RESOLUTION: This is similar to the previous comment.  It was thought that 
the direction of flow should indicate which decode to perform.  However, 
in order to be more helpful, the following paragraph has been added to 
Section 3.2:

A Time Stamp Request MUST be contained in a file with file extension ".tsr". 
A Time Stamp Response MUST be contained in a file with file extension ".tst".

11. Section 3.3.  It would be useful to implementors to include the state 
machine for the TCP-based protocol.

RESOLUTION: It's not clear that this is required.  I would note that the 
TCP-based protocol is based on the TCP-based protocol from CMP and that 
none is included there.  If a state machine is required, it should be 
included in the draft for CMP transport protocols.

12. Section 3.4.  How does the MIME type distinguish a time stamp request from 
a time stamp token?  The recipient must either decode a TimeStampReq or a 
ContentInfo, and this does not provide enough information to determine 
which operation to perform.

RESOLUTION: This is similar to previous comments.  In order to help determine 
which operation to perform, Section 3.4 has been re-written as:

This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 2 and Appendix D via the
HyperText Transfer Protocol.

Two MIME objects are specified as follows.

Content-Type: application/timestamp-request

   <<the ASN.1 DER-encoded Time Stamp Request message>>

Content-Type: application/timestamp-response

   <<the ASN.1 DER-encoded Time Stamp Response message>>

These MIME objects can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Time Stamp messages.

Upon receiving a valid request, the server MUST respond with either a
valid response with content type application/timestamp-response or with an 
HTTP error.

13. Section 4, item 4.  Each of the transports specified has different delay 
characteristics.  This should be pointed out.

RESOLUTION: The following sentence has been added to the end of Section 4, 
Item 4:

Since each transport method specified in this document has different delay 
characteristics, the period of time that is considered acceptable will 
depend upon the particular transport method used, as well as other 
environment factors.  


EDITORIAL

14. Whole document.  Either add "SHALL" to the list of words that you say are 
defined in RFC 2119, or change "SHALL" to "MUST."

RESOLUTION: "SHALL" has been added.

15. Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the second to 
last sentence.  It should say: "For more details about replay attack 
detection, see the security considerations section (item 6)."

RESOLUTION: Done. 

16. Section 2.4.1, MessageImprint Definition.  I suggest the replacement of 
"hashedMessage" with "MessageHash."  To me, the current name implies the 
full message text rather than a hash of the message text.

RESOLUTION: This would make an ASN1 change. hashedMessage cannot be the 
full message, since this is a hashed Message. MessageHash would be a little 
bit more descriptive, but I think we can live with hashedMessage. Not done.

17. Section 2.4.1, certReq Disscussion.  Typo.  Please move the comma.  The 
sentence should read: "If the certReq field is missing or if the certReq 
field is present and set to false, then ..."

RESOLUTION: Done.

18. Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the registry calls 
this OID id-ct-TSTInfo. Second, I think that it would be more readable to 
define it as follows:
	id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
		 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

RESOLUTION: Done.

19. Section 2.4.2, genTime Discussion.  Some require course granularity, others 
require fine granularity.  I suggest that a TSA MUST offer at least 1 
second granularity.  Filling in the genTime structure with "00" as the 
seconds does not meet this requirement.

RESOLUTION: The sentence "GeneralizedTime values MUST include seconds" has 
been added. Filling in the genTime structure with "00" " as the seconds is 
allowed and does meet this requirement.

20. Section 2.4.2, accuracy Discussion.  I think that a bit more discussion is 
needed.  the syntax permits the seconds and micros fields to be present and 
the millis to be absent.  I am not sure how to add and subtract such a 
structure.

RESOLUTION: The following sentence has been added: "If either seconds, millis 
or micros is missing, then a value of zero MUST be taken for the missing field."

21. Section 2.4.2, ordering Discussion.  Please replace the last sentence with: 
"... TSA can always be ordered based on the genTime field, regardless of 
the genTime accuracy.

RESOLUTION: Done.

22. Section 2.4.2, tsa Discussion.  Please change "an hint" to "a hint."

RESOLUTION: Done.

23. Section 4, item 6.  Please change "(algorithm and)" to "algorithm and."

RESOLUTION: Done.

24. Appendix A.  First, the registry calls this OID id-aa-timeStampToken. 
Second, I think that it would be more readable to define it as follows:
	id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

RESOLUTION: Done.


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04175 for <[e-mail]>; Fri, 22 Sep 2000 07:44:14 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA34410; Fri, 22 Sep 2000 16:51:59 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id QAA20124; Fri, 22 Sep 2000 16:46:26 +0200
Message-ID: <[e-mail]>
Date: Fri, 22 Sep 2000 16:46:29 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>, Russ Housley <[e-mail]>
Subject: TSP: Response to the comments raised by Russ Housley
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

Here are proposed resolutions for the 24 comments you sent during
the IESG last call period for the document:
<draft-ietf-pkix-time-stamp-09.txt>

Would you tell us if you are satisfied with these resolutions ?

Denis 

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

Note the comments have been numbered so that it is easier to refer
to them.

TECHNICAL

1. Section 2.1, 6th requirement.  I do not understand "hash-function 
OID."  OIDs, when managed correctly, are collision free.  I think we
need 
to be discussing the one-way hash function, not its OID.  The
selected 
one-way hash function must be uniquely identified by an OID.

RESOLUTION: Changed the text into: 

   to only time stamp a hash representation of the datum, i.e.
   a data imprint associated with a one-way collision resistant 
   hash-function uniquely identified by an OID.

2. Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The
text says 
that the client SHOULD make the check, but that the client MAY elect
to 
skip the check.  The checking requirement is either a SHOULD or a
MAY, it 
cannot be both.

RESOLUTION: The second sentence which contains the MAY has been
deleted (i.e. "The client MAY ignore this field if that is
acceptable for the intended application".)

3. Section 2.4.1, reqPolicy Discussion.  I do not think that a
reference to 
RFC 2459 is adequate.  First, I do not believe that a certification
policy 
and a TSA policy are equivalent.  At a minimum, the TSA Policy and
TSA 
Practice Statement will have significantly different content.  These 
differences need to be discussed.  Second, I would prefer syntax
without 
qualifiers.  What value do they add in the TSA context?

RESOLUTION: The current wording is as follows: " The reqPolicy
field, if included, indicates the policy under which the
TimeStampToken SHOULD be provided. PolicyInformation is defined in
Section 4.2.1.5 of [RFC2459]."
The second sentence only means that the ASN1 syntax of
PolicyInformation is defined in this document. It is true that a
certification policy and a TSA policy are fairly different but it is
not intended here to go into more details. A separate document on
TSA policy would certainly be useful. Such a work item is being
initiated by ETSI. The results will be presented to the IETF when
available, so that, if the WG agrees, an RFC can be issued. Unless a
proposal is made to clarify the wording, it is believed that no
change is necessary.

4. Section 2.4.1, nonce Discussion.  Please replace "shall" with
"MUST."

RESOLUTION: Done.

5. Section 2.4.2, 3rd paragraph.  The text does not match the
comments in the 
ASN.1 structure.  I assume that the comments are correct.  Please 
rewrite.  I suggest:
  When status contains the value zero or one, a Time Stamp Token
  MUST be present.  When status contains a value other than zero or
  one, a Time Stamp Token MUST NOT be present.  One of the following
  values MUST be contained in status:"

RESOLUTION: It is a good catch for the missing "or one". The rest is
a clarification which has been incorporated

6. Section 2.4.2, 11th paragraph (counting paragraphs is difficult
since the 
ASN.1 fragments are not indented).   Please replace "shall" with
"MUST."

RESOLUTION: Done.

7. Section 2.4.2, serialNumber Discussion.  Please reword the last
sentence to 
include a MUST.  I suggest: "This property MUST be preserved even
after an 
interruption in service (e.g. crash)."

RESOLUTION: Done.

8. Section 2.4.2, genTime Discussion.  Please replace "shall" with 
"MUST."  There are at least five occurrences.

RESOLUTION: Done.

9. Section 3.1.  How does the MIME type distinguish a time stamp
request from 
a time stamp token?  The recipient must either decode a TimeStampReq
or a 
ContentInfo, and this does not provide enough information to
determine 
which operation to perform.

RESOLUTION: While the direction of flow should indicate which
content type to expect, it would probably make things easier if
there were two content types.  Thus, Section 3.1 has been changed to
read:

This section specifies a means for conveying ASN.1-encoded messages 
for the protocol exchanges described in Section 2 and Appendix D via 
Internet mail.

Two MIME objects are specified as follows:

   Content-Type: application/timestamp-request
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp request message,
base64-encoded>>

   Content-Type: application/timestamp-response
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp response message,
base64-encoded>>

These MIME objects can be sent and received using common MIME
processing 
engines and provides a simple Internet mail transport for Time Stamp 
messages.

10. Section 3.2.  It would be helpful to specify file extensions for
a time 
stamp request and a time stamp token.  Such extensions would permit
the 
recipient to determine which decode to perform.

RESOLUTION: This is similar to the previous comment.  It was thought
that the direction of flow should indicate which decode to perform. 
However, in order to be more helpful, the following paragraph has
been added to Section 3.2:

A Time Stamp Request MUST be contained in a file with file extension
".tsr".  A Time Stamp Response MUST be contained in a file with file
extension ".tst".

11. Section 3.3.  It would be useful to implementors to include the
state 
machine for the TCP-based protocol.

RESOLUTION: It's not clear that this is required.  I would note that
the TCP-based protocol is based on the TCP-based protocol from CMP
and that none is included there.  If a state machine is required, it
should be included in the draft for CMP transport protocols.

12. Section 3.4.  How does the MIME type distinguish a time stamp
request from 
a time stamp token?  The recipient must either decode a TimeStampReq
or a 
ContentInfo, and this does not provide enough information to
determine 
which operation to perform.

RESOLUTION: This is similar to previous comments.  In order to help
determine which operation to perform, Section 3.4 has been
re-written as:

This subsection specifies a means for conveying ASN.1-encoded
messages
for the protocol exchanges described in Section 2 and Appendix D via
the
HyperText Transfer Protocol.

Two MIME objects are specified as follows.

Content-Type: application/timestamp-request

   <<the ASN.1 DER-encoded Time Stamp Request message>>

Content-Type: application/timestamp-response

   <<the ASN.1 DER-encoded Time Stamp Response message>>

These MIME objects can be sent and received using common HTTP
processing
engines over WWW links and provides a simple browser-server
transport
for Time Stamp messages.

Upon receiving a valid request, the server MUST respond with either
a
valid response with content type application/timestamp-response or
with an HTTP
error.

13. Section 4, item 4.  Each of the transports specified has
different delay 
characteristics.  This should be pointed out.

RESOLUTION: The following sentence has been added to the end of
Section 4, 
Item 4:

Since each transport method specified in this document has different
delay characteristics, the period of time that is considered
acceptable will depend upon the particular transport method used, as
well as other environment factors.  


EDITORIAL

14. Whole document.  Either add "SHALL" to the list of words that
you say are 
defined in RFC 2119, or change "SHALL" to "MUST."

RESOLUTION: "SHALL" has been added.

15. Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the
second to 
last sentence.  It should say: "For more details about replay attack 
detection, see the security considerations section (item 6)."

RESOLUTION: Done. 

16. Section 2.4.1, MessageImprint Definition.  I suggest the
replacement of 
"hashedMessage" with "MessageHash."  To me, the current name implies
the 
full message text rather than a hash of the message text.

RESOLUTION: This would make an ASN1 change. hashedMessage cannot be
the full message, since this is a hashed Message. MessageHash would
be a little bit more descriptive, but I think we can live with
hashedMessage. Not done.

17. Section 2.4.1, certReq Disscussion.  Typo.  Please move the
comma.  The 
sentence should read: "If the certReq field is missing or if the
certReq 
field is present and set to false, then ..."

RESOLUTION: Done.

18. Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the
registry calls 
this OID id-ct-TSTInfo. Second, I think that it would be more
readable to 
define it as follows:
	id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840)
		 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

RESOLUTION: Done.

19. Section 2.4.2, genTime Discussion.  Some require course
granularity, others 
require fine granularity.  I suggest that a TSA MUST offer at least
1 
second granularity.  Filling in the genTime structure with "00" as
the 
seconds does not meet this requirement.

RESOLUTION: The sentence "GeneralizedTime values MUST include
seconds" has been added. Filling in the genTime structure with "00"
" as the seconds is allowed and does meet this requirement.

20. Section 2.4.2, accuracy Discussion.  I think that a bit more
discussion is 
needed.  the syntax permits the seconds and micros fields to be
present and 
the millis to be absent.  I am not sure how to add and subtract such
a 
structure.

RESOLUTION: The following sentence has been added: "If either
seconds, millis or micros is missing, then a value of zero MUST be
taken for the missing field."

21. Section 2.4.2, ordering Discussion.  Please replace the last
sentence with: 
"... TSA can always be ordered based on the genTime field,
regardless of 
the genTime accuracy.

RESOLUTION: Done.

22. Section 2.4.2, tsa Discussion.  Please change "an hint" to "a
hint."

RESOLUTION: Done.

23. Section 4, item 6.  Please change "(algorithm and)" to
"algorithm and."

RESOLUTION: Done.

24. Appendix A.  First, the registry calls this OID
id-aa-timeStampToken. 
Second, I think that it would be more readable to define it as
follows:
	id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }

RESOLUTION: Done.


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02798 for <[e-mail]>; Fri, 22 Sep 2000 06:35:46 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA21755; Fri, 22 Sep 2000 09:38:39 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v0422080db5eed6f03d27@[128.33.238.22]>
In-Reply-To: <A681CAA9AC8BD4119F0300B0D03D205F05D86F@MAIL>
References: <A681CAA9AC8BD4119F0300B0D03D205F05D86F@MAIL>
Date: Wed, 20 Sep 2000 17:06:01 -0400
To: Mathew  Butler <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Fw: The need for two grades of time data.
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mat,

>Small problem here: Is PKIX not a customer of NTP, for its time information?

Not necessarily.  A TSA could use WWV (in the U.S.) or GPS, ACTS 
(which Todd described in a recent, Informational RFC), or some other, 
non-Internet means of acquiring time.

Steve



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02205 for <[e-mail]>; Fri, 22 Sep 2000 06:04:38 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA19312; Fri, 22 Sep 2000 15:07:34 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 22 Sep 2000 15:07:34 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA09783; Fri, 22 Sep 2000 15:07:33 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA21906; Fri, 22 Sep 2000 15:07:33 +0200 (MET DST)
Date: Fri, 22 Sep 2000 15:07:33 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: OCSPv2 and OCSP extensions drafts
Cc: [e-mail]

> 
> > Where and how is the state maintained?
> 
> The implementation of the server isn't part of the spec.
True. I stumbled over the word 'state', you examples are clear, it
seems we agree that there is  small need for some clarifications/
explications in the text.  
 
> 
> > One possibility is the cookie that was returned, and not in the server.
> > and a client just may accept the first proposal, and has no way to
> > indicate to the server that the association is terminated.
> 
> I don't follow that sentence (or two sentences, whatever:-). The 
> example above should clarify that the client never needs to close 
> a stateful connection or anything like it.

I used cookie as an alias for retryReference. 

The retryReference could be something that allows a server to start
the next "search" behind. As a simple analogy: Reading a directory
and asking "give me the next entry after the this one". 

The retry reference could for example be some encoding of the result, 
assuming that it can be used in order to determine 'what is the next'.

> > In order to maintain a state on a server, one could also use something
> > like the keep-alive technique of http, or what had been discovered
> > in the direct socket based protocol of cmp.
> 
> That's not needed here. If the server no longer has the retryReference
> it returns an error and the client can process the error.
> I could buy that we'd want a specific error, (say referenceNotFound
> or something), but internalError or tryLater should be ok in this case.
> You're probably right that we should specify which error to send in 
> this case (I'd pick internalError).

Right, in fact, using an open 'connection' with the server wouldn't
probably work, for example when the client interacts with the end user
in order to decide whether to proceed.

tryLater is independant of a reference, it can happen, 
when you have lost connectivity to a directory for example. 

Internalerror sounds sufficient. one might try to explain what
a client can try to do after getting such an error, 
may be not now, this may need some implementation experience. 





  


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28628 for <[e-mail]>; Fri, 22 Sep 2000 03:30:03 -0700 (PDT)
Received: by balinese.baltimore.ie; id LAA13677; Fri, 22 Sep 2000 11:32:48 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma012650; Fri, 22 Sep 00 11:28:30 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA10713; Fri, 22 Sep 2000 11:27:27 +0100
Message-ID: <[e-mail]>
Date: Fri, 22 Sep 2000 11:30:02 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], xme <[e-mail]>
Subject: Re: OCSPv2 and OCSP extensions drafts
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

Peter Sylvester wrote:
> 
> The path determination proposal now has the possibility to continue a 'stateful'
> association. There should be at least some more text about saying what this
> actually means.

I'd be interested in any proposals you might have to clarify this feature
(actually, answering your question has thrown up a couple:-).

In any case, what's at issue is not an onerous state, that the server has 
to maintain with each client separately - I'd imagine that a lot of server 
implementations would use the same retryReference value in a response, 
regardless of who makes the request. Calling it stateful is probably 
inaccurate, its more like a shorthand for the "meat" of the request/response 
pair in question.

Just to give an example, say a relying party (rp1) has an ee cert (for ee1) 
and sends a request with the issuer/serial from ee1's cert. The response 
includes retryReference 1. The responder now has all the certs in a path
for ee1 in its cache.

Next, ee1 also contacts rp2 in the same "domain" as rp1 (they use the
same responder). A new request for ee1's path is sent to the responder.
It returns the same path from its cache, with the same retryReference
value (1) to rp2.

If either of rp1 or rp2 don't like the first path and more paths
exist, then in this scenario, they'll both step through the list
of retryReference values chosen by the responder. It doesn't matter
in which order they step through the list, or whether rp1 or
rp2 "leapfrog" one another.

The retryReference values can be changed with each response, so that
there's no "history" needed on the responder (maybe we need this
sentence explicitly in the draft). I don't think we have to 
make this a MUST, in case someone does want to implement a server
that maintains the full history of its dealings with a specific
client, by storing different state information per client (not
that that seems very useful). In any case, it makes no difference
to the client since the client always uses the retryReference from
the most recent response, not from the response to the original 
request (again, maybe we should make this more explicit).

> Where and how is the state maintained?

The implementation of the server isn't part of the spec. 

> One possibility is the cookie that was returned, and not in the server.
> and a client just may accept the first proposal, and has no way to
> indicate to the server that the association is terminated.

I don't follow that sentence (or two sentences, whatever:-). The 
example above should clarify that the client never needs to close 
a stateful connection or anything like it.

> In order to maintain a state on a server, one could also use something
> like the keep-alive technique of http, or what had been discovered
> in the direct socket based protocol of cmp.

That's not needed here. If the server no longer has the retryReference
it returns an error and the client can process the error.
I could buy that we'd want a specific error, (say referenceNotFound
or something), but internalError or tryLater should be ok in this case.
You're probably right that we should specify which error to send in 
this case (I'd pick internalError).

Stephen.



-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12085 for <[e-mail]>; Thu, 21 Sep 2000 15:02:01 -0700 (PDT)
Received: from mega (t1o69p58.telia.com [62.20.144.58]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id AAA06451; Fri, 22 Sep 2000 00:04:17 +0200 (CEST)
Message-ID: <001501c02420$1d3b68c0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Philip Hallam-Baker" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Date: Fri, 22 Sep 2000 01:03:09 +0200
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 ns.secondary.com id PAA12087

Phil et al.

> We are all agreed upon
>what the architecture SHOULD look like. The question is simply one of
>how we migrate towards that architecture.


Regarding this architecture that we all should migrate to:

There is AFAIK no standard set of attributes that CAs always support
which IMO means that DN components is a deployment issue and
are usually profiled for specific uses.  Due to this lack of conformance
each certificate class/type needs its own directory structure.
This assuming that the DN is a multi-valued pointer into a directory tree
which is definitely not always true.  In IIS (MS Webserver), you can apply "rules"
to DN interpretation which of course is due to the fact that there seldom is
a clean 1-1 match between a DN and OS user, customer etc. etc.
By using such mecanisms an RP can BTW handle a lot of certificates
and CAs WITHOUT having all DN components in directories.  Just the "important" ones.
(For encryption purposes you have to store the entire certificate blob though)

Such solutions were maybe not what the X509 designers had in mind but this
is where we are.  And it actually works!

Permanent Identifiers (today usually extracted from DNs and in the future implemented through the
coming PI draft) ease this process even more. And of course diminish the connection between
a certificate DN and a matching (X500) directory entry even further.  X509.v3 certificates are maybe
slowly (but surely) moving away from their original architectural home?

That CAs usually store certificates in directories exactly matching their issued certificates
is natural and easy to do compared to the situation for RPs that usually outnumber their CAs by
several orders of magnitude. 

<snip>

>My VeriSign Certificate has the email address encoded in SubjectAltName
>and not in the DN. So we certainly have the ability to support 2459.
>The 'problem' seems to be that we also support other profiles if
>the customer selects them.


If the custumer orders a VeriSign class #1 certificate or uses the MS CertSrv
(that does not support the 2459 e-mail solution except by forcing the customer
to write their own policy module), you really don't have this option.

Note: I don't complain about neither VeriSign or MSFT.  It is just an observation which
I tried to map on 2459 with limited success.  

Regards
Anders



Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08278 for <[e-mail]>; Thu, 21 Sep 2000 11:15:39 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA201722 for <[e-mail]>; Thu, 21 Sep 2000 14:18:14 -0400
Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with ESMTP id OAA74106 for <[e-mail]>; Thu, 21 Sep 2000 14:18:30 -0400
X-Priority: 3 (Normal)
Importance: Normal
To: [e-mail]
Subject: comments on draft-ietf-pkix-ldap-schema-01.txt
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: <[e-mail]>
Date: Thu, 21 Sep 2000 14:18:15 -0400
X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V505_08212000.dev00 |August 28, 2000) at 09/21/2000 02:18:31 PM, Serialize complete at 09/21/2000 02:18:31 PM
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 0063A3C785256961_="

This is a multipart message in MIME format.
--=_alternative 0063A3C785256961_=
Content-Type: text/plain; charset="us-ascii"

Greetings,

Section 2:
----------
I would prefer that the phrase "use the subschemasubentry attribute in the 
root DSE" be changed to "use the subschemasubentry attribute from the 
namingContext entry which is found in the root DSE".

Section 3.2:
------------
In the BNF for "GeneralName", a single whitespace character appears (e.g. 
"rfc822 +").  Was this intentional?  It seems out of place/misleading.

Editor's note on AuthorityKeyIdentifier:
----------------------------------------
Seems to me that authority issuer name and authority certificate serial 
number could be useful.

Section 4.1:
------------
In the BNF for "CertificateListExactAssertion", the "$" after "Time" is 
OPTIONAL, correct?  It should only be needed if "DistributionPointName" is 
specified, I think.

Section 5 - ISSUE:
------------------
I am not qualified to provide an opinion on this one.

Section 5.3.2 - first Editor's note:
------------------------------------
I would like to see attribute type names (not just OIDs) be allowed.

Section 5.3.2 - second Editor's note:
-------------------------------------
I would find 5.3.9 Time Specification Match to be useful.  I don't have 
experience with the others.


Regards,
Tim Hahn

Internet: [e-mail]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: [phone]     tie-line: 8/852.6388
fax: [phone]
--=_alternative 0063A3C785256961_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Greetings,</font>
<br>
<br><font size=2 face="Courier New">Section 2:</font>
<br><font size=2 face="Courier New">----------</font>
<br><font size=2 face="Courier New">I would prefer that the phrase &quot;use the subschemasubentry attribute in the root DSE&quot; be changed to &quot;use the subschemasubentry attribute from the namingContext entry which is found in the root DSE&quot;.</font>
<br>
<br><font size=2 face="Courier New">Section 3.2:</font>
<br><font size=2 face="Courier New">------------</font>
<br><font size=2 face="Courier New">In the BNF for &quot;GeneralName&quot;, a single whitespace character appears (e.g. &quot;rfc822 +&quot;). &nbsp;Was this intentional? &nbsp;It seems out of place/misleading.</font>
<br>
<br><font size=2 face="Courier New">Editor's note on AuthorityKeyIdentifier:</font>
<br><font size=2 face="Courier New">----------------------------------------</font>
<br><font size=2 face="Courier New">Seems to me that authority issuer name and authority certificate serial number could be useful.</font>
<br>
<br><font size=2 face="Courier New">Section 4.1:</font>
<br><font size=2 face="Courier New">------------</font>
<br><font size=2 face="Courier New">In the BNF for &quot;CertificateListExactAssertion&quot;, the &quot;$&quot; after &quot;Time&quot; is OPTIONAL, correct? &nbsp;It should only be needed if &quot;DistributionPointName&quot; is specified, I think.</font>
<br>
<br><font size=2 face="Courier New">Section 5 - ISSUE:</font>
<br><font size=2 face="Courier New">------------------</font>
<br><font size=2 face="Courier New">I am not qualified to provide an opinion on this one.</font>
<br>
<br><font size=2 face="Courier New">Section 5.3.2 - first Editor's note:</font>
<br><font size=2 face="Courier New">------------------------------------</font>
<br><font size=2 face="Courier New">I would like to see attribute type names (not just OIDs) be allowed.</font>
<br>
<br><font size=2 face="Courier New">Section 5.3.2 - second Editor's note:</font>
<br><font size=2 face="Courier New">-------------------------------------</font>
<br><font size=2 face="Courier New">I would find 5.3.9 Time Specification Match to be useful. &nbsp;I don't have experience with the others.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
Tim Hahn<br>
<br>
Internet: [e-mail]<br>
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)<br>
phone: [phone] &nbsp; &nbsp; tie-line: 8/852.6388<br>
fax: [phone]</font>
--=_alternative 0063A3C785256961_=--


Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07483 for <[e-mail]>; Thu, 21 Sep 2000 10:34:31 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id KAA05482; Thu, 21 Sep 2000 10:33:43 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <SWY14K7A>; Thu, 21 Sep 2000 10:36:50 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Philip Hallam-Baker <[e-mail]>
Cc: [e-mail]
Subject: RE: 2459 disapproved by MSFT and VeriSign?
Date: Thu, 21 Sep 2000 10:36:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_002E_01C023D1.2B33DC90"; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C023D1.2B33DC90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Phil,
> 
> We obviously differ in our views of what constitutes the right way to 
> make tradeoffs wrt Internet standards.  My bias comes from serving on 
> the IAB for over a decade, and from having been involved in the 
> development of Internet protocols for over 20 years.  I'm comfortable 
> with that basis for making the tradeoff. Jon Postel's oft quoted 
> phrase is a good one, and I discussed the implications of it in 
> security contexts on many occasions.  We didn't always agree :-), but 
> Jon was certainly a big supporter of architectural purity.
> 
> Steve

I don't think we have such a wide disagreement. We are all agreed upon
what the architecture SHOULD look like. The question is simply one of
how we migrate towards that architecture.

Suggestions that VeriSign should ONLY issue certificates that don't 
work with X% or of the deployed base for the sake of 'architectural
purity' are plain silly if X is 50% and more reasonable if X is 0.05%.

My VeriSign Certificate has the email address encoded in SubjectAltName
and not in the DN. So we certainly have the ability to support 2459.
The 'problem' seems to be that we also support other profiles if
the customer selects them.


Today every ISP supports IPV4. That is not taken as a statement from
those ISPs that they do not intend to use IPV6. On the contrary, we
all know that eventually there will be a migration but before the
ISPs can move the customers need to be able to buy robust IPV6
platforms.


		Phill 

------=_NextPart_000_002E_01C023D1.2B33DC90
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ
AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx
MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s
IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf
/wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq
PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB
dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz
aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC
BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB
hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr
BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g
YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA
MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc
mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM
F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH
9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy
bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy
aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB
jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA5MjExNzM4MDRa
MCMGCSqGSIb3DQEJBDEWBBRKRsSlrv4qLqlJWK7IELDCYf1CazBYBgkqhkiG9w0BCQ8xSzBJMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl
MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN
BgkqhkiG9w0BAQEFAASBgEusfqDYeIBQfvHk84S7RlfCyrVrUETs9tarh4JRtqa0zcUconhkn9TG
ms/bpg5XdwpfvpjtuEwfLzE1BXXnWrzlubm3UWlYBStJWiEpqJlaTE4gAJde0ewdWixT9U8QWIU3
of1PE6o+IhS8P/NnB0sjZuUpGtKeoVXubekGP+NdAAAAAAAA

------=_NextPart_000_002E_01C023D1.2B33DC90--



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06638 for <[e-mail]>; Thu, 21 Sep 2000 09:46:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA09492; Thu, 21 Sep 2000 18:48:38 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 21 Sep 2000 18:48:38 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA06103; Thu, 21 Sep 2000 18:48:36 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA21526; Thu, 21 Sep 2000 18:48:36 +0200 (MET DST)
Date: Thu, 21 Sep 2000 18:48:36 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: OCSPv2 and OCSP extensions drafts
Cc: [e-mail]

> Peter,
> 
> Maybe I'm the only one who thinks this way, but I view DVCS as more related
> to the validation of signatures on documents and consequently a higher-order
> (i.e. more application-level) protocol than OCSP.  Validation of those
> signatures inherently involves validation of the relevant certificate(s).
> This could be facilitated in part by reference to CRLs or an online
> mechanism (i.e. OCSP).

You mean X509 certificates? One can also say that OCSP does a REAL one-dimensional
thing while DVCS works in COMPLEX environment. 

> 
> The draft that expired was the original "OCSP-X" draft. The DPV and DPD
> drafts draw from and build on that.

The idea of my small comparison was to find out what protocol element are
actually used to implement the required service. Since we are in PKIX and
are not really afraid of borrowing ideas from the X-Series, it seems to me that
a good idea to try to define a service first, unless everybody feels that
this is obvious.

One could also consider that cmp is THE certificate management protocol,
or that an LDAP control could be used for path determination. 

Another thing: 

The path determination proposal now has the possibility to continue a 'stateful'
association. There should be at least some more text about saying what this
actually means. Where and how is the state maintained?
One possibility is the cookie that was returned, and not in the server.
and a client just may accept the first proposal, and has no way to
indicate to the server that the association is terminated. 
In order to maintain a state on a server, one could also use something
like the keep-alive technique of http, or what had been discovered
in the direct socket based protocol of cmp. 

Peter

 







Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06312 for <[e-mail]>; Thu, 21 Sep 2000 09:42:03 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id MAA01615; Thu, 21 Sep 2000 12:44:45 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id <SSF7VFMW>; Thu, 21 Sep 2000 12:37:44 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Mathew  Butler'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, todd glassey <[e-mail]>
Cc: [e-mail]
Subject: RE: Fw: The need for two grades of time data.
Date: Thu, 21 Sep 2000 12:37:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

> Small problem here: Is PKIX not a customer of NTP, for its 
> time information?
> 
> -Mat Butler

Not necessarily. As I understand it, I can by a couple of atomic clocks, or
a land line to NIST and go into the TSP business.

Hal

=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail]
F: 1-508-229-0338             www.entegrity.com
=======================================================



Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06086 for <[e-mail]>; Thu, 21 Sep 2000 09:38:14 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id MAA01602; Thu, 21 Sep 2000 12:41:07 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id <SSF7VFMP>; Thu, 21 Sep 2000 12:34:05 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Tim Polk'" <[e-mail]>, todd glassey <[e-mail]>
Cc: [e-mail]
Subject: RE: WG chairs, TSP, and two grades of time data
Date: Thu, 21 Sep 2000 12:34:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Todd, et al

I for one have been baffled by this discusion.

> You asked to have TTP inserted into the name.  Steve 
> suggested that the
> scope could note that the spec is based on a TTP model.  I 
> think that's
> reasonable.

The abstract of the document begins:

"A time stamping service allows to prove that a datum existed before 
a particular time and can be used by a Trusted Third Party (TTP) as 
one component in building reliable non-repudiation services (see 
[ISONR])."

The beginning of the Introduction says:

"In order to associate a datum with a particular point in time, a
Time Stamp Authority (TSA) may need to be used.  This Trusted Third 
Party provides a "proof-of-existence" for this particular datum at an 
instant in time."

Without getting in to the merits of a TTP vs. non-TTP approach, why has it
not been clear to everybody for the last year or so that this protocol is
based on the use of a TTP?

Regardsd,

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail]
F: 1-508-229-0338             www.entegrity.com
=======================================================




Received: from uobmail.balamand.edu.lb (balamand.edu.lb [193.227.175.7] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29677 for <[e-mail]>; Thu, 21 Sep 2000 07:36:26 -0700 (PDT)
From: [e-mail]
Received: from gnr.net ([216.77.220.217]) by uobmail.balamand.edu.lb (Netscape Messaging Server 3.54)  with SMTP id AGU316; Wed, 20 Sep 2000 19:27:39 -0200
To: [e-mail]
Subject: So, How in the heck have you been?
Date: Wed, 20 Sep 2000 19:27:38 -0200
Message-ID: <[e-mail]>

So, How in the heck have you been?

Do you remember holding previous conversations regarding business and
money making opportunities? I did not send this to you in error!

You Said:

If only I could find an easier way to make a higher income!

and

If I had more money, I could spend more time with my Family, and less
time at work and I sure could use more money so I could pay off my
bills once and for all!

And

I would love to get involved in a business in which will generate money
while I am not at work (like a Gas Pump)!

Dear Friend,

There is a possibility that we haven’t met, but you were chosen by
someone to receive this E-Mail. Please, please, print this off and
read thoroughly. Be sure that you don’t miss any of the points
outlined.  Then put it down, and then read it again. I am sending
you a whole lot of information in which you might not understand
the first time you read it. If you don’t believe this  program
will work for you, send it to 10-20 of your closest friends
(in which you trust deeply),  and ask them what they think?
This really works! Have faith, don’t miss this opportunity,
get involved also, and it will work for you as it does for us!!!!

Due to the popularity of this letter on the Internet, A Major Nightly
News Program recently dedicated an entire show to the investigation of
the
program described below to see if it really can make people money.
The show also investigated whether or not the program was legal. Their
findings proved that there are absolutely no laws prohibiting the
participation in the program. This has helped to show people that this
is a simple, harmless and fun way to make extra money at home. The
results have been truly remarkable. So many people are participating
that those involved are doing much better than ever before. Since
everyone makes more as more people try it out, its been very exciting.

You will understand only if you get involved!
********** THE ENTIRE PLAN IS HERE BELOW **********
**** Print This Now For Future Reference ****

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make AT LEAST $50,000 in less than 90 days! If not,

forward this to someone who would like to make this kind of money.
It works (like designed) but only for those who follow it to the letter!

Please read this program THEN READ IT AGAIN!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT
require you to come into contact with people or make or take any
telephone
calls. Just follow the instructions, and you will make money. This
simplified e-mail marketing program works perfectly 100% EVERY TIME!

E-mail is the sales tool of the future. Take advantage of this virtually

free method of advertising NOW!!! The longer you wait, the more people
will
be doing business using e-mail. Get your piece of this action!!!

Hello, My name is Johnathon Rourke, I’m from Rhode Island.  The enclosed

information is something I almost let slip through my fingers.
Fortunately, sometime later I re-read everything and gave some thought
and study to it. Two years ago, the corporation I worked for the past
twelve yearsdown-sized and my position was eliminated. After
unproductive
job interviews, I decided to open my own business. Over the past year,I
incurred many unforeseen financial problems. I owed my family, friends
and
creditors over$35,000. The economy was taking a toll on my business and
I
just could not seem to make ends meet. I had to refinance and borrow
against
my home to support my family and struggling business.

AT THAT MOMENT something significant happened in my life. I am writing
to share the experience I hopes that this could change your life
FOREVER.
FINANCIALLY$$$!!!

In mid December, I received this program in my e-mail. Six months prior
to
receiving this program I had been sending away for information on
various
business opportunities. All of the programs I received, in my
opinion,were
not cost effective. They were either toodifficult for me to comprehend
or
the initial investment was too muchfor me to risk to see if they would
work.
But as I was saying, in December of 1997 I received this program.I
didn’t
send for it, or ask for it, they just got my name off a mailing list.

THANK GOODNESS FOR THAT!!!

After reading it several times, to make sure I was reading it correctly.
I
couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start
immediately without any debt. Like most of you I was still a little
skeptical and a little worried about the legalaspects of it all. So I
checked it out with the U.S. Post Office (1-800-725-2161 24-hrs)  and
they
confirmed that it is indeed legal ! After determining the program was
LEGAL
I decided WHY NOT!?!??

Initially I sent out 10,000 e-mails. It cost me about $15 for my time
on-line. The great thing about e-mail is that I don’t need any paper for

printing to send out the program, and because I also send the product
(reports) by e-mail, my only expense is my time. In less than one week,I
was
starting to receive orders for REPORT #1.

By January 13, I had received 26 orders for REPORT #1. Your goal is to
RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T
SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in
90
days was done. By January 30, I had received 196 orders for REPORT #2.
Your
goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN
2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE
100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL.

Well, I had 196 orders for REPORT #2. 96 more than I needed. So I
sat back and relaxed.

By March 1, of my e-mailing of 10,000, received $58,000 with more coming
in
every day. I paid off ALL my debts and bought a much need new car!
Please
take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!!
Remember, it won’t work if you don’t try it. This program does work, But
you
must follow it EXACTLY! Especially the rules of not trying to place your

name in a different place. It won’t work and you’ll lose out on a lot of

money! In order for this program to work, you must meet your goal of 20+

orders for REPORT #1, and 100+ orders for REPORT #2 and you will make
$50,000 or more in 90 days.

I AM LIVING PROOF THAT IT WORKS!!!

If you choose not to participate in this program, I am sorry. It really
is a great opportunity with little cost or risk to you.  If you choose
toparticipate, follow the program and you will be on your way to
financial security. If you are a fellow business owner and
are financial trouble like I was, or you want to start your own
business, consider this a sign. I DID! $$

Sincerely,
Johnathon Rourke

A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you
have read the enclosed program and reports, you should have concluded
that
such a program, and one that is legal, cpuld not have been created by an

amateur. Let me tell you a little about myself. I had a profitable
business
for 10 years. Then in 1979 my business began falling off. I was doing
the
same things that were previously successful for me, but it wasn’t
working.
Finally, I figured it out. It wasn’t me, it was the economy. Inflation
and
recession had replaced the stable economy that had been with us since
1945.
I don’t have to tell you what happened to the unemployment rate because
many
of you know from first hand experience. There were more failures and
bankruptcies than ever before. The middle class was vanishing. Those who

knew what they were doing invested wisely and moved up. Those who did
not,
including those who never had anything to save or invest, were moving
down into the ranks of the poor. As the saying goes, THE RICH GET RICHER

ANDTHE POOR GET POORER.  The traditional methods of making money will
never
allow you to move up or get rich, inflation will see to that You have
just
received the rest of  your life, with NO RISK and JUST A LITTLE BIT OF
EFFORT. You can make more money in the next few months than you have
everimagined.I should also point out that I will not see a penny of this

money, nor anyone else who has provided a testimonial for this program.
I
retired from the program after sending thousands and thousands of
programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way.
It
works exceedingly well as it is now. Remember to e-mail a copyof this
exciting report to everyone you can think of. One of the people you send

this to may send out 50,000 and your name will be on everyone of them!
REMEMBER though, ------ the MORE YOU SEND OUT, the more potential
customers
you will reach. So my friend, I have given you the ideas,  information,
materials and opportunity to become financially independent.

IT IS UP TO YOU!! NOW DO IT!!

BEFORE YOU delete this program from your in box, as I almost did, take a

little time to read it and REALLY THINK ABOUT IT. Get a pencil and
figure out what could happen when YOU participate. Figure out the worst
possible response and no matter how you calculate it, you will still
make a
lot of money! You will definitely get back what you invested. Any doubts
you
have will vanish when your first orders come in. $$$ IT WORKS!!! $$$

Jody Jacobs Richmond, VA.

HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF
DOLLARS$$$$!!!!

This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure
that you could use up to $50,000 or more in the next 90 days. Before you
say
BULL, please read this program carefully. This is not a chain letter,but
a
perfectly legal money making business. As with all multi-level
businesses,
we build our business by recruiting new partners and selling our
products.
Every state in the USA allows you to recruit new multi-level business
partners, and we sell and deliver a product for EVERY dollar received.

YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not
involved in personal selling. You do it privately in your own home,
store or
office. This is the EASIEST marketing plan anywhere! It is simply order
filling by e-mail! The product is informational and instructional
material,
keys to the secrets for everyone on how to open the doors to the magic
world
of E-COMMERCE, the information highway, the wave of the future !

PLAN SUMMARY:

(1) You order the 4 reports listed below ($5 each) They come to you by
e-mail.

(2)  Save a copy of this entire letter and put your name after Report #1
and
move the other names down.

(3)  Via the internet, access Yahoo.com or any of the other major search

engines to locate hundreds of bulk e-mail service companies (search for
bulk
email) and have them send 25,000  50,000 emails for you about $49+.

(4)  Orders will come to you by postal mail simply e-mail them the
Report they ordered. Let me ask you  isn’t this about as easy as it
gets?

By the way there are over 50 MILLION e-mail address with millions more
joining the internet each year so don’t worry about running out or
saturation. People are used to seeing and hearing the same
advertisements every day on radio/TV. How many times have you received
the same pizza flyers on your door? Then one day you are hungry for
pizza
and order one. Same thing with this letter. I received this letter many
times  then one day I decided it was time to try it.

YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR
REPORTS

Order the four reports shown on the list below (you can’t sell them if
you don’t order them).  For each report, send $5.00 CASH, the NAME &
NUMBER
OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME &
RETURN
ADDRESS (in case of a problem) to the person whose name appears on the
list
next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN
CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail

each of the four reports.Save them on your computer so you can send them
to
the 1,000’s of people who will  order them from you.

STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER

a. Look below for the listing of the four reports.
b. After you’ve ordered the four reports, delete the name and address
under REPORT #4. This person has made it through the cycle.
c. Move the name and address under REPORT #3 down to REPORT #4.
d. Move the name and address under REPORT #2 down to REPORT #3.
e. Move the name and address under REPORT #1 down to REPORT #2.
f. Insert your name/address in the REPORT #1 position. Please make sure
you

COPY ALL INFORMATION, every name and address, ACCURATELY!

STEP #3. Take this entire letter, including the modified list of names,
and save it to your computer. Make NO changes to these instructions. Now
you
are ready to use this entire e-mail to send by e-mail to prospects.

Report #1 will tell you how to download bulk email software and email
address so you can send it out to thousands of people while you sleep!
Remember that 50,000+ new people are joining the internet every month!
Your cost to participate in this is practically nothing ( surely you can

afford $20 and initial bulk mailing cost). You obviously already have a
computer and an Internet connection and e-mail is FREE! There are two
primary methods of building your downline: METHOD #1: SENDING BULK
E-MAIL
let’s say that you decide to start small, just to see how it goes, and
we’ll
assume you and all those involved email out only 2,000 programs each.
Let’s
also assume that the mailing receives a 0.5% response. The response
could be
much better. Also, many people will email out thousands of thousands of
programs instead of 2,000 (Why stop at 2000?) But continuing with this
example, you send out only 2,000 programs. With a 0.5% response, that is

only 10 orders for REPORT #1. Those 10 people respond by sending out
2,000
programs each for a total of 20,000. Out of those 0.5%, 100 people
respond
and order REPORT #2.Those 100 mail out 2,000 programs each for a total
of
200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those
1,000 send out 2,000  programs each for a 2,000,000 total. The 0.5%
response
to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you.
CASH!!! Your total income in this example is $50 + $500 + $5000 +
$50,000
for a total of $55,550!!!

REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL
TO
WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A
MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS
INSTEAD OF 2,000. Believe me, many people will do just that, and more!

METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet
is very, very inexpensive, and there are HUNDREDS of FREE places to
advertise. Let’s say you decide to start small to see how well it works.

Assume your goal is to get ONLY 10 people to participate on your first
level. (Placing a lot of FREE ads on the Internet will EASILY get a
larger
response). Also assume that everyone else in YOUR ORGANIZATION gets only
10
downline members. Look how this small number accumulates to achieve the
STAGGERING results below:

1St level  your first 10 send you $5........................$50
2nd level  10 members from those 10 ($5 x 100)............$500
3rd level  10 members from those 100 ($5 x 1,000)......$5,000
4th level 10 members from those 1,000 ($5 x 10,000)..$50,000
$$$$$$ THIS TOTALS
------------------------------------------------55,5550
$$$$$

AMAZING ISN’T IT Remember friends, this assumes that the people who
participate only recruit 10 people each. Think for a moment what would
happen if they got 20 people to participate! Most people get 100’s of
participants and many will continue to work this program, sending out
programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT!
People are going to get emails about this plan from you or somebody else
and
many will work this plan  the question is Don’t you want your name to be
on
the emails they will send out?

*** DON’T MISS OUT !!!***
***JUST TRY IT ONCE !!!***
***SEE WHAT HAPPENS !!!***
***YOU'LL BE AMAZED !!!***

ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that
the e-mail THEY send out with YOUR name and address on it will be prompt

because they can’t advertise until they receive the report!

GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:--
ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT
ACCEPTED.
Make sure the cash is concealed by wrapping it in two sheets of paper.
On
one of those sheets write:

(a) the number & name of the report you are ordering
(b) your e-mail address, and
(c) your name & postal address.

REPORT #1b The Insider’s Guide to Advertising for Free on the Internet
ORDER REPORT #1 FROM:

NICK NICHOLAS
473 MICHIGAN ST
ST.PAUL, MN 55102

NOTE: I and every member below are dedicated at helping you with this
program so it will work for you also. TRY US!

REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet
ORDER REPORT #2 FROM:

DIANE COLON
1811 TAMARIND AVE # 206
LOS ANGELES, CA. 90028

REPORT #3 The Secrets to Multilevel Marketing on the Internet
ORDER REPORT #3 FROM:

MELISSA HOGENMILLER
3709 MONHEIM ROAD
CONOVER, WI 54519

REPORT #4 How to become a Millionaire utilizing the Power of Multilevel
Marketing and the Internet
ORDER REPORT #4 FROM:

CATHY BARROW
10 SYCAMORE STREET
CONWAY, SC 29527

*************TIPS FOR SUCCESS***************
TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the
directions accurately.  Send for the four reports IMMEDIATELY so you
will have them when the orders start coming in because: When you
receive a $5 order you MUST send out the requested product/report.
It is required for this to be a legal business and they need the
reports to send out their letter (with your name on them).

--ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be
patient and persistent with this program- If you follow the
instructions exactly results WILL FOLLOW. $$$$

************ YOUR SUCCESS GUIDELINES ***************

Follow these guidelines to guarantee your success: If you don’t receive
20 orders for REPORT #1 within two weeks, continue advertising or
sending
e-mail until you do. Then a couple of weeks later you should receive at
least 100 orders for REPORT #2. If you don’t continue advertising or
sending
e-mail until you do. Once you have received 100 or more orders for
REPORT
#2, YOU CAN RELAX, because the system is already working for you, and
the
cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER:  Every
time
your name is moved down on the list, you are placed in front of a
DIFFERENT
report. You can KEEP TRACK of your  PROGRESS by watching which report
people
are ordering from you. To generate more income, simply send another
batch of
e-mails or continue placing ads and start the whole process again! There
is
no limit to the income you will generate from this business! Before you
make
your decision as to whether or not you participate in this program.
Please
answer one question:

ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB?

1. If the answer is no, then please look at the following facts about
this super simple MLM program: NO face to face selling, NO meetings, NO
inventory! NO Telephone calls, NO big cost to start! Nothing to learn,
No skills needed! (Surely you know how to send email?)

2. No equipment to buy you already have a computer and internet
connection so you have everything you need to fill orders!

3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR
SHIP! (Email copies of the reports are FREE!)

4. All of your customers pay you in CASH! This program will change your
LIFE  FOREEVER!! Look at the potential for you to be able to quit your
job and live a life of luxury you could only dream about! Imagine
getting out of debt and buying the car and home of your dreams and
being able to work a super-high paying leisurely easy business from
home!

$$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW!
Take your first step toward achieving financial independence.  Order
the reports and follow the program outlined above __ SUCCESS will be
your reward.

Thank you for your time and consideration. PLEASE NOT: If you need
help with starting a business, registering a business name, learning
now income tax is handled, etc., contact your local office of the
Small Business Administration  (A Federal Agency) 1-800-827-5722
for free help and answers to questions. Also the Internal Revenue
Service offers free help via telephone and free seminars about
business tax requirements. Your earnings are highly dependent on
your activities and advertising. The information contained on this
site and in the report constitutes no guarantees stated nor implied.
In the event that it is determined that this site or report
constitutes a guarantee of any kind, that guarantee is now void. The
earnings amounts listed on this site and in the report are estimates
only. If you have any questions of the legality of this program,
contact the Office of Associate Director for Marketing Practices,
Federal Trade Commission, Bureau of Consumer Protection in
Washington DC.

Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal. This is a one time
e-mail transmission. No request for removal is necessary.





Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19233 for <[e-mail]>; Thu, 21 Sep 2000 01:12:16 -0700 (PDT)
Received: from [38.29.122.25] (ip25.phoenix10.az.pub-ip.psi.net [38.29.122.25]) by scaup.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id BAA07032; Thu, 21 Sep 2000 01:14:12 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a04330103b5ef5ffbb1ed@[38.29.122.25]>
Date: Thu, 21 Sep 2000 01:11:27 -0700
To: OSI Directory List <[e-mail]>, [e-mail], [e-mail]
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: sixth revision of the draft 4th edition of X.509 is on the server
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

hello

some of you observant readers out there have found a few more 
problems in the text. we have corrected them.

a sixth revision of the draft 4th edition of x509 is on the directory 
server in both pdf and office 98 formats. the urls are:

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.doc

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.pdf

this revision (v6) contains corrections in three areas:

1) Subject versus holder

In the attribute certificate match matching rule (asn.1 and descriptive
text), the terminology needs to be updated to reflect the technical
agreement that attribute certificates are issued to holders, not to
subjects.

In clause 17.3.2, and in Annex A in the attribute certificate framework
module, in the AttributeCertificateAssertion ASN.1 production:

replace "subject" with "holder" and replace "subjectName" with "holderName"

In clause 17.3.2 in the 2nd bullet following the ASN.1, replace "subjectName"
with "holderName".


2) Optional authority key id

The authority key identifier component in the certificate list 
assertion syntax, should be optional.

In clause 11.3.6 and in the certificate extensions module of Annex A, in the
CertificateListAssertion ASN.1 production;

replace:
	authorityKeyIdentifier	[3]  AuthorityKeyIdentifier}

with:
	authorityKeyIdentifier	[3]  AuthorityKeyIdentifier  OPTIONAL }


3) Optional serial number

The syntax of the attribute certificate exact matching rule should be 
aligned to that of the attribute certificate issuer.

In clause 17.3.1 and in the attribute certificate framework module of Annex
A, in the AttributeCertificateExactAssertion ASN.1 production:

replace
	serialNumber	CertificateSerialNumber,

with
	serialNumber	CertificateSerialNumber  OPTIONAL,


The ISO ballot on this text will close 28 November. The document will 
then be formally published and available for purchase shortly after 
that date. I will remove the copy of this document from the server at 
that time.

keep those cards and letters coming

    hoyt


Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08686 for <[e-mail]>; Wed, 20 Sep 2000 15:22:42 -0700 (PDT)
Received: from tsg1 ([12.72.64.152]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000920222500.MXUA17935.mtiwmhc21.worldnet.att.net@tsg1>; Wed, 20 Sep 2000 22:25:00 +0000
Message-ID: <008b01c02351$97ceced0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107]><012e01c021a2$3aa00cc0$020aff0c@tsg1><v0422080eb5ec195cd7b0@[171.78.30.107]><002201c021cd$09a42ae0$020aff0c@tsg1> <[e-mail]><016401c022c8$8dfc0000$020aff0c@tsg1> <v04220801b5eeb2a2cd6d@[128.33.238.45]>
Subject: Re: Fw: The need for two grades of time data.
Date: Wed, 20 Sep 2000 15:24:04 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 20, 2000 12:55 PM
Subject: Re: Fw: The need for two grades of time data.

Come on Steve -

>
> >Read the first sentence of the 2nd paragraph of the WG
> >Description on the WG's homepage It's quoted below:
> >----
> >"The working group is now embarking on additional standards work to
develop
> >protocols that are either integral to PKI management, or that are
otherwise
> >closely related to PKI use."
> >----
> >Time and its services are clearly members of this set.
>
> Time is covered under this when it is intrinsic to PKI management or
> use, as is the case for a time stamping protocol.  There are many
> ways for a  PKI user to acquire time for use in cert processing.

Steve I think you are wrong here. What this is really all about is the
difference in using time as content and in using "what time it is" as part
of the control process.

>
> >  So then using PKI
> >Authenticated NTP as a timebase for general PKIX PKI would have made a
lot
> >of sense. Especially  with the sheer number of places its already
deployed.
> >It would have given PKIX protocol's tens of  millions more seats than
they
> >already have, automagically.
>





Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08084 for <[e-mail]>; Wed, 20 Sep 2000 15:03:45 -0700 (PDT)
Received: from tsg1 ([12.72.64.152]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000920220602.MPCL17935.mtiwmhc21.worldnet.att.net@tsg1>; Wed, 20 Sep 2000 22:06:02 +0000
Message-ID: <006101c0234e$f1cd2ab0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Mathew  Butler" <[e-mail]>
Cc: <[e-mail]>
References: <A681CAA9AC8BD4119F0300B0D03D205F05D86F@MAIL>
Subject: Re: Fw: The need for two grades of time data.
Date: Wed, 20 Sep 2000 14:45:04 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Mat -

1)    PKIX has no standard method of moving time around. The IETF does,
several of them - only none of them are referenced by the TSP or are used in
the TSP drafts for the synchronization of the TSA.

In fact the TSA in the TSP applies an arbitrary time instance to the stamp
that from a trust standpoint is about as reliable Carney Hucksters pitch.
There is no way in the TSP of proving anything about the Time in the Time
Stamp so then to use it, an external CPS and the associated agreements must
all be weighed to use this at any commercial level - Just doesn't make sense
to me.

2)    And what people are not realizing is that the use of NTP as a time
stamping system uses the protocol in two modes. The first is a transport for
time data, what is understood as the traditional use, and the second would
be as a transport for the audit process or TST's that get schlepped around.

The NTP solution as a carrier for the TST's themselves would invalidate the
need to build a separate protocol for this as well. Eliminates the need for
a separate level of code at the Server; and as I am so fond of saying, it
makes millions of PKI enabled systems deployable instantly. Which is
critically good for the advancement of PKI as an industry at large.

Todd
----- Original Message -----
From: "Mathew Butler" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>; "todd glassey"
<[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 20, 2000 1:38 PM
Subject: RE: Fw: The need for two grades of time data.


> Small problem here: Is PKIX not a customer of NTP, for its time
information?
>
> -Mat Butler
>
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, September 20, 2000 12:55 PM
> To: todd glassey
> Cc: [e-mail]
> Subject: Re: Fw: The need for two grades of time data.
>
>
> Todd,
>
> >I have to apologize because this is a philosophical retort  and I don't
> mean
> >to be a stick in the mud but -
> >
> >  >
> >  > NTP is not part of the charter of this group, so this kind of topic
> >  > cannot be dealt in the PKIX WG, unless the charter is changed.
> >
> >Denis this is just not true- the use of any protocol with PKI in it is
> >germain to the Charter of this WG whether that core protocol was
developed
> >here or not.
>
> Not true. S/MIME, TLS and IPsec make use of PKI, but are clearly out
> of scope. They are consumers of PKI services, just as one would
> expect NTP to be when  it makes use of PKI for authentication of its
> communication.
>
> >Read the first sentence of the 2nd paragraph of the WG
> >Description on the WG's homepage It's quoted below:
> >----
> >"The working group is now embarking on additional standards work to
develop
> >protocols that are either integral to PKI management, or that are
otherwise
> >closely related to PKI use."
> >----
> >Time and its services are clearly members of this set.
>
> Time is covered under this when it is intrinsic to PKI management or
> use, as is the case for a time stamping protocol.  There are many
> ways for a  PKI user to acquire time for use in cert processing.
>
> >  So then using PKI
> >Authenticated NTP as a timebase for general PKIX PKI would have made a
lot
> >of sense. Especially  with the sheer number of places its already
deployed.
> >It would have given PKIX protocol's tens of  millions more seats than
they
> >already have, automagically.
>
> This is pure speculation, bereft of substantiation! It ignores the
> typical reasons usually cited for reluctance by a company to
> establish a PKI.
>
> >You know if people had to get x509 certs for
> >the millions of routers they had, it would have advanced the cause of
x509
> >use tremendoulsy and as such our world as well.
>
> S-BGP is another application that motivates issuance of certs to
> routers, but I don't expect it to make a dent in broader use of PKI.
>
> Steve



Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06810 for <[e-mail]>; Wed, 20 Sep 2000 13:39:48 -0700 (PDT)
Received: by MAIL with Internet Mail Service (5.5.2650.21) id <TASRLVC4>; Wed, 20 Sep 2000 13:38:54 -0700
Message-ID: <A681CAA9AC8BD4119F0300B0D03D205F05D86F@MAIL>
From: Mathew  Butler <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, todd glassey <[e-mail]>
Cc: [e-mail]
Subject: RE: Fw: The need for two grades of time data.
Date: Wed, 20 Sep 2000 13:38:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Small problem here: Is PKIX not a customer of NTP, for its time information?

-Mat Butler

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, September 20, 2000 12:55 PM
To: todd glassey
Cc: [e-mail]
Subject: Re: Fw: The need for two grades of time data.


Todd,

>I have to apologize because this is a philosophical retort  and I don't
mean
>to be a stick in the mud but -
>
>  >
>  > NTP is not part of the charter of this group, so this kind of topic
>  > cannot be dealt in the PKIX WG, unless the charter is changed.
>
>Denis this is just not true- the use of any protocol with PKI in it is
>germain to the Charter of this WG whether that core protocol was developed
>here or not.

Not true. S/MIME, TLS and IPsec make use of PKI, but are clearly out 
of scope. They are consumers of PKI services, just as one would 
expect NTP to be when  it makes use of PKI for authentication of its 
communication.

>Read the first sentence of the 2nd paragraph of the WG
>Description on the WG's homepage It's quoted below:
>----
>"The working group is now embarking on additional standards work to develop
>protocols that are either integral to PKI management, or that are otherwise
>closely related to PKI use."
>----
>Time and its services are clearly members of this set.

Time is covered under this when it is intrinsic to PKI management or 
use, as is the case for a time stamping protocol.  There are many 
ways for a  PKI user to acquire time for use in cert processing.

>  So then using PKI
>Authenticated NTP as a timebase for general PKIX PKI would have made a lot
>of sense. Especially  with the sheer number of places its already deployed.
>It would have given PKIX protocol's tens of  millions more seats than they
>already have, automagically.

This is pure speculation, bereft of substantiation! It ignores the 
typical reasons usually cited for reluctance by a company to 
establish a PKI.

>You know if people had to get x509 certs for
>the millions of routers they had, it would have advanced the cause of x509
>use tremendoulsy and as such our world as well.

S-BGP is another application that motivates issuance of certs to 
routers, but I don't expect it to make a dent in broader use of PKI.

Steve


Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06205 for <[e-mail]>; Wed, 20 Sep 2000 13:10:33 -0700 (PDT)
Received: from [128.33.238.22] (TC034.BBN.COM [128.33.238.34]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id QAA07345; Wed, 20 Sep 2000 16:12:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220808b5eec9500827@[128.33.238.22]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 20 Sep 2000 16:10:50 -0400
To: Philip Hallam-Baker <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: 2459 disapproved by MSFT and VeriSign?
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Phil,

We obviously differ in our views of what constitutes the right way to 
make tradeoffs wrt Internet standards.  My bias comes from serving on 
the IAB for over a decade, and from having been involved in the 
development of Internet protocols for over 20 years.  I'm comfortable 
with that basis for making the tradeoff. Jon Postel's oft quoted 
phrase is a good one, and I discussed the implications of it in 
security contexts on many occasions.  We didn't always agree :-), but 
Jon was certainly a big supporter of architectural purity.

Steve



Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05955 for <[e-mail]>; Wed, 20 Sep 2000 13:08:46 -0700 (PDT)
Received: from pavilion (asynce031.nist.gov [129.6.31.31]) by email.nist.gov (8.9.3/8.9.3) with SMTP id QAA04308; Wed, 20 Sep 2000 16:11:32 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Wed, 20 Sep 2000 16:18:52 -0400
To: todd glassey <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: WG chairs, TSP, and two grades of time data
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <003701c0217c$18af0b00$020aff0c@tsg1> <v04220801b5ebe1d3cb63@[171.78.30.107]> <012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002201c021cd$09a42ae0$020aff0c@tsg1> <[e-mail]> <016401c022c8$8dfc0000$020aff0c@tsg1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Todd,

You said you were withdrawing your objections to TSP's progression. Thank you.

You asked to have TTP inserted into the name.  Steve suggested that the
scope could note that the spec is based on a TTP model.  I think that's
reasonable.

Let's progress TSP and move on, okay?  It's a good spec, even if it doesn't
solve everyone's problems all the time.

Now, moving on....

You have asked if the WG chairs would support an additional protocol.  I
can't speak for Steve.  As for myself, I can't support a new protocol
unless I understand what it adds.  Multiple protocols that do the same
thing are no good for anyone.

I postulated a number of properties for the TSP spec in a number of
statements in my email last Friday and asked where I was wrong.  There has
been no reply to that message from you, Adrian, or anyone else.

Please take the time to read my message from Friday and comment on it.
Either the properties I postulate are (1) wrong, (2) insufficient, or (3)
there is no need for a new protocol.  In the absence of a response to
Friday's message, I am leaning towards (3).

Thanks,

Tim Polk





Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05423 for <[e-mail]>; Wed, 20 Sep 2000 12:52:30 -0700 (PDT)
Received: from [128.33.238.22] (TC022.BBN.COM [128.33.238.22]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id PAA02904; Wed, 20 Sep 2000 15:55:12 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220801b5eeb2a2cd6d@[128.33.238.45]>
In-Reply-To: <016401c022c8$8dfc0000$020aff0c@tsg1>
References:  <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107 ]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002201c021cd$09a42ae0$020aff0c@tsg1> <[e-mail]> <016401c022c8$8dfc0000$020aff0c@tsg1>
Date: Wed, 20 Sep 2000 15:55:15 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>I have to apologize because this is a philosophical retort  and I don't mean
>to be a stick in the mud but -
>
>  >
>  > NTP is not part of the charter of this group, so this kind of topic
>  > cannot be dealt in the PKIX WG, unless the charter is changed.
>
>Denis this is just not true- the use of any protocol with PKI in it is
>germain to the Charter of this WG whether that core protocol was developed
>here or not.

Not true. S/MIME, TLS and IPsec make use of PKI, but are clearly out 
of scope. They are consumers of PKI services, just as one would 
expect NTP to be when  it makes use of PKI for authentication of its 
communication.

>Read the first sentence of the 2nd paragraph of the WG
>Description on the WG's homepage It's quoted below:
>----
>"The working group is now embarking on additional standards work to develop
>protocols that are either integral to PKI management, or that are otherwise
>closely related to PKI use."
>----
>Time and its services are clearly members of this set.

Time is covered under this when it is intrinsic to PKI management or 
use, as is the case for a time stamping protocol.  There are many 
ways for a  PKI user to acquire time for use in cert processing.

>  So then using PKI
>Authenticated NTP as a timebase for general PKIX PKI would have made a lot
>of sense. Especially  with the sheer number of places its already deployed.
>It would have given PKIX protocol's tens of  millions more seats than they
>already have, automagically.

This is pure speculation, bereft of substantiation! It ignores the 
typical reasons usually cited for reluctance by a company to 
establish a PKI.

>You know if people had to get x509 certs for
>the millions of routers they had, it would have advanced the cause of x509
>use tremendoulsy and as such our world as well.

S-BGP is another application that motivates issuance of certs to 
routers, but I don't expect it to make a dent in broader use of PKI.

Steve



Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03919 for <[e-mail]>; Wed, 20 Sep 2000 11:27:46 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA12080; Wed, 20 Sep 2000 11:26:46 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <SWY1T96P>; Wed, 20 Sep 2000 11:29:52 -0700
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Subject: RE: 2459 disapproved by MSFT and VeriSign?
Date: Wed, 20 Sep 2000 11:29:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0008_01C0230F.6AB62F20"; micalg=SHA1; protocol="application/x-pkcs7-signature"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C0230F.6AB62F20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I find this discussion somewhat strange. The long standing principle of
the IETF has been to make systems as interoperable as possible. In
particular the IETF has always frowned on architectural transitions that
cause deployed products to break unnecessarily.

Architectural purity has ALWAYS come second.

There are good reasons to ensure that all applications are capable of
ACCEPTING email addresses encoded in SubjectAltName. Not least the fact
that people in organizations tend to have multiple email addresses.

'Be permissive in what you accept, be caution in what you generate'

It is no problem for a CA to generate email addresses in any particular
certificate slot - especially if the CA does not care about strict
compliance with the X.509 standard.

Customers on the other hand might have problems using those certificates
with legacy applications. A substantial part of the value added by an
outsource service is to be able to help the customer make informed
decisions about the configuration of their certificate.


		Phill

Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227




------=_NextPart_000_0008_01C0230F.6AB62F20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINaDCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIBAgIQ
AxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcNMDAx
MjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl
Y2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNpZ24s
IEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq6dnf
/wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrTInfq
PKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQABo4IB
dDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZlcmlz
aWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8EBAMC
BaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgB
hvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr
BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4g
YnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeA
MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApBXCjc
mPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoANmsM
F/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqHvbaH
9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVy
bXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVy
aVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUAoIIB
jDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDA5MjAxODMxMDha
MCMGCSqGSIb3DQEJBDEWBBQhSjNadbK0K9J3s7XsNKTGcGh4CzBYBgkqhkiG9w0BCQ8xSzBJMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMC
GjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEl
MCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAN
BgkqhkiG9w0BAQEFAASBgCIf6omyzAT974sMNnximdVT/VSYc8jqWnMe7hpOn7OIFei41RZYYoHT
MsSOvcp0WMaONGLhE1rOz62r6vIb2TBXACJwcL+6JZpDqgPeKfWOksH3fYRx0c147x9PFZmsKoQv
cFi3n9VR2/1CCguShI4dt6rRweZfYFvnm7Uy349mAAAAAAAA

------=_NextPart_000_0008_01C0230F.6AB62F20--



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA18955 for <[e-mail]>; Wed, 20 Sep 2000 03:27:17 -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 GAA17430; Wed, 20 Sep 2000 06:30:03 -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-ocsp-path-00.txt
Date: Wed, 20 Sep 2000 06:30:03 -0400
Sender: [e-mail]

--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		: Delegated Path Discovery with OCSP
	Author(s)	: M. Myers, S. Farrell, C. Adams
	Filename	: draft-ietf-pkix-ocsp-path-00.txt
	Pages		: 11
	Date		: 19-Sep-00
	
OCSP [RFC2560] establishes the Internet standard for online certificate status. An OCSP path discovery responder is an enhanced OCSP responder that provides requestors with certification paths.  The technological and geographic diversity of the sources of these data motivates existence of service that enables relying-party software to acquire certification path data from an OCSP server rather than replicate the same functionality. This specification establishes an Internet standard extension to OCSP to address this need.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-path-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-ocsp-path-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-ocsp-path-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-ocsp-path-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-path-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 hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16179 for <[e-mail]>; Wed, 20 Sep 2000 03:05:52 -0700 (PDT)
Received: from [38.29.122.82] (ip82.phoenix10.az.pub-ip.psi.net [38.29.122.82]) by hawk.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id DAA19799; Wed, 20 Sep 2000 03:03:49 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a04330100b5ee39eb68ca@[38.29.122.218]>
Date: Wed, 20 Sep 2000 03:00:15 -0700
To: OSI Directory List <[e-mail]>
From: "Hoyt L. Kesterson II" <[e-mail]>
Subject: Announcement of X.500 (including X.509) meeting
Cc: [e-mail], "Bertine, Herbert V (Herbert" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

An editing and rapporteur meeting will be held 13 through 17 November 
in Orlando, Florida.

Details can be found at

ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000/Meeting/announcement.pdf

   hoyt


Received: from uekae.uekae.gov.tr (uekae.mam.gov.tr [193.140.77.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13242 for <[e-mail]>; Wed, 20 Sep 2000 01:27:57 -0700 (PDT)
Received: from tafics2 (zigana.uekae.gov.tr [192.168.5.2]) by uekae.uekae.gov.tr (8.11.0/8.11.0/SuSE Linux 8.9.3-0.1) with SMTP id e8K8alw27330 for <[e-mail]>; Wed, 20 Sep 2000 11:36:47 +0300
Message-ID: <001d01c02341$a1e94680$[e-mail]>
From: =?iso-8859-9?B?QWx0dfAgWWF2Yf4=?= <[e-mail]>
To: <[e-mail]>
Subject: get me off
Date: Wed, 20 Sep 2000 23:30:36 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C0235A.C72EDD60"
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

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C0235A.C72EDD60
Content-Type: text/plain;
	charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable

Please get me out of this list!
Altug

------=_NextPart_000_001A_01C0235A.C72EDD60
Content-Type: text/html;
	charset="iso-8859-9"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-9" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Please get me out of this =
list!</FONT></DIV>
<DIV><FONT face=3D"Arial TUR" size=3D2>Altug</FONT></DIV></BODY></HTML>

------=_NextPart_000_001A_01C0235A.C72EDD60--



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09704 for <[e-mail]>; Tue, 19 Sep 2000 23:31:07 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA54686; Wed, 20 Sep 2000 08:38:43 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id IAA32204; Wed, 20 Sep 2000 08:33:15 +0200
Message-ID: <[e-mail]>
Date: Wed, 20 Sep 2000 08:33:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: Fw: The need for two grades of time data.
References: <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002201c021cd$09a42ae0$020aff0c@tsg1> <[e-mail]> <016401c022c8$8dfc0000$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Todd,

As you said at the very end: "But hey, that's just my opinion". I do
not share your opinion.

Denis

> I have to apologize because this is a philosophical retort  and I don't mean
> to be a stick in the mud but -
> 
> >
> > NTP is not part of the charter of this group, so this kind of topic
> > cannot be dealt in the PKIX WG, unless the charter is changed.
> 
> Denis this is just not true- the use of any protocol with PKI in it is
> germain to the Charter of this WG whether that core protocol was developed
> here or not.   Read the first sentence of the 2nd paragraph of the WG
> Description on the WG's homepage It's quoted below:
> ----
> "The working group is now embarking on additional standards work to develop
> protocols that are either integral to PKI management, or that are otherwise
> closely related to PKI use."
> ----
> Time and its services are clearly members of this set. So then using PKI
> Authenticated NTP as a timebase for general PKIX PKI would have made a lot
> of sense. Especially  with the sheer number of places its already deployed.
> It would have given PKIX protocol's tens of  millions more seats than they
> already have, automagically. You know if people had to get x509 certs for
> the millions of routers they had, it would have advanced the cause of x509
> use tremendoulsy and as such our world as well.
> 
> >
> 
> What is it Dennis Miller Says - "But hey, that's just my opinion".
> 
> Todd


Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA08291 for <[e-mail]>; Tue, 19 Sep 2000 23:01:44 -0700 (PDT)
Received: from tsg1 ([12.72.113.96]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000920060358.DAHY8992.mtiwmhc26.worldnet.att.net@tsg1>; Wed, 20 Sep 2000 06:03:58 +0000
Message-ID: <016401c022c8$8dfc0000$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002201c021cd$09a42ae0$020aff0c@tsg1> <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Date: Tue, 19 Sep 2000 23:03:47 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

I have to apologize because this is a philosophical retort  and I don't mean
to be a stick in the mud but -

>
> NTP is not part of the charter of this group, so this kind of topic
> cannot be dealt in the PKIX WG, unless the charter is changed.

Denis this is just not true- the use of any protocol with PKI in it is
germain to the Charter of this WG whether that core protocol was developed
here or not.   Read the first sentence of the 2nd paragraph of the WG
Description on the WG's homepage It's quoted below:
----
"The working group is now embarking on additional standards work to develop
protocols that are either integral to PKI management, or that are otherwise
closely related to PKI use."
----
Time and its services are clearly members of this set. So then using PKI
Authenticated NTP as a timebase for general PKIX PKI would have made a lot
of sense. Especially  with the sheer number of places its already deployed.
It would have given PKIX protocol's tens of  millions more seats than they
already have, automagically. You know if people had to get x509 certs for
the millions of routers they had, it would have advanced the cause of x509
use tremendoulsy and as such our world as well.

>

What is it Dennis Miller Says - "But hey, that's just my opinion".

Todd



Received: from animus.mf.uni-lj.si (animus.mf.uni-lj.si [193.2.69.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA07473 for <[e-mail]>; Tue, 19 Sep 2000 22:56:02 -0700 (PDT)
Received: from gemini ("port 4961"@[193.2.210.199]) by MF.UNI-LJ.SI (PMDF V5.2-31 #42976) with SMTP id <[e-mail]> for [e-mail]; Wed, 20 Sep 2000 07:58:47 CET
Date: Wed, 20 Sep 2000 07:55:59 +0200
From: Matjaz Ostroversnik <[e-mail]>
Subject: get me off the list please
To: [e-mail]
Reply-to: Matjaz Ostroversnik <[e-mail]>
Message-id: <00df01c022c7$85491750$[e-mail]>
Organization: ZTK
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.3825.400
X-Mailer: Microsoft Outlook Express 5.50.3825.400
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>

Could someone get me off the list please.
----- Original Message -----
From: "Michael Myers" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, September 19, 2000 6:58 PM
Subject: RE: OCSPv2 and OCSP extensions drafts


> Peter,
>
> Maybe I'm the only one who thinks this way, but I view DVCS as more
related
> to the validation of signatures on documents and consequently a
higher-order
> (i.e. more application-level) protocol than OCSP.  Validation of those
> signatures inherently involves validation of the relevant certificate(s).
> This could be facilitated in part by reference to CRLs or an online
> mechanism (i.e. OCSP).
>
> The draft that expired was the original "OCSP-X" draft. The DPV and DPD
> drafts draw from and build on that.
>
> Mike
>
> > -----Original Message-----
> > From: Peter Sylvester [mailto:[e-mail]]
> > Sent: Tuesday, September 19, 2000 4:59 AM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: OCSPv2 and OCSP extensions drafts
> >
> >
> > > Mike:
> > >
> > > This raises a bigger question.  I do not think that PKIX
> > should have more
> > > than one way to do remove cert path validation.  There
> > seems to be three
> > > approaches on the table.  Which protocol is the right one
> > (OCSP, SCVP, or DCS)?
> > The name of the last is DVCS. :-)
> >
> > >
> > > Personally, I would rather not spend a lot of time reviewing three
> > > different approaches.  Rather, I would like to determine
> > the way we are
> > > going, then review the one.  Maybe each of the proponents
> > could summarize
> > > how their protocol stacks up against the requirements.  (It
> > might be my
> > > memory, but I thought we had a requirements discussion on
> > the list.  It is
> > > not in an Internet-Draft).
> >
> > I read the OCSP draft-ietf-pkix-ocsp-valid-00.txt and would like to
> > compare this with what is the corresponding part in DVCS.
> >
> > Unless I have misunderstood something, besides the different encoding
> > of requests and responses, the essential data elements to be
> > compared in a
> > draft-ietf-pkix-ocsp-valid-00.txt requests and responses are:
> >
> > ReqCert  ::= CHOICE {
> >      certID            CertID,
> >      issuerSerial      [0] IssuerandSerialNumber,
> >      pKCert            [1] Certificate,
> >      name              [2] GeneralName }
> >
> > and
> >
> > DPVOptions  :: = SEQUENCE{
> >     initialPolicySet [0] EXPLICIT PolicyList OPTIONAL,
> >     trustPoints       SEQUENCE OF ReqCert OPTIONAL }
> >
> > The corresponding data structures in DVCS
> >
> >    TargetEtcChain ::= SEQUENCE {
> >         target                       CertEtcToken,
> >         chain                        SEQUENCE SIZE (1..MAX) OF
> >                                         CertEtcToken OPTIONAL,
> >         pathProcInput                [0] PathProcInput OPTIONAL
> >    }
> >
> >    PathProcInput ::= SEQUENCE {
> >         acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
> >                                         PolicyInformation,
> >         inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
> >         explicitPolicyReqd           BOOLEAN DEFAULT FALSE
> >    }
> >
> >    CertEtcToken ::= CHOICE {
> >         certificate                  [0] IMPLICIT Certificate ,
> >         esscertid                    [1] ESSCertId ,
> >         pkistatus                    [2] IMPLICIT PKIStatusInfo ,
> >         assertion                    [3] ContentInfo ,
> >         crl                          [4] IMPLICIT CertificateList,
> >         ocspcertstatus               [5] IMPLICIT CertStatus,
> >         oscpcertid                   [6] IMPLICIT CertId ,
> >         oscpresponse                 [7] IMPLICIT OCSPResponse,
> >         capabilities                 [8] SMIMECapabilities,
> >         extension                    Extension
> >    }
> >
> >
> > The difference in dvcs is that it allows
> > inhibitPolicyMapping, explicitPolicyReqd
> > That doesn't seem a very big deal, in the ocsp draft this can
> > be easily added
> > (if considered useful).
> >
> > The definition of TargetEtcChain.chain part in DVCS
> > unfortunately says:
> >
> >      Each certificate to be verified MUST be included in a separate
> >      instance of TargetEtcChain, and to be verified.  The
> >      'TargetEtcChain.chain' field, if present, MUST indicate the chain
> >      of trust to be used when certifying the certificate.
> >
> > There are several possibilities:
> > One is making several TargetEtcChain, and getting status for
> > ALL the possible trust points.
> > Another is to modify the text above to give more freedom to
> > the server,
> > actually the same semantics as in the ocsp extension draft..
> >
> > So:
> >
> > There is a lot of overlap among the protocols, they can also
> > be regarded
> > as complementary.
> >
> > DVCS allows to return not only a validated path but also all
> > validation information
> > that come with it, saying basically: 'I think the cert status
> > is X and I have based
> > my information on that and that information.'  For example
> > there could be an
> > imbedded ocsp reponse for an intermediate CA.
> >
> > Peter Sylvester
> >
> > Is it correct that the other ocsp draft (path) is *already* expired?
> >
> >



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09671 for <[e-mail]>; Tue, 19 Sep 2000 13:21:20 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA27718 for <[e-mail]>; Tue, 19 Sep 2000 16:07:40 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 19 Sep 2000 16:18:05 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vzYdJXrECPsdPoLAaBZs7A==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Anders Rundgren" <[e-mail]>
> 
> The E= in Subject *IS* a standard way of putting e-mail addresses in 
certificates! 
> By far the most common solution also... 
> 
> To "criminalize" that is far too late.
> 
> The recommendation in 2459 has no important architectural merit. If it had, 
people 
> would follow it. Quite simple logic there IMO. It is just a result of 
> "historical" problems and 2459 should also say that. I.e. there are *two* 
EQUALLY
> conformant solutions which is admittedly unfortunate but nothing to do about 
except accepting. 


The merit of putting alternative names in the SubjectAltName extension
is that distinguished names and rfc822 names are from different
namespaces.

Yes, you can use the syntax of RDNSequence to contain an rfc822name,
just as you can use it to contain a copyright and limitation of
liability statement.  But the fact that it is both syntactically
possible and "VeriSign/Microsoft standard" to stuff absolutely anything
into the subject Name field does not imply that mixing RDN attributes
from different namespaces (or no namespace at all) has architectural
merit.  Nor does the fact that large numbers of people use what they
get for free imply that what they use is architecturally sound.



Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04200 for <[e-mail]>; Tue, 19 Sep 2000 10:22:17 -0700 (PDT)
Received: from tsg1 ([12.72.2.144]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000919172427.NWKP8992.mtiwmhc26.worldnet.att.net@tsg1>; Tue, 19 Sep 2000 17:24:27 +0000
Message-ID: <011901c0225e$6edf6be0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002201c021cd$09a42ae0$020aff0c@tsg1> <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Date: Tue, 19 Sep 2000 10:16:09 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Denis,
how is this TS API not an API and wherein is it a true networking protocol.
This process is as much application dependant as any so what would you do,
design a shared library of these services, OK that sounds like middleware to
me. What do you call it?

Todd

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, September 19, 2000 12:16 AM
Subject: Re: Fw: The need for two grades of time data.


> Todd,
>
> > Stephen I understand how to solve part of this problem, it is my intent
to
> > submit an API Specification for the use of the already existing NTP
AutoKey
> > to this group for TSP Uses.
>
> APIs is usually not a task performed by the IETF; it is only
> performed by exception. The GSS-APIs fall under that exception.
>
> NTP is not part of the charter of this group, so this kind of topic
> cannot be dealt in the PKIX WG, unless the charter is changed.
>
> > The draft will be in as an I-D within 14-17 days.
>
> You can certainly post such a draft, but as an individual draft, not
> as a PKIX draft.

How do you figure.

>
> > Anyone that would like to
> > collaborate on this please contact me immediately. We will in this draft
> > also show the use of the TSP API on top of NTP to address the
evidentiary
> > problems that the TSA does not address as well as a number of other
protocol
> > interfaces like one to generate TST's for IOTP and XML uses.
> >
> > I personally would suggest holding the standard until then and reviewing
it.
>
> This is unrelated, so your "suggestion" is not relevant.

Sorry it is exactly relevant and the draft should be held if the underlying
assumption I made in the original posting is correct.

>
> Denis
>
>
> > Two weeks does not push the time frame out too far to delay any decision
on
> > the TSP Draft and advancing it over something as heavily deployed as the
> > Network Time Protocol.
> >
> > Todd
> >
> > ----- Original Message -----
> > From: "Stephen Kent" <[e-mail]>
> > To: "todd glassey" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Monday, September 18, 2000 12:15 PM
> > Subject: Re: Fw: The need for two grades of time data.
> >
> > > Todd,
> > >
> > > We have no other PKI-oriented time stamping standards on the table. I
> > > don't think we can answer that question in the abstract.
> > >
> > > Any candidate would have to be technically sound, not encumbered by
> > > any IP [certainly no more than we already have :-)], consistent with
> > > our PKI models, and be accompanied by a well written description.
> > >
> > > Nothing that has been submitted to this list has met these criteria.
> > >
> > > Steve
> > >
>



Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA03523; Tue, 19 Sep 2000 09:59:07 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Sep 2000 17:00:42 UT
Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA17603; Tue, 19 Sep 2000 12:59:06 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2448.0) id <SC8Y2BVV>; Tue, 19 Sep 2000 10:01:47 -0700
Message-ID: <[e-mail]>
From: "Kingdon, Kevin" <[e-mail]>
To: "'Andrew Farrell'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Q: Is possible indefinite form of length encoding in DER? 
Date: Tue, 19 Sep 2000 10:01:46 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

See comments below:

-----Original Message-----
From: Andrew Farrell [mailto:[e-mail]]
Sent: Tuesday, September 19, 2000 7:42 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Q: Is possible indefinite form of length encoding in DER? 


<SNIP/>

On the ridiculous end of this rule is a certificate in which everything
is indefinite length encoded - perfectly valid AFAIK, as long as you
re-encode before verifying.

<KWK>
Further complicating matters is the fact that some commercial products
incorrectly sign the BER encoding. So to validate a signature against a
BER-encoded message, you may have to try validating the with the transmitted
encoding and if that fails try re-coding and validating against the
DER-encoding of the message. (Note that signing BER is flawed if there is a
possibility that an intermediate processor will re-code the BER encoding
into a different but equivalent BER encoding. This usually doesn't happen
with BER, but it is expected to happen with XML-encoded documents. Thus
there is increased emphasis on "canonicalization" procedures for XML digital
signatures.)
</KWK>

<SNIP/>


Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03327 for <[e-mail]>; Tue, 19 Sep 2000 09:57:24 -0700 (PDT)
Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA07050; Tue, 19 Sep 2000 09:55:38 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <SW0280VV>; Tue, 19 Sep 2000 09:58:43 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Peter Sylvester <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: OCSPv2 and OCSP extensions drafts
Date: Tue, 19 Sep 2000 09:58:37 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Peter,

Maybe I'm the only one who thinks this way, but I view DVCS as more related
to the validation of signatures on documents and consequently a higher-order
(i.e. more application-level) protocol than OCSP.  Validation of those
signatures inherently involves validation of the relevant certificate(s).
This could be facilitated in part by reference to CRLs or an online
mechanism (i.e. OCSP).

The draft that expired was the original "OCSP-X" draft. The DPV and DPD
drafts draw from and build on that.

Mike

> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Tuesday, September 19, 2000 4:59 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: OCSPv2 and OCSP extensions drafts
> 
> 
> > Mike:
> > 
> > This raises a bigger question.  I do not think that PKIX 
> should have more 
> > than one way to do remove cert path validation.  There 
> seems to be three 
> > approaches on the table.  Which protocol is the right one 
> (OCSP, SCVP, or DCS)?
> The name of the last is DVCS. :-)
> 
> > 
> > Personally, I would rather not spend a lot of time reviewing three 
> > different approaches.  Rather, I would like to determine 
> the way we are 
> > going, then review the one.  Maybe each of the proponents 
> could summarize 
> > how their protocol stacks up against the requirements.  (It 
> might be my 
> > memory, but I thought we had a requirements discussion on 
> the list.  It is 
> > not in an Internet-Draft).
> 
> I read the OCSP draft-ietf-pkix-ocsp-valid-00.txt and would like to
> compare this with what is the corresponding part in DVCS. 
> 
> Unless I have misunderstood something, besides the different encoding
> of requests and responses, the essential data elements to be 
> compared in a
> draft-ietf-pkix-ocsp-valid-00.txt requests and responses are: 
> 
> ReqCert  ::= CHOICE {
>      certID            CertID,
>      issuerSerial      [0] IssuerandSerialNumber,
>      pKCert            [1] Certificate,
>      name              [2] GeneralName }
> 
> and 
> 
> DPVOptions  :: = SEQUENCE{
>     initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, 
>     trustPoints       SEQUENCE OF ReqCert OPTIONAL } 
> 
> The corresponding data structures in DVCS    
> 
>    TargetEtcChain ::= SEQUENCE {
>         target                       CertEtcToken,
>         chain                        SEQUENCE SIZE (1..MAX) OF
>                                         CertEtcToken OPTIONAL,
>         pathProcInput                [0] PathProcInput OPTIONAL
>    }
> 
>    PathProcInput ::= SEQUENCE {
>         acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
>                                         PolicyInformation,
>         inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
>         explicitPolicyReqd           BOOLEAN DEFAULT FALSE
>    }
> 
>    CertEtcToken ::= CHOICE {
>         certificate                  [0] IMPLICIT Certificate ,
>         esscertid                    [1] ESSCertId ,
>         pkistatus                    [2] IMPLICIT PKIStatusInfo ,
>         assertion                    [3] ContentInfo ,
>         crl                          [4] IMPLICIT CertificateList,
>         ocspcertstatus               [5] IMPLICIT CertStatus,
>         oscpcertid                   [6] IMPLICIT CertId ,
>         oscpresponse                 [7] IMPLICIT OCSPResponse,
>         capabilities                 [8] SMIMECapabilities,
>         extension                    Extension
>    }
> 
> 
> The difference in dvcs is that it allows 
> inhibitPolicyMapping, explicitPolicyReqd
> That doesn't seem a very big deal, in the ocsp draft this can 
> be easily added
> (if considered useful).  
> 
> The definition of TargetEtcChain.chain part in DVCS 
> unfortunately says:
> 
>      Each certificate to be verified MUST be included in a separate
>      instance of TargetEtcChain, and to be verified.  The
>      'TargetEtcChain.chain' field, if present, MUST indicate the chain
>      of trust to be used when certifying the certificate. 
> 
> There are several possibilities: 
> One is making several TargetEtcChain, and getting status for 
> ALL the possible trust points.
> Another is to modify the text above to give more freedom to 
> the server,
> actually the same semantics as in the ocsp extension draft..  
> 
> So: 
> 
> There is a lot of overlap among the protocols, they can also 
> be regarded
> as complementary. 
> 
> DVCS allows to return not only a validated path but also all 
> validation information
> that come with it, saying basically: 'I think the cert status 
> is X and I have based
> my information on that and that information.'  For example 
> there could be an
> imbedded ocsp reponse for an intermediate CA.
> 
> Peter Sylvester
> 
> Is it correct that the other ocsp draft (path) is *already* expired?
> 
> 


Received: from windoze.tenebras.com (windoze.tenebras.com [216.15.43.196]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03131 for <[e-mail]>; Tue, 19 Sep 2000 09:56:03 -0700 (PDT)
Received: from dnai.com (localhost [127.0.0.1]) by windoze.tenebras.com (8.9.3/8.9.3) with ESMTP id JAA46217; Tue, 19 Sep 2000 09:57:31 -0700 (PDT) (envelope-from [e-mail])
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 19 Sep 2000 09:57:30 -0700
From: Michael Sierchio <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: Stephen Kent <[e-mail]>, Tony Bartoletti <[e-mail]>, [e-mail]
Subject: Re: Fw: The need for two grades of time data.
References: <[e-mail]><002701c021b7$3a5b07f0$020aff0c@tsg1><003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107 ]><012e01c021a2$3aa00cc0$020aff0c@tsg1><v0422080eb5ec195cd7b0@[171.78.30.107]><002701c021b7$3a5b07f0$020aff0c@tsg1><[e-mail]> <[e-mail]> <00c901c02253$0df42d30$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

todd glassey wrote:

> In answering these questions lets look at the real world solutions today.
> First lets answer the question: What is the need or desire for a evidentiary
> grade of time data? the answer to that is simple. In proofing and
> comparison-based decision support systems, the willingness for people to
> trust these systems is often 100% rooted in the whether they can document
> what they say is or is not. The concept is clearly outlined and is woven
> through most of what PKIX does under the term "non-repudiation", so lets
> look at today's timebase system's and apply non-repudiation to them. i.e..
> do they support it? ...

Your observations are cogent and lucid, but I tend to agree that the 
problems you articulate are operational matters, without direct relevance
to the TSP itself.

There are hazards inherent to relying on GPS as a sole means of
authoritative time data, just as there is risk inherent in relying
on it as a sole means of navigation.  There are several operational
steps that can be taken to provide trust in the evidentiary value
of the time data used, all of which seem outside the scope of the
protocol discussion, or even the choice of time signal source.

I am very much interested in continuing the discussion, which has
merit,  in a different context.


Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01455 for <[e-mail]>; Tue, 19 Sep 2000 09:00:51 -0700 (PDT)
Received: from tsg1 ([12.72.2.144]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000919160300.MHZK8992.mtiwmhc26.worldnet.att.net@tsg1>; Tue, 19 Sep 2000 16:03:00 +0000
Message-ID: <00c901c02253$0df42d30$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><002701c021b7$3a5b07f0$020aff0c@tsg1><003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107 ]><012e01c021a2$3aa00cc0$020aff0c@tsg1><v0422080eb5ec195cd7b0@[171.78.30.107]><002701c021b7$3a5b07f0$020aff0c@tsg1><[e-mail]> <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Date: Tue, 19 Sep 2000 09:01:59 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Tony your response below touches on two key issues

    1)     Is there any difference in time for evidentiary grade purposes
and that provided by any other time source (Yes of course there is.
Evidentiary Time is non-repudiated and the other time sources are not.)

    2)    How the TSP/TSA Architecture provides services.

The are both very important but important questions/concepts, and they
should not be confused. Lets look at the first one. The issue of Evidentiary
Time Data.

In answering these questions lets look at the real world solutions today.
First lets answer the question: What is the need or desire for a evidentiary
grade of time data? the answer to that is simple. In proofing and
comparison-based decision support systems, the willingness for people to
trust these systems is often 100% rooted in the whether they can document
what they say is or is not. The concept is clearly outlined and is woven
through most of what PKIX does under the term "non-repudiation", so lets
look at today's timebase system's and apply non-repudiation to them. i.e..
do they support it?

    a)    NTP by itself - NTP By itself will authenticate the end-node
identity of the Time Service Provider (the NTP Server) either in symmetric
or asymmetric service models if you can find someone to operate such a
service. Becuase of the PKI or Symmetric Key Management and the audit
overhead, none of the Public NTP Time Servers will provide this. ONLY the
commercial services like those offered by CertifiedTime today address this
concept that the quality of the time data is guaranteed inline in the NTP
Audit Process and there is a real money indemnity policy backing this. Hence
getting time from a TA (rather than a CA).

For generic NTP when the PKI Extensions are widely distributed this will
allow for various players to operate these anchored NTP Servers, but even
that wont provide the NR we are all looking for in digital trust processes.
However this NR facility, since it is not as time sensitive as the actual
deployment of NTP time makes NTP work as one obvious answer as a generic
Time Service transport including being a transport for the TSA.

Bluntly, the TSP Use and Time Data NR features could easily be added to the
NTP process as an additional parcel as a part of the user defined payload.

    b) ACTS - The NIST or USNO ACTS systems - provides no security or record
of the use. No access to certifiable time is available through this as well
although it is performed form a closed circuit non-networked system so the
audit value is better IMHO than generic NTP.

    c)    GPS Systems - Many security reports are now surfacing on the DoS
and spoofing susceptibility of the GPS system, but from an audit standpoint
there is even a larger vulnerability here in that GPS cannot be
authenticated or the results of stored in such a manner as the transaction
process can be rebuilt for later review. GPS being passive in nature has
virtually no way for Civilian Receivers to replay or rebuild any of the GPS
Timestamps issued as part of the GPS system's operations.

The other issue is in understanding the true security perimeter of the GPS
systems operations models. This is an important concept since by addressing
it we discover that GPS, an externally processed signal, and the particular
GPS data stream is unauthenticated in conveyance and its
certification/accuracy making the reliance on GPS a pure Trust RISK. Not an
enablement as many have been lead to believe. Sorry folks, the using GPS as
a source of trusted time is a mistake IMHO.

Many people believe that using a security policy wherein a log entry shows
when the GPS Signal Lost Lock will provide this "logging of the signal
process" but it really does not do this. The issue is that since the GPS
Data Service Model  is still passive in nature this relying on the "Pilot
Lock"  really means little or nothing at all from an audit perspective. The
totality of the envelope of trust for a GPS system is IMHO  the skin of the
Receiver unit itself and not its injection point into the computer whether
that is at the Bus Interface Level or through a Serial Port. .

One of the issues here is in removing human culpability from the process
stages internal to the transaction processes. It is bad enough that human
participation limits the reliability of the raw data points such that PKI
has to be used to prove them, but the same liability exists with the time
and other audit parameters as do the certificate parameters that we have
fought so hard to authenticate. This is the point wherein time data is used
as content rather than plumbing or infrastructure, and as such it deserves
the same levels of authentication and trust processing as any other
datapoint in the trust envelope in question.

The point is does the setting of the OS TOD clock require an Evidentiary
Grade of time or not. That is the question that really needs to be answered
here and the answer is that the audit and trust processes will make that
determination. Since the TSA takes time off the underlying OS without any
concern for its validity is a problem in my book too.

Todd

----- Original Message -----
From: "Tony Bartoletti" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 18, 2000 4:47 PM
Subject: Re: Fw: The need for two grades of time data.


> At 07:05 PM 9/18/00 -0400, Stephen Kent wrote:
>
> >>Seriously, is it fundamentally IP issues, or "non-TTP model"
> >>issues, or "there can be only one TSP standard" issues, or
> >>something else that is objectionable "on principle alone".
> >
> >It's not "non-TTP model" and it is IP concerns. But we also don't need to
> >endorse equivalent ways of doing the same thing, since that degrades
> >interoperability, or imposes extra burdens on implementors. We've having
> >that debate no with regard to delegated path processing, validation,
> >etc.  I don't want to limit the reasons I might object to another TSP
> >proposal to the set that are immediately obvious: there may be
innumerable
> >examples of other bad TSP model one could devise :-)
>
> The latter seems then to fall under "something else that is objectionable
> on principle." :)
>
> The central (non-IP) issue is then the validity of the phrase
> "equivalent ways of doing the same thing".  Certainly, there is
> no need or desire to really do the same thing in different but
> equivalent ways ... so ...
>
> 1.  Are these "the same thing"?  Todd argues that "time as control
parameter"
> and "time as evidentiary content" are in principle different things, and
that
> this is not just a matter of degree but a matter of kind.  If these are
really
> not different (equivalently, not needed), then the story ends quickly.
>
> 2.  Are the assurance procedures really "equivalent ways"?  If there is
truth
> to the distinction regarding "time, the evidence", and a reason to believe
> that it may be a quantity "in demand", then one must examine if it
deserves
> other than the TTP-treatment for assurance.
>
> (Indeed, an attempt to rely upon a TTP model seems to introduce an endless
> regress of stamps and assurances.  At a minimum, it has a multiplying
effect
> on "things to be assured about.")
>
> Perhaps by sticking to the core "is it really different/needed"
examinations,
> one can progress to a resolution without the allusions to ulterior motives
> that often surface (Mea Culpa!)
>
> ___tony___
>
>
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
>



Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25566 for <[e-mail]>; Tue, 19 Sep 2000 08:03:29 -0700 (PDT)
Received: from asn-1.com (user-2ivf0kk.dialup.mindspring.com [165.247.130.148]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA28235; Tue, 19 Sep 2000 11:05:55 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Tue, 19 Sep 2000 11:07:48 -0400
From: "Phillip H. Griffin" <[e-mail]>
Reply-To: [e-mail]
Organization: Griffin Consulting 
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Rich Ankney <[e-mail]>
CC: ChungKil Kim <[e-mail]>, [e-mail]
Subject: Re: Is possible indefinite form of length encoding in DER?
References: <000f01c021e5$ef117520$7888a4d8@rankney>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Rich,

Rich Ankney wrote:
> 
> I think all of the RFC 2630 stuff needs to be DER.  It's not clear at all

RFC 2630 says this:

   The Cryptographic Message Syntax values are generated using ASN.1
   [X.208-88], using BER-encoding [X.209-88].  Values are typically
   represented as octet strings.  

I could go on and on about this one. First of course is that
DER is a subset of BER, so DER is allowed anywhere that some
protocol specifies BER. And of course you're right that almost
all specifications (except for this one) based on derivatives 
of RSA's PKCS #7 rely on DER. Since BER is used the encoding
details are at the option of the sender and the restrictions
of DER do not hold here. Note that X.209 predates DER and does
not define any distinguished encoding rules. DER is defined in
X.690 and a Directory-only DER variant is defined in X.509. 

And the current RSA PKCS specifications all rely on well
constructed ASN.1 notation based on the current ASN.1 
standards (as is the case for all ISO, ITU-T, and X9
specifications) rather than on the deprecated X.208/209
versions of the ASN.1 standards, which are in maintenance
and scheduled for withdrawal. No one is working on these
versions to amend them to add new types (UTF8String,
BMPString, RELATIVE-OID) and notation (ENCODED BY, 
CONTAINING) or to correct their many known defects. 

> what you can do about some ASN.1 wrapped in the eContent OCTET
> STRING though.  If that were ASN.1 (wrapped in an OS) there's no
> way to signal how it's encoded (although this sort of thing is a topic
> in the new version of ASN.1).  Theoretically it could be anything but it

Yes, we use this new constraint notation in two of our
recent specifications, X9.68 compressed domain certificates
and X9.84 biometric management which are both in/near some
stage of balloting. The new constraint notation allows tools
to identify the format of the value portion of an octet or
bit string with an object identifier.

For example, X9.68 contains revised versions of familiar 
cryptographic types:

   MessageDigest ::= CHOICE {
      digest        OCTET STRING (SIZE(20)) (ENCODED BY sha-1),
      digestedData  DigestedData
   }

   RSA-PublicKey ::= 
      BIT STRING (CONTAINING RSAPublicKey ENCODED BY rsaEncryption)

as well as

   DNSName ::= 
        VisibleString (SIZE(1..MAX)) (PATTERN "[A-Za-z0-9 .-]*")

And X9.84 uses short (one byte) relative object identifiers to 
indicate well known biometric technologies:

body-Odor           RELATIVE-OID ::= { bodyOdor(1) }
dna                 RELATIVE-OID ::= { dna(2) }
ear-Shape           RELATIVE-OID ::= { earShape(3) }
facial-Features     RELATIVE-OID ::= { facialFeatures(4) }
finger-Image        RELATIVE-OID ::= { fingerImage(5) }
finger-Geometry     RELATIVE-OID ::= { fingerGeometry(6) }
hand-Geometry       RELATIVE-OID ::= { handGeometry(7) }
iris-Features       RELATIVE-OID ::= { irisFeatures(8) }
keystroke-Dynamics  RELATIVE-OID ::= { keystrokeDynamics(9) }
palm                RELATIVE-OID ::= { palm(10) }
retina              RELATIVE-OID ::= { retina(11) }
signature           RELATIVE-OID ::= { signature(12) }
speech-Pattern      RELATIVE-OID ::= { speechPattern(13) }
thermal-Image       RELATIVE-OID ::= { thermalImage(14) }
vein-Pattern        RELATIVE-OID ::= { veinPattern(15) }

So, for example, I can specify that a component of some type
contains a Java applet and my decoder tools can take some
action when the applet is received:

  Applet ::= OCTET STRING (ENCODED BY java-applet)

Or perhaps I can identify the my favorite word processor
or compression format and have my application spawn some 
process to display or archive the data:

  Tar ::= OCTET STRING (ENCODED BY id-tar)

  Zip ::= OCTET STRING (ENCODED BY gZIP)

  Word95 ::= OCTET STRING (ENCODED BY id-word)

Or perhaps I need to sign some XML without regard to 
whether it is well formed or not, relies on relative
URIs, or has white space issues, relies on RELAX or
some yet undefined schema:

  XML-Document ::= 
    OCTET STRING (CONTAINING UTF8String ENCODED BY xml)

Here, the 'value' portion (ala TLV) of the OCTET STRING
contains the complete encoding of a value of type
UTF8String, which itself is identified as an XML
document. This can be easily signed using CMS just
like any other piece of "data"content. But it can 
also be picked out of an ASN.1 message by clever tools
and processed by a receiving application.

Identification of these types of document entities is 
currently underway in a revised version of X9.45 that
should be ready for review and discussion at next 
months X9F1 meeting.

> has to be signalled by the content type (IMHO).
> 
> Regards,
> Rich
> 
> -----Original Message-----
> From: ChungKil Kim <[e-mail]>
> To: [e-mail] <[e-mail]>
> Date: Monday, September 18, 2000 10:41 PM
> Subject: Q: Is possible indefinite form of length encoding in DER?
> 
> >In some S/MIME messages, there are indefinite form of length encoding.
> >Is it possible?
> >
> >In PKCS specs, only use DER?
> >

-- 
Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
[phone]         1625 Glenwood Avenue, Five Points
[phone] [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24740; Tue, 19 Sep 2000 07:39:57 -0700 (PDT)
Received: by balinese.baltimore.ie; id PAA11985; Tue, 19 Sep 2000 15:42:37 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma011799; Tue, 19 Sep 00 15:41:58 +0100
Received: from ocelot.ie.baltimore.com (IDENT:root@ocelot [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA26305; Tue, 19 Sep 2000 15:41:57 +0100
Received: from ocelot.ie.baltimore.com (afarrell@localhost [127.0.0.1]) by ocelot.ie.baltimore.com (8.8.7/8.8.7) with ESMTP id PAA12950; Tue, 19 Sep 2000 15:41:56 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Q: Is possible indefinite form of length encoding in DER? 
In-Reply-To: Your message of "Tue, 19 Sep 2000 11:39:46 +0900." <[e-mail]> 
Date: Tue, 19 Sep 2000 15:41:56 +0100
From: Andrew Farrell <[e-mail]>

ChungKil Kim <[e-mail]> wrote:

>In some S/MIME messages, there are indefinite form of length encoding.
>Is it possible?

>In PKCS specs, only use DER?

An important thing to remember is that although it's often specified
that a signature must be over the DER encoding of an object, it's not
necessarily true that what is transmitted has to be that encoding.

On the ridiculous end of this rule is a certificate in which everything
is indefinite length encoded - perfectly valid AFAIK, as long as you
re-encode before verifying.

On the more practical end, it is often impossible to know when composing
a PKCS#7 SignedData how long the data being signed is. As a result all
the layers surrounding the Content (ContentInfo, SignedData,
EncapsulatedContentInfo) are encoded indefinite length, and the content
itself is encoded as a contructed octet string. The signature is over
the contents octets of the DER encoding, and so it is never necessary
even to count the length of the assembled octetstring. The individual
strings are simply fed to the digests as they appear.

Andrew


Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23864 for <[e-mail]>; Tue, 19 Sep 2000 07:14:55 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA162132; Tue, 19 Sep 2000 10:17:19 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id KAA83824; Tue, 19 Sep 2000 10:17:35 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525695F.004E7E99 ; Tue, 19 Sep 2000 10:17:22 -0400
X-Lotus-FromDomain: IBMUS
To: "Rich Ankney" <[e-mail]>
cc: "Aram Perez" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 19 Sep 2000 10:17:24 -0400
Subject: Re: Is possible indefinite form of length encoding in DER?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     You're right, of course.  Constructed octet strings, like constructed
character strings and constructed bit strings, are legal in BER but not in
DER.  The same is true of indefinite lengths (length octet of 0x80 with a
matching EOC consisting of two zero octets at the end).

          Tom Gindin

"Rich Ankney" <[e-mail]> on 09/19/2000 10:00:31 AM

To:   "Aram Perez" <[e-mail]>, <[e-mail]>
cc:
Subject:  Re: Is possible indefinite form of length encoding in DER?



I don't think you can use constructed OCTET STRINGs in DER,
though. I'll try to unearth the 1994 standard today and verify this.
Or no doubt Phil Griffin is lurking on the list and can answer this
off the top of his head:-)

Regards,
Rich

-----Original Message-----
From: Aram Perez <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Monday, September 18, 2000 11:20 PM
Subject: Re: Is possible indefinite form of length encoding in DER?


>Hi Rich and ChungKil,
>
>It's my understanding that for OCTET STRING you can use a constructed
OCTET
>STRING, which when you decode appears as one OCTET STRING. I used to have
an
>example file but I don't know where it is.
>
>Regards,
>Aram Perez
>
>> From: Rich Ankney <[e-mail]>
>> Date: Mon, 18 Sep 2000 23:01:36 -0400
>> To: ChungKil Kim <[e-mail]>, [e-mail]
>> Subject: Re: Is possible indefinite form of length encoding in DER?
>>
>> I think all of the RFC 2630 stuff needs to be DER.  It's not clear at
all
>> what you can do about some ASN.1 wrapped in the eContent OCTET
>> STRING though.  If that were ASN.1 (wrapped in an OS) there's no
>> way to signal how it's encoded (although this sort of thing is a topic
>> in the new version of ASN.1).  Theoretically it could be anything but it
>> has to be signalled by the content type (IMHO).
>>
>> Regards,
>> Rich
>>
>> -----Original Message-----
>> From: ChungKil Kim <[e-mail]>
>> To: [e-mail] <[e-mail]>
>> Date: Monday, September 18, 2000 10:41 PM
>> Subject: Q: Is possible indefinite form of length encoding in DER?
>>
>>
>>> In some S/MIME messages, there are indefinite form of length encoding.
>>> Is it possible?
>>>
>>> In PKCS specs, only use DER?
>>>
>>
>
>






Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23488 for <[e-mail]>; Tue, 19 Sep 2000 07:07:31 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA27942; Tue, 19 Sep 2000 10:10:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220805b5ed22bb30ff@[171.78.30.107]>
In-Reply-To: <004101c02217$2a4a79d0$[e-mail]>
References: <004101c02217$2a4a79d0$[e-mail]>
Date: Tue, 19 Sep 2000 10:05:58 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

In conducting debates on mailing lists one sometimes has to decide 
that further exchanges are not productive, wasting one's own time as 
well as that of the WG members. This appears to be one of those 
cases. I'm sure you'll understand why I will no longer respond to 
your messages.

Steve


Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23042 for <[e-mail]>; Tue, 19 Sep 2000 06:56:14 -0700 (PDT)
Received: from 216-164-128-142.s142.tnt1.lnhva.md.dialup.rcn.com ([216.164.128.142] helo=rankney) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13bNvD-0005Eq-00; Tue, 19 Sep 2000 09:58:55 -0400
Message-ID: <000f01c02241$fbe3c1c0$8e80a4d8@rankney>
From: "Rich Ankney" <[e-mail]>
To: "Aram Perez" <[e-mail]>, <[e-mail]>
Subject: Re: Is possible indefinite form of length encoding in DER?
Date: Tue, 19 Sep 2000 10:00:31 -0400
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.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

I don't think you can use constructed OCTET STRINGs in DER,
though. I'll try to unearth the 1994 standard today and verify this.
Or no doubt Phil Griffin is lurking on the list and can answer this
off the top of his head:-)

Regards,
Rich

-----Original Message-----
From: Aram Perez <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Monday, September 18, 2000 11:20 PM
Subject: Re: Is possible indefinite form of length encoding in DER?


>Hi Rich and ChungKil,
>
>It's my understanding that for OCTET STRING you can use a constructed OCTET
>STRING, which when you decode appears as one OCTET STRING. I used to have
an
>example file but I don't know where it is.
>
>Regards,
>Aram Perez
>
>> From: Rich Ankney <[e-mail]>
>> Date: Mon, 18 Sep 2000 23:01:36 -0400
>> To: ChungKil Kim <[e-mail]>, [e-mail]
>> Subject: Re: Is possible indefinite form of length encoding in DER?
>>
>> I think all of the RFC 2630 stuff needs to be DER.  It's not clear at all
>> what you can do about some ASN.1 wrapped in the eContent OCTET
>> STRING though.  If that were ASN.1 (wrapped in an OS) there's no
>> way to signal how it's encoded (although this sort of thing is a topic
>> in the new version of ASN.1).  Theoretically it could be anything but it
>> has to be signalled by the content type (IMHO).
>>
>> Regards,
>> Rich
>>
>> -----Original Message-----
>> From: ChungKil Kim <[e-mail]>
>> To: [e-mail] <[e-mail]>
>> Date: Monday, September 18, 2000 10:41 PM
>> Subject: Q: Is possible indefinite form of length encoding in DER?
>>
>>
>>> In some S/MIME messages, there are indefinite form of length encoding.
>>> Is it possible?
>>>
>>> In PKCS specs, only use DER?
>>>
>>
>
>



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19551 for <[e-mail]>; Tue, 19 Sep 2000 04:57:19 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA10932; Tue, 19 Sep 2000 13:59:10 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 19 Sep 2000 13:59:11 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA25558; Tue, 19 Sep 2000 13:59:09 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA20398; Tue, 19 Sep 2000 13:59:09 +0200 (MET DST)
Date: Tue, 19 Sep 2000 13:59:09 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OCSPv2 and OCSP extensions drafts
Cc: [e-mail]

> Mike:
> 
> This raises a bigger question.  I do not think that PKIX should have more 
> than one way to do remove cert path validation.  There seems to be three 
> approaches on the table.  Which protocol is the right one (OCSP, SCVP, or DCS)?
The name of the last is DVCS. :-)

> 
> Personally, I would rather not spend a lot of time reviewing three 
> different approaches.  Rather, I would like to determine the way we are 
> going, then review the one.  Maybe each of the proponents could summarize 
> how their protocol stacks up against the requirements.  (It might be my 
> memory, but I thought we had a requirements discussion on the list.  It is 
> not in an Internet-Draft).

I read the OCSP draft-ietf-pkix-ocsp-valid-00.txt and would like to
compare this with what is the corresponding part in DVCS. 

Unless I have misunderstood something, besides the different encoding
of requests and responses, the essential data elements to be compared in a
draft-ietf-pkix-ocsp-valid-00.txt requests and responses are: 

ReqCert  ::= CHOICE {
     certID            CertID,
     issuerSerial      [0] IssuerandSerialNumber,
     pKCert            [1] Certificate,
     name              [2] GeneralName }

and 

DPVOptions  :: = SEQUENCE{
    initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, 
    trustPoints       SEQUENCE OF ReqCert OPTIONAL } 

The corresponding data structures in DVCS    

   TargetEtcChain ::= SEQUENCE {
        target                       CertEtcToken,
        chain                        SEQUENCE SIZE (1..MAX) OF
                                        CertEtcToken OPTIONAL,
        pathProcInput                [0] PathProcInput OPTIONAL
   }

   PathProcInput ::= SEQUENCE {
        acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
                                        PolicyInformation,
        inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
        explicitPolicyReqd           BOOLEAN DEFAULT FALSE
   }

   CertEtcToken ::= CHOICE {
        certificate                  [0] IMPLICIT Certificate ,
        esscertid                    [1] ESSCertId ,
        pkistatus                    [2] IMPLICIT PKIStatusInfo ,
        assertion                    [3] ContentInfo ,
        crl                          [4] IMPLICIT CertificateList,
        ocspcertstatus               [5] IMPLICIT CertStatus,
        oscpcertid                   [6] IMPLICIT CertId ,
        oscpresponse                 [7] IMPLICIT OCSPResponse,
        capabilities                 [8] SMIMECapabilities,
        extension                    Extension
   }


The difference in dvcs is that it allows inhibitPolicyMapping, explicitPolicyReqd
That doesn't seem a very big deal, in the ocsp draft this can be easily added
(if considered useful).  

The definition of TargetEtcChain.chain part in DVCS unfortunately says:

     Each certificate to be verified MUST be included in a separate
     instance of TargetEtcChain, and to be verified.  The
     'TargetEtcChain.chain' field, if present, MUST indicate the chain
     of trust to be used when certifying the certificate. 

There are several possibilities: 
One is making several TargetEtcChain, and getting status for ALL the possible trust points.
Another is to modify the text above to give more freedom to the server,
actually the same semantics as in the ocsp extension draft..  

So: 

There is a lot of overlap among the protocols, they can also be regarded
as complementary. 

DVCS allows to return not only a validated path but also all validation information
that come with it, saying basically: 'I think the cert status is X and I have based
my information on that and that information.'  For example there could be an
imbedded ocsp reponse for an intermediate CA.

Peter Sylvester

Is it correct that the other ocsp draft (path) is *already* expired?




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16695 for <[e-mail]>; Tue, 19 Sep 2000 03:34:03 -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 GAA11276; Tue, 19 Sep 2000 06:36:44 -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-ocspv2-00.txt
Date: Tue, 19 Sep 2000 06:36:44 -0400
Sender: [e-mail]

--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		: Online Certificate Status Protocol, version 2
	Author(s)	: M. Myers, R. Ankney, C. Adams
	Filename	: draft-ietf-pkix-ocspv2-00.txt
	Pages		: 20
	Date		: 18-Sep-00
	
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.
An overview of the protocol is provided in section 2. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-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-ocspv2-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-ocspv2-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-ocspv2-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocspv2-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 ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16683 for <[e-mail]>; Tue, 19 Sep 2000 03:33:59 -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 GAA11262; Tue, 19 Sep 2000 06:36:39 -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-ocsp-valid-00.txt
Date: Tue, 19 Sep 2000 06:36:39 -0400
Sender: [e-mail]

--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		: Delegated Path Validation
	Author(s)	: M. Myers, C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-ocsp-valid-00.txt
	Pages		: 3
	Date		: 18-Sep-00
	
OCSP [RFC2560] establishes the Internet standard for online certificate status. The baseline response type defined in [RFC2560] supports acquisition of the revocation state of a certificate.  This specification builds on the OCSP framework's extensibility by defining an Internet-standard extension to OCSP that can be used to fully delegate all path validation processing to an OCSP server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-valid-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-ocsp-valid-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-ocsp-valid-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-ocsp-valid-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocsp-valid-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 d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10248 for <[e-mail]>; Tue, 19 Sep 2000 00:52:34 -0700 (PDT)
Received: from mega (t2o69p24.telia.com [62.20.144.144]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id JAA04739; Tue, 19 Sep 2000 09:55:11 +0200 (CEST)
Message-ID: <004101c02217$2a4a79d0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Date: Tue, 19 Sep 2000 10:54:02 +0200
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 ns.secondary.com id AAA10249

Steve, 

>This has a familiar ring. You often argue for modifying our standards 
>to accommodate some vendor approach, irrespective of architectural 
>merit. 

Why not wake up Warwick that both co-authored 2459 and is employed by
one of these "marginal" vendors that apparently don't care about it?

The E= in Subject *IS* a standard way of putting e-mail addresses in certificates! 
By far the most common solution also... 

To "criminalize" that is far too late.

The recommendation in 2459 has no important architectural merit. If it had, people 
would follow it. Quite simple logic there IMO. It is just a result of 
"historical" problems and 2459 should also say that. I.e. there are *two* EQUALLY
conformant solutions which is admittedly unfortunate but nothing to do about except accepting. 

Note that if VeriSign and Microsoft would change their email support in certificates 
a lot of custom software would probably fail. To change son-of-2459 does not hurt anybody. 

Regarding my "lust" for screwing up standards: 
I don't know exactly know what you refer to except that I have had (and still have) 
a lot of unanswered questions regarding QCs. Which is still in draft. 

I do know that I complained about the sudden deprecation of dnQualifier in the 
Subject field and was referring to existing *known* deployment of that while the s.c. 
conformant usage (that very few understood) is probably not used by anybody. 
Again: Too late to be changed without creating problems. REAL problems.

>That's not how the IETF pursues standards. That's why TLS is 
>not backwards compatible with SSL, for example.

No, but TLS is *upward* compatible with SSL which is about all you can 
require (in some cases) when you introduce enhanced standards. 

Anders




Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA09331 for <[e-mail]>; Tue, 19 Sep 2000 00:14:09 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA49052; Tue, 19 Sep 2000 09:21:40 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA20378; Tue, 19 Sep 2000 09:16:12 +0200
Message-ID: <[e-mail]>
Date: Tue, 19 Sep 2000 09:16:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Fw: The need for two grades of time data.
References: <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002201c021cd$09a42ae0$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Todd,

> Stephen I understand how to solve part of this problem, it is my intent to
> submit an API Specification for the use of the already existing NTP AutoKey
> to this group for TSP Uses.

APIs is usually not a task performed by the IETF; it is only
performed by exception. The GSS-APIs fall under that exception. 

NTP is not part of the charter of this group, so this kind of topic
cannot be dealt in the PKIX WG, unless the charter is changed. 

> The draft will be in as an I-D within 14-17 days. 

You can certainly post such a draft, but as an individual draft, not
as a PKIX draft.

> Anyone that would like to
> collaborate on this please contact me immediately. We will in this draft
> also show the use of the TSP API on top of NTP to address the evidentiary
> problems that the TSA does not address as well as a number of other protocol
> interfaces like one to generate TST's for IOTP and XML uses.
> 
> I personally would suggest holding the standard until then and reviewing it.

This is unrelated, so your "suggestion" is not relevant.

Denis


> Two weeks does not push the time frame out too far to delay any decision on
> the TSP Draft and advancing it over something as heavily deployed as the
> Network Time Protocol.
> 
> Todd
> 
> ----- Original Message -----
> From: "Stephen Kent" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, September 18, 2000 12:15 PM
> Subject: Re: Fw: The need for two grades of time data.
> 
> > Todd,
> >
> > We have no other PKI-oriented time stamping standards on the table. I
> > don't think we can answer that question in the abstract.
> >
> > Any candidate would have to be technically sound, not encumbered by
> > any IP [certainly no more than we already have :-)], consistent with
> > our PKI models, and be accompanied by a well written description.
> >
> > Nothing that has been submitted to this list has met these criteria.
> >
> > Steve
> >


Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA04942 for <[e-mail]>; Mon, 18 Sep 2000 21:11:48 -0700 (PDT)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id e8J4BBj08271 for <[e-mail]>; Tue, 19 Sep 2000 13:11:11 +0900 (KST)
From: "Kwon, YongChul" <[e-mail]>
To: "PKIX Working Group" <[e-mail]>
Subject: RE: Is possible indefinite form of length encoding in DER?
Date: Tue, 19 Sep 2000 13:12:26 +0900
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal

> Hi Rich and ChungKil,
> 
> It's my understanding that for OCTET STRING you can use a 
> constructed OCTET
> STRING, which when you decode appears as one OCTET STRING. I used 
> to have an
> example file but I don't know where it is.

	following X.690, constructed encoding is not permitted for bit string,
	octetstring and restricted character string types in DER encoding.

	octetstring can be constructed only if it is tagged with EXPLICIT in DER.



Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA03921 for <[e-mail]>; Mon, 18 Sep 2000 20:17:15 -0700 (PDT)
Received: from [192.168.1.40] ([208.233.228.110]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <[e-mail]> for [e-mail]; Mon, 18 Sep 2000 20:16:28 -0700 (PDT)
Date: Mon, 18 Sep 2000 20:17:18 -0700
From: Aram Perez <[e-mail]>
Subject: Re: Is possible indefinite form of length encoding in DER?
In-reply-to: <000f01c021e5$ef117520$7888a4d8@rankney>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

Hi Rich and ChungKil,

It's my understanding that for OCTET STRING you can use a constructed OCTET
STRING, which when you decode appears as one OCTET STRING. I used to have an
example file but I don't know where it is.

Regards,
Aram Perez

> From: Rich Ankney <[e-mail]>
> Date: Mon, 18 Sep 2000 23:01:36 -0400
> To: ChungKil Kim <[e-mail]>, [e-mail]
> Subject: Re: Is possible indefinite form of length encoding in DER?
> 
> I think all of the RFC 2630 stuff needs to be DER.  It's not clear at all
> what you can do about some ASN.1 wrapped in the eContent OCTET
> STRING though.  If that were ASN.1 (wrapped in an OS) there's no
> way to signal how it's encoded (although this sort of thing is a topic
> in the new version of ASN.1).  Theoretically it could be anything but it
> has to be signalled by the content type (IMHO).
> 
> Regards,
> Rich
> 
> -----Original Message-----
> From: ChungKil Kim <[e-mail]>
> To: [e-mail] <[e-mail]>
> Date: Monday, September 18, 2000 10:41 PM
> Subject: Q: Is possible indefinite form of length encoding in DER?
> 
> 
>> In some S/MIME messages, there are indefinite form of length encoding.
>> Is it possible?
>> 
>> In PKCS specs, only use DER?
>> 
> 



Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA03407 for <[e-mail]>; Mon, 18 Sep 2000 19:59:23 -0700 (PDT)
Received: from 216-164-136-120.s120.tnt4.lnhva.md.dialup.rcn.com ([216.164.136.120] helo=rankney) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13bDfW-0007Zz-00; Mon, 18 Sep 2000 23:02:03 -0400
Message-ID: <001901c021e6$365f8c00$7888a4d8@rankney>
From: "Rich Ankney" <[e-mail]>
To: "ChungKil Kim" <[e-mail]>, <[e-mail]>
Subject: Re: Is possible indefinite form of length encoding in DER?
Date: Mon, 18 Sep 2000 23:03:36 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="EUC-KR"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

To follow up, I suppose it could be one of those funky things that
most ASN.1 compilers don't handle well, like an EMBEDDED PDV
(which can signal encoding rules).

Regards,
Rich

-----Original Message-----
From: ChungKil Kim <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Monday, September 18, 2000 10:41 PM
Subject: Q: Is possible indefinite form of length encoding in DER?


>In some S/MIME messages, there are indefinite form of length encoding.
>Is it possible?
>
>In PKCS specs, only use DER?
>



Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA03187 for <[e-mail]>; Mon, 18 Sep 2000 19:57:24 -0700 (PDT)
Received: from 216-164-136-120.s120.tnt4.lnhva.md.dialup.rcn.com ([216.164.136.120] helo=rankney) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13bDdb-0007Hx-00; Mon, 18 Sep 2000 23:00:03 -0400
Message-ID: <000f01c021e5$ef117520$7888a4d8@rankney>
From: "Rich Ankney" <[e-mail]>
To: "ChungKil Kim" <[e-mail]>, <[e-mail]>
Subject: Re: Is possible indefinite form of length encoding in DER?
Date: Mon, 18 Sep 2000 23:01:36 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="EUC-KR"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

I think all of the RFC 2630 stuff needs to be DER.  It's not clear at all
what you can do about some ASN.1 wrapped in the eContent OCTET
STRING though.  If that were ASN.1 (wrapped in an OS) there's no
way to signal how it's encoded (although this sort of thing is a topic
in the new version of ASN.1).  Theoretically it could be anything but it
has to be signalled by the content type (IMHO).

Regards,
Rich

-----Original Message-----
From: ChungKil Kim <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Monday, September 18, 2000 10:41 PM
Subject: Q: Is possible indefinite form of length encoding in DER?


>In some S/MIME messages, there are indefinite form of length encoding.
>Is it possible?
>
>In PKCS specs, only use DER?
>



Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA02725 for <[e-mail]>; Mon, 18 Sep 2000 19:37:38 -0700 (PDT)
Received: from initech.com ([203.238.37.143]) by venus.initech.com (8.11.0/8.11.0) with ESMTP id e8J2b1j07262 for <[e-mail]>; Tue, 19 Sep 2000 11:37:01 +0900 (KST)
Message-ID: <[e-mail]>
Date: Tue, 19 Sep 2000 11:39:46 +0900
From: ChungKil Kim <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: ko,en
MIME-Version: 1.0
To: [e-mail]
Subject: Q: Is possible indefinite form of length encoding in DER?
Content-Type: multipart/mixed; boundary="------------C751703D52D3852167AC3217"

This is a multi-part message in MIME format.
--------------C751703D52D3852167AC3217
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit

In some S/MIME messages, there are indefinite form of length encoding.
Is it possible?

In PKCS specs, only use DER?

--------------C751703D52D3852167AC3217
Content-Type: text/x-vcard; charset=EUC-KR;
 name="chkim.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for ChungKil Kim
Content-Disposition: attachment;
 filename="chkim.vcf"

begin:vcard 
n:Kim;ChungKil
tel;cell:016-830-7406
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:INITECH Co., Ltd.;Research Institute
version:2.1
email;internet:[e-mail]
title:Researcher
adr;quoted-printable:;;KWANG-SUNG B/D 8F=0D=0A831-47 YOKSAM-DONG,=0D=0AKANGNAM-KU;SEOUL;;135-080;KOREA
fn:ChungKil Kim
end:vcard

--------------C751703D52D3852167AC3217--



Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29240 for <[e-mail]>; Mon, 18 Sep 2000 17:01:27 -0700 (PDT)
Received: from tsg1 ([12.72.112.232]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000919000335.ZXVB8992.mtiwmhc26.worldnet.att.net@tsg1>; Tue, 19 Sep 2000 00:03:35 +0000
Message-ID: <002201c021cd$09a42ae0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]>
Subject: Re: Fw: The need for two grades of time data.
Date: Mon, 18 Sep 2000 17:03:18 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Stephen I understand how to solve part of this problem, it is my intent to
submit an API Specification for the use of the already existing NTP AutoKey
to this group for TSP Uses.

The draft will be in as an I-D within 14-17 days. Anyone that would like to
collaborate on this please contact me immediately. We will in this draft
also show the use of the TSP API on top of NTP to address the evidentiary
problems that the TSA does not address as well as a number of other protocol
interfaces like one to generate TST's for IOTP and XML uses.

I personally would suggest holding the standard until then and reviewing it.
Two weeks does not push the time frame out too far to delay any decision on
the TSP Draft and advancing it over something as heavily deployed as the
Network Time Protocol.

Todd



----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 18, 2000 12:15 PM
Subject: Re: Fw: The need for two grades of time data.


> Todd,
>
> We have no other PKI-oriented time stamping standards on the table. I
> don't think we can answer that question in the abstract.
>
> Any candidate would have to be technically sound, not encumbered by
> any IP [certainly no more than we already have :-)], consistent with
> our PKI models, and be accompanied by a well written description.
>
> Nothing that has been submitted to this list has met these criteria.
>
> Steve
>



Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29156 for <[e-mail]>; Mon, 18 Sep 2000 17:01:00 -0700 (PDT)
Received: from tsg1 ([12.72.112.232]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000919000308.ZXQM8992.mtiwmhc26.worldnet.att.net@tsg1>; Tue, 19 Sep 2000 00:03:08 +0000
Message-ID: <002101c021cc$f9664cd0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Tony Bartoletti" <[e-mail]>
Cc: <[e-mail]>
References: <002701c021b7$3a5b07f0$020aff0c@tsg1><003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107 ]><012e01c021a2$3aa00cc0$020aff0c@tsg1><v0422080eb5ec195cd7b0@[171.78.30.107]><002701c021b7$3a5b07f0$020aff0c@tsg1> <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Date: Mon, 18 Sep 2000 16:57:42 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

THANKS  Tony I agree.
----- Original Message -----
From: "Tony Bartoletti" <[e-mail]>
To: "Stephen Kent" <[e-mail]>; "todd glassey"
<[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 18, 2000 4:02 PM
Subject: Re: Fw: The need for two grades of time data.


>
>    "Objection, Your Honor!  Calls for speculation."  :)
>
> I feel like I'm watching a techno-geek courtroom drama.
>
> Is there really any objection to the (hypothetical) statement:
> "The PKIX WG Chairs would support a non-TTP TSP standard if it
> met conditions X, Y, and Z (to be disclosed only under duress.)"
>
> Seriously, is it fundamentally IP issues, or "non-TTP model"
> issues, or "there can be only one TSP standard" issues, or
> something else that is objectionable "on principle alone".
>
> This is important, as much wasted effort could be avoided by
> knowing in advance the substantial objections.
>
> Curious.
>
> ___tony___
>
>
> At 05:41 PM 9/18/00 -0400, Stephen Kent wrote:
> >Todd,
> >
> >>Steve - I'm sorry - maybe I was not clear enough in what I asked. I
wasn't
> >>speaking to the actual but to the theoretical. The question is not has
> >>anyone submitted it already, but rather will the WG Chairs support their
> >>being more than one standard.
> >
> >My response reflects the fact that I would not commit to the viability of
> >another standard until we hand an example in hand.
> >
> >Steve
> >
>
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
>



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA28517 for <[e-mail]>; Mon, 18 Sep 2000 16:34:43 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id QAA10042; Mon, 18 Sep 2000 16:36:43 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 18 Sep 2000 16:47:46 -0700
To: Stephen Kent <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
In-Reply-To: <v04220820b5ec4eb660a5@[171.78.30.107]>
References: <[e-mail]> <002701c021b7$3a5b07f0$020aff0c@tsg1> <003701c0217c$18af0b00$020aff0c@tsg1> <v04220801b5ebe1d3cb63@[171.78.30.107 ]> <012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002701c021b7$3a5b07f0$020aff0c@tsg1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 07:05 PM 9/18/00 -0400, Stephen Kent wrote:

>>Seriously, is it fundamentally IP issues, or "non-TTP model"
>>issues, or "there can be only one TSP standard" issues, or
>>something else that is objectionable "on principle alone".
>
>It's not "non-TTP model" and it is IP concerns. But we also don't need to 
>endorse equivalent ways of doing the same thing, since that degrades 
>interoperability, or imposes extra burdens on implementors. We've having 
>that debate no with regard to delegated path processing, validation, 
>etc.  I don't want to limit the reasons I might object to another TSP 
>proposal to the set that are immediately obvious: there may be innumerable 
>examples of other bad TSP model one could devise :-)

The latter seems then to fall under "something else that is objectionable 
on principle." :)

The central (non-IP) issue is then the validity of the phrase
"equivalent ways of doing the same thing".  Certainly, there is
no need or desire to really do the same thing in different but
equivalent ways ... so ...

1.  Are these "the same thing"?  Todd argues that "time as control parameter"
and "time as evidentiary content" are in principle different things, and that
this is not just a matter of degree but a matter of kind.  If these are really
not different (equivalently, not needed), then the story ends quickly.

2.  Are the assurance procedures really "equivalent ways"?  If there is truth
to the distinction regarding "time, the evidence", and a reason to believe
that it may be a quantity "in demand", then one must examine if it deserves
other than the TTP-treatment for assurance.

(Indeed, an attempt to rely upon a TTP model seems to introduce an endless
regress of stamps and assurances.  At a minimum, it has a multiplying effect
on "things to be assured about.")

Perhaps by sticking to the core "is it really different/needed" examinations,
one can progress to a resolution without the allusions to ulterior motives
that often surface (Mea Culpa!)

___tony___


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27819 for <[e-mail]>; Mon, 18 Sep 2000 16:00:57 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA02657; Mon, 18 Sep 2000 19:03:34 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220820b5ec4eb660a5@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <002701c021b7$3a5b07f0$020aff0c@tsg1> <003701c0217c$18af0b00$020aff0c@tsg1> <v04220801b5ebe1d3cb63@[171.78.30.107 ]> <012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002701c021b7$3a5b07f0$020aff0c@tsg1> <[e-mail]>
Date: Mon, 18 Sep 2000 19:05:16 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Tony,

>   "Objection, Your Honor!  Calls for speculation."  :)
>
>I feel like I'm watching a techno-geek courtroom drama.
>
>Is there really any objection to the (hypothetical) statement:
>"The PKIX WG Chairs would support a non-TTP TSP standard if it
>met conditions X, Y, and Z (to be disclosed only under duress.)"
>
>Seriously, is it fundamentally IP issues, or "non-TTP model"
>issues, or "there can be only one TSP standard" issues, or
>something else that is objectionable "on principle alone".

It's not "non-TTP model" and it is IP concerns. But we also don't 
need to endorse equivalent ways of doing the same thing, since that 
degrades interoperability, or imposes extra burdens on implementors. 
We've having that debate no with regard to delegated path processing, 
validation, etc.  I don't want to limit the reasons I might object to 
another TSP proposal to the set that are immediately obvious: there 
may be innumerable examples of other bad TSP model one could devise 
:-)

>This is important, as much wasted effort could be avoided by
>knowing in advance the substantial objections.

Another way to think of this issue is that there had better be a 
very, very good reason to introduce another means of achieving the 
same effect, or it is a waste of everyone's time.  This is generally 
a good basis for such decisions.

Steve



Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27411 for <[e-mail]>; Mon, 18 Sep 2000 15:49:44 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id PAA15513; Mon, 18 Sep 2000 15:51:37 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 18 Sep 2000 16:02:40 -0700
To: Stephen Kent <[e-mail]>, "todd glassey" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
In-Reply-To: <v0422081cb5ec3c5d1106@[171.78.30.107]>
References: <002701c021b7$3a5b07f0$020aff0c@tsg1> <003701c0217c$18af0b00$020aff0c@tsg1> <v04220801b5ebe1d3cb63@[171.78.30.107 ]> <012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002701c021b7$3a5b07f0$020aff0c@tsg1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

   "Objection, Your Honor!  Calls for speculation."  :)

I feel like I'm watching a techno-geek courtroom drama.

Is there really any objection to the (hypothetical) statement:
"The PKIX WG Chairs would support a non-TTP TSP standard if it
met conditions X, Y, and Z (to be disclosed only under duress.)"

Seriously, is it fundamentally IP issues, or "non-TTP model"
issues, or "there can be only one TSP standard" issues, or
something else that is objectionable "on principle alone".

This is important, as much wasted effort could be avoided by
knowing in advance the substantial objections.

Curious.

___tony___


At 05:41 PM 9/18/00 -0400, Stephen Kent wrote:
>Todd,
>
>>Steve - I'm sorry - maybe I was not clear enough in what I asked. I wasn't
>>speaking to the actual but to the theoretical. The question is not has
>>anyone submitted it already, but rather will the WG Chairs support their
>>being more than one standard.
>
>My response reflects the fact that I would not commit to the viability of 
>another standard until we hand an example in hand.
>
>Steve
>

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26102 for <[e-mail]>; Mon, 18 Sep 2000 14:43:07 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA26839; Mon, 18 Sep 2000 17:45:34 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422081cb5ec3c5d1106@[171.78.30.107]>
In-Reply-To: <002701c021b7$3a5b07f0$020aff0c@tsg1>
References:  <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107 ]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]> <002701c021b7$3a5b07f0$020aff0c@tsg1>
Date: Mon, 18 Sep 2000 17:41:56 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Steve - I'm sorry - maybe I was not clear enough in what I asked. I wasn't
>speaking to the actual but to the theoretical. The question is not has
>anyone submitted it already, but rather will the WG Chairs support their
>being more than one standard.

My response reflects the fact that I would not commit to the 
viability of another standard until we hand an example in hand.

Steve



Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25420 for <[e-mail]>; Mon, 18 Sep 2000 14:25:35 -0700 (PDT)
Received: from tsg1 ([12.72.112.232]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000918212742.XHGP8992.mtiwmhc26.worldnet.att.net@tsg1>; Mon, 18 Sep 2000 21:27:42 +0000
Message-ID: <002801c021b7$43320fe0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1><[e-mail]><03a101c01dd0$52afa620$020aff0c@tsg1><v0422080ab5e6c934afc6@[171.78.30.107]><062701c01e8c$de010f40$020aff0c@tsg1> <v04220807b5e7eab51090@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Mon, 18 Sep 2000 14:27: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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

> Todd,
>
> >Stephen,
> >One simple and elegant solution would be to change the name from "The
PKIX
> >Time Stamping Protocol" to "The PKIX TTP Time Stamping Protocol", and
allow
> >other TS protocols that are not TTP in nature to progress as well.
>
> We can consider this change, if there is adequate support for it.
>

Thanks Stephen - Hi all. I would like to amend the name of the Current TSP
Draft now queued for Draft Standard Status to indicate that the TSP Method
only works as a TTP. Does anyone have a problem with this, and if so could
you ring me up to speed on it?

Todd



Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25381 for <[e-mail]>; Mon, 18 Sep 2000 14:25:20 -0700 (PDT)
Received: from tsg1 ([12.72.112.232]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000918212728.XGYJ8992.mtiwmhc26.worldnet.att.net@tsg1>; Mon, 18 Sep 2000 21:27:28 +0000
Message-ID: <002701c021b7$3a5b07f0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <003701c0217c$18af0b00$020aff0c@tsg1><v04220801b5ebe1d3cb63@[171.78.30.107]><012e01c021a2$3aa00cc0$020aff0c@tsg1> <v0422080eb5ec195cd7b0@[171.78.30.107]>
Subject: Re: Fw: The need for two grades of time data.
Date: Mon, 18 Sep 2000 14:20:32 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Steve - I'm sorry - maybe I was not clear enough in what I asked. I wasn't
speaking to the actual but to the theoretical. The question is not has
anyone submitted it already, but rather will the WG Chairs support their
being more than one standard.

Todd

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 18, 2000 12:15 PM
Subject: Re: Fw: The need for two grades of time data.


> Todd,
>
> We have no other PKI-oriented time stamping standards on the table. I
> don't think we can answer that question in the abstract.
>
> Any candidate would have to be technically sound, not encumbered by
> any IP [certainly no more than we already have :-)], consistent with
> our PKI models, and be accompanied by a well written description.
>
> Nothing that has been submitted to this list has met these criteria.
>
> Steve
>



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22814 for <[e-mail]>; Mon, 18 Sep 2000 12:13:25 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA06387; Mon, 18 Sep 2000 15:15:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080eb5ec195cd7b0@[171.78.30.107]>
In-Reply-To: <012e01c021a2$3aa00cc0$020aff0c@tsg1>
References: <003701c0217c$18af0b00$020aff0c@tsg1> <v04220801b5ebe1d3cb63@[171.78.30.107]> <012e01c021a2$3aa00cc0$020aff0c@tsg1>
Date: Mon, 18 Sep 2000 15:15:26 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

We have no other PKI-oriented time stamping standards on the table. I 
don't think we can answer that question in the abstract.

Any candidate would have to be technically sound, not encumbered by 
any IP [certainly no more than we already have :-)], consistent with 
our PKI models, and be accompanied by a well written description.

Nothing that has been submitted to this list has met these criteria.

Steve


Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22233 for <[e-mail]>; Mon, 18 Sep 2000 11:55:05 -0700 (PDT)
Received: from tsg1 ([12.72.112.232]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000918185708.URUW8992.mtiwmhc26.worldnet.att.net@tsg1>; Mon, 18 Sep 2000 18:57:08 +0000
Message-ID: <012e01c021a2$3aa00cc0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <003701c0217c$18af0b00$020aff0c@tsg1> <v04220801b5ebe1d3cb63@[171.78.30.107]>
Subject: Re: Fw: The need for two grades of time data.
Date: Mon, 18 Sep 2000 11:56:57 -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.3018.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.3018.1300

My concern then Stephen is that this is to become the ONLY PKIX TSP.  Is
PKIX open to advancing other standards that might do this as well?

Todd
----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 18, 2000 8:15 AM
Subject: Re: Fw: The need for two grades of time data.


> Todd,
>
> I don't think the name needs to be changed, but I think the intro
> should contain  text that notes the TTP context in which TSP operates.
>
> Steve
>




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21990 for <[e-mail]>; Mon, 18 Sep 2000 11:52:30 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA03213; Mon, 18 Sep 2000 14:55:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220807b5e7eab51090@[171.78.30.107]>
In-Reply-To: <062701c01e8c$de010f40$020aff0c@tsg1>
References:  <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107 ]><006d01c01d1e$a8403b20$020aff0c@tsg1> <[e-mail]><03a101c01dd0$52afa620$020aff0c@tsg1> <v0422080ab5e6c934afc6@[171.78.30.107]> <062701c01e8c$de010f40$020aff0c@tsg1>
Date: Mon, 18 Sep 2000 14:56:48 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Stephen,
>One simple and elegant solution would be to change the name from "The PKIX
>Time Stamping Protocol" to "The PKIX TTP Time Stamping Protocol", and allow
>other TS protocols that are not TTP in nature to progress as well.

We can consider this change, if there is adequate support for it.

>
>By the way, If the response is no because we only need one TTP protocol the
>TSP protocol itself violates that rule. NTP has offered its uses timestamps
>and many people have used the NTP protocol for timestamping for years. What
>this means is that are production systems relying on discreet NTP TST's for
>their validation and this has been going on for at least 8 years that I am
>aware of.

NTP does not provide secure time stamps in the sense we're talking 
about.  The latest NTP document from Dave Mills is clear about the 
security services it tries to offer, and the goal is not NR.  My 
reading suggests that digital signatures are employed in his protocol 
only hourly, to authenticate values that, in turn, are used to 
provide quick authentication of individual time values. Each 
individual time value is protected by a MAC computed using a sequence 
of keys that are part of a hash sequence, analogous to s-key.

>And now that the old-hat NTP 3.x symmetric crypto has given way to the PKI
>based AutoKey, as in the additions recently filed by Dave Mills against his
>NTP 4,0 Standard, the facility offered by the generic NTP 4.0 PKI Server
>does most if not all of what the TSP wants to do and it authenticates the
>time source. Oh and the real win is that there are already tens of millions
>of NTP instances deployed out there and whether the PKIX group likes it or
>not its the way it is. So Unicast Timestamping with NTP is something that
>has been available for years but in a somewhat undocumented state.

Your use of the term "timestamping" here is not consistent with the 
NR-supportive use that we're debating. It is not equivalent. Perhaps 
what you mean is that one can develop another approach to time 
stamping using authenticated NTP as a basis. That option is available 
to TSAs.

>My point is that there is already one fully entrenched TS enable protocol
>that has successfully had global deployment accomplished for it.
>
>PKIX might want to take that into account.  The concept that by rolling the
>rev levels of NTP in every Cisco Router magically becoming a timestamper
>capable of legally binding marques.. seems to me to be the real win for
>timestamping.

Given the security management typically afforded to routers, this is 
indeed a comforting thought :-).

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21458 for <[e-mail]>; Mon, 18 Sep 2000 11:33:27 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA00287; Mon, 18 Sep 2000 14:36:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220809b5ec0ee66289@[171.78.30.107]>
In-Reply-To: <001601c0219d$ca392a60$[e-mail]>
References: <001601c0219d$ca392a60$[e-mail]>
Date: Mon, 18 Sep 2000 14:28:56 -0400
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Anders,

This has a familiar ring. You often argue for modifying our standards 
to accommodate some vendor approach, irrespective of architectural 
merit.  That's not how the IETF pursues standards.  That's why TLS is 
not backwards compatible with SSL, for example.

Steve


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21264 for <[e-mail]>; Mon, 18 Sep 2000 11:32:12 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA10651; Mon, 18 Sep 2000 11:33:42 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 18 Sep 2000 11:33:59 -0400
To: Michael Myers <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: OCSPv2 and OCSP extensions drafts
Cc: [e-mail]
In-Reply-To: <[e-mail] n.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Mike:

This raises a bigger question.  I do not think that PKIX should have more 
than one way to do remove cert path validation.  There seems to be three 
approaches on the table.  Which protocol is the right one (OCSP, SCVP, or DCS)?

Personally, I would rather not spend a lot of time reviewing three 
different approaches.  Rather, I would like to determine the way we are 
going, then review the one.  Maybe each of the proponents could summarize 
how their protocol stacks up against the requirements.  (It might be my 
memory, but I thought we had a requirements discussion on the list.  It is 
not in an Internet-Draft).

Russ

At 06:06 PM 09/15/2000 -0700, Michael Myers wrote:
>All,
>
>Ealier today I sent to IETF three OCSP-related drafts as followup to our
>Pittsburg meeting, developed in collaboration with Carlisle Adams and
>Stephen Farrell.  I trust these drafts will soon be available for your
>consideration.  If you wish a more immediate copy, please let me know
>directly.
>
>Two of these drafts propose Internet standard extensions to OCSP.  These are
>Delegated Path Validation (DPV) and Delegated Path Discovery (DPD).  The DPV
>extension enables offloading of certificate path processing to an OCSP
>server while the DPD extension enables acquisition of the PKI data an OCSP
>server would otherwise use in meeting the DPV requirements.
>
>The third draft is OCSPv2.  This is the "2560bis" work I referred to
>earlier.  It proposes to extend the existing certID structure to more fully
>enable the use of OCSP in wireless and other contexts.  The v2 proposal
>interoperably subsumes RFC 2560.  There is no technical linkage between the
>v2 proposal and the DPV and DPD drafts.  The latter two are specifically
>defined to enable their application to existing OCSP implementations.
>
>Mike



Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19904 for <[e-mail]>; Mon, 18 Sep 2000 10:24:44 -0700 (PDT)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id e8IHKWS13998 for <[e-mail]>; Mon, 18 Sep 2000 10:20:33 -0700 (PDT)
Received: from netscape.com ([192.18.121.215]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id G13F4Q02.U0V; Mon, 18 Sep 2000 10:26:50 -0700 
Message-ID: <[e-mail]>
Date: Mon, 18 Sep 2000 10:26:49 -0700
From: [e-mail] (Terry Hayes)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Anders Rundgren <[e-mail]>, [e-mail]
Subject: Re: 2459 disapproved by MSFT and VeriSign?
References: <OFA723901B.187EA080-ONC125695E.00568B85@LocalDomain>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC64009C92BF65F7FD0E7BAAE"

This is a cryptographically signed message in MIME format.

--------------msC64009C92BF65F7FD0E7BAAE
Content-Type: multipart/alternative;
 boundary="------------F52457833C0AB5669E21CA79"


--------------F52457833C0AB5669E21CA79
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

[e-mail] wrote:

> As far as I know at least Microsoft interprets rfc822Name in
> subjectAltName if present. Maybe to encode both EmailAdress and
> subjectAltName in general is the right solution for this problem.

Netscape products will also recognize and use rfc822Name values in
subjectAltName in addition to the "legacy" method of embedding the value in
the subject name itself.

> There is another problem with those "legacy" implementations that may be
> discussed together with this issue: Microsoft and Netscape both fail to
> encode/decode T61Strings correctly. They encode for example umlauts using
> ISO8859-1 and expect T61String to carry this encoding, which is wrong. In
> T.61 "München" has to be encoded as "MÈunchen" (hopefully these special
> characters make it to everyone on this list) but Microsoft and Netscape
> write and expects to get "München". Since DER require T.61 encoding for
> the word "München" (I've been told), you end up with the options:
> do not use anything else then PrintableString encodable items in certs.
>

If you look at RFC 2459, you will see that it suggests interpreting T61String
as containing ISO8859-1.  This is, of course, incorrect, but is there entirely
for compatibility with these sorts of implementations.  One small correction,
Netscape products do not actually attempt to encode or decode values in
T61String beyond the set of ASCII 7-bit characters.  In recent products,
values that don't fit in PrintableString are encoded into UniversalString.
This has its own problems, since many implementations don't understand that
either.

> do not use anything else then PrintableString encodable items in certs.

RFC2459 says that by 2003 everything should use UTF8String.  This encoding can
handle the full set of Unicode characters.

Terry

--------------F52457833C0AB5669E21CA79
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
[e-mail] wrote:
<blockquote TYPE=CITE>As far as I know at least Microsoft interprets rfc822Name
in
<br>subjectAltName if present. Maybe to encode both EmailAdress and
<br>subjectAltName in general is the right solution for this problem.</blockquote>
Netscape products will also recognize and use rfc822Name values in subjectAltName
in addition to the "legacy" method of embedding the value in the subject
name itself.
<blockquote TYPE=CITE>There is another problem with those "legacy" implementations
that may be
<br>discussed together with this issue: Microsoft and Netscape both fail
to
<br>encode/decode T61Strings correctly. They encode for example umlauts
using
<br>ISO8859-1 and expect T61String to carry this encoding, which is wrong.
In
<br>T.61 "M&uuml;nchen" has to be encoded as "M&Egrave;unchen" (hopefully
these special
<br>characters make it to everyone on this list) but Microsoft and Netscape
<br>write and expects to get "M&uuml;nchen". Since DER require T.61 encoding
for
<br>the word "M&uuml;nchen" (I've been told), you end up with the options:
<br>do not use anything else then PrintableString encodable items in certs.
<br>&nbsp;</blockquote>
If you look at RFC 2459, you will see that it suggests interpreting T61String
as containing ISO8859-1.&nbsp; This is, of course, incorrect, but is there
entirely for compatibility with these sorts of implementations.&nbsp; One
small correction, Netscape products do not actually attempt to encode or
decode values in T61String beyond the set of ASCII 7-bit characters.&nbsp;
In recent products, values that don't fit in PrintableString are encoded
into UniversalString.&nbsp; This has its own problems, since many implementations
don't understand that either.
<p><b>> do not use anything else then PrintableString encodable items in
certs.</b><b></b>
<p>RFC2459 says that by 2003 everything should use UTF8String.&nbsp; This
encoding can handle the full set of Unicode characters.
<p>Terry</html>

--------------F52457833C0AB5669E21CA79--

--------------msC64009C92BF65F7FD0E7BAAE
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

MIIIhQYJKoZIhvcNAQcCoIIIdjCCCHICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BlgwggMLMIICdKADAgECAgIlaTANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMDA5MTgwNjE1MzhaFw0wMTAzMTcwNjE1Mzha
MIGBMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIjAg
BgkqhkiG9w0BCQEWE3RoYXllc0BuZXRzY2FwZS5jb20xFDASBgNVBAMTC1RlcnJ5IEhheWVz
MRYwFAYKCZImiZPyLGQBARMGdGhheWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCu
3O/+q8x0q/PRsst9G7hfmjgh7H6/dnHY0XjEZnFwfSE3jZWeoLGd8mOoY7DC97j9OXo6/IpJ
JcCB0VsYCcvD35wS/T4Pj27Hy8wwaLxGQY7yI7xjHYT21lWNGxgp0GNjhPUECY26mVarJdba
N9hK2tLIPY1WS/nFCZchOz8sIwIDAQABo34wfDARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0P
AQH/BAQDAgSwMB8GA1UdIwQYMBaAFKI7ZTL39xuJ/FUNBwG8h0ha/ZA9MDYGCCsGAQUFBwEB
BCowKDAmBggrBgEFBQcwAYYaaHR0cDovL25zb2NzcC5uZXRzY2FwZS5jb20wDQYJKoZIhvcN
AQEEBQADgYEAVG1MTPU1ybrS69hh6saLjNi/h5Piw8OoCXwMgZZUi8Ek5M4WYzyQhSAz+XX3
XX7VVn6DEiOdp0Gwax8PAIP+01BNzcJwtdW2cqWr7fIC+w//MdWXjYj1M6ozN258hiQ5BttA
AnOpiw3kjBmWNH4fwGeQjDd3aoxLIbJ03mxu4nowggNFMIICrqADAgECAgEnMA0GCSqGSIb3
DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0
aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5j
b20wHhcNOTkwNjAzMjIwMDM0WhcNMDEwNjAyMjIwMDM0WjCBkzELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u
bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0
IENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA4u9f
LHZDiUsaX7Pl+Kpviy+BTWf/vUoPYy7E3IX2nixJJiD/ABfkiIhp3v2DV+CjERkRqtbcvO+z
0hUuVMZufL/ZucNG0wkFhOVTXEjthIWaDjs9Fgdc8LN5q5oQpbzBpNF4TAblZEH8BSVjJuvv
DMduVKGMzlRXth+S2rISS40CAwEAAaNpMGcwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUE
FjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwEQYJYIZIAYb4QgEBBAQDAgECMB8GA1UdIwQYMBaA
FHJJwnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBALpQffwAsv9BtAcIOQwh
9FlJFwjMjtPPDFbxb+gLGmli6waCW2msHYQnBjnJDn41E9B+wI+cWHwDMSyHENViO3DVDrFk
gDROWfrGWeZG3k5oCHVA9R2MKdaud63JPWnkQI1El0ZvvnrAWKSxH2qnDylRioENKY6d5A8z
C4+NJD3sMYIB9TCCAfECAQEwgZowgZMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQG
A1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYD
VQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBB
dXRob3JpdHkCAiVpMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
BgkqhkiG9w0BCQUxDxcNMDAwOTE4MTcyNjUwWjAjBgkqhkiG9w0BCQQxFgQUBPy+1P9C51o7
/SvgMSLjhLgQxgkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC
AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB
BQAEgYB9+zb8ktqiOcN/8q8A6TL61BGI6hYDHJdG/V3XX5n7uEIk2DKeQ9WvagmxQ4HtRIAg
sYJhBqavgMox/N33Tz5BLuwRb0d0Jvpfv9x2j/Oi0J7l7R+1NPHg2fC78z5DflN+L9Mmx0O5
rRl9TF2eYfr9hRLvq8OoRlGaEIeVarfV3w==
--------------msC64009C92BF65F7FD0E7BAAE--



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19839 for <[e-mail]>; Mon, 18 Sep 2000 10:23:46 -0700 (PDT)
Received: from mega (t2o69p6.telia.com [62.20.144.126]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id TAA03664; Mon, 18 Sep 2000 19:26:22 +0200 (CEST)
Message-ID: <001601c0219d$ca392a60$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: 2459 disapproved by MSFT and VeriSign?
Date: Mon, 18 Sep 2000 20:25:13 +0200
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 ns.secondary.com id KAA19840

Olaf,

>As far as I know at least Microsoft interprets rfc822Name in
>subjectAltName if present.

They do.

>Maybe to encode both EmailAdress and
>subjectAltName in general is the right solution for this problem.

Will the REAL e-mail address solution, please stand up! please stand up! please stand up!

Pardon the joke.  Let's be serious:

The current Microsoft, VeriSign solution (email address attribute) is already widely implemented
and is spreading with the help of CertSrv.  It is accepted "everywhere" but in 2459. 
I.e. 2459 is not "de-facto" standard conformant and should be updated.

>There is another problem with those "legacy" implementations that may be
>discussed together with this issue: Microsoft and Netscape both fail to
>encode/decode T61Strings correctly. They encode for example umlauts using
>ISO8859-1 and expect T61String to carry this encoding, which is wrong. In
>T.61 "München" has to be encoded as "MÈunchen" (hopefully these special
>characters make it to everyone on this list) but Microsoft and Netscape
>write and expects to get "München". Since DER require T.61 encoding for
>the word "München" (I've been told), you end up with the options:
>
>encode wrong but get the correct display of the certificate in those
>applications (which may cause problems with applications that
>decode/encode certs prior to signature calculation and other operations),
>
>encode right but get an odd display,
>
>do not use anything else then PrintableString encodable items in certs.
>
>None of these options look very attractive. For me this problem looks
>harder to resolve cleanly. (By the way, Microsoft screwed the T.61
>encoding up in LDAP v2 requests as well).


This is probably true but is this a question related to 2459?  I would say it looks
more like a bug reports for Microsoft and Netscape.

Regards
Anders



Received: from inet-gate.gdm.de ([195.127.236.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18327 for <[e-mail]>; Mon, 18 Sep 2000 09:08:11 -0700 (PDT)
From: [e-mail]
Received: by inet-gate.gdm.de (8.9.3/8.9.3) id SAA20906; Mon, 18 Sep 2000 18:02:48 +0200 (CEST)
Received: (from localhost) by inet-gate.gdm.de (MSCAN) id 5/inet-gate.gdm.de/smtp-gw/mscan; Mon Sep 18 18:02:48 2000
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Subject: Re: 2459 disapproved by MSFT and VeriSign?
X-Mailer: Lotus Notes Version 5.0.1 (Intl)  11. August 1999
Message-ID: <OFA723901B.187EA080-ONC125695E.00568B85@LocalDomain>
Date: Mon, 18 Sep 2000 18:10:13 +0200
X-MIMETrack: MIME-CD by Notes Server on NOTESGDM1/SRV/GuD(Release 5.0.3 (Intl)|21 March 2000) at 09/18/2000 06:09:27 PM, MIME-CD complete at 09/18/2000 06:09:27 PM, Serialize by Router on NOTESDMZ1/SRV/GuD(Release 5.0.4a |July 24, 2000) at 09/18/2000 06:11:22 PM
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 ns.secondary.com id JAA18328

As far as I know at least Microsoft interprets rfc822Name in
subjectAltName if present. Maybe to encode both EmailAdress and
subjectAltName in general is the right solution for this problem.

There is another problem with those "legacy" implementations that may be
discussed together with this issue: Microsoft and Netscape both fail to
encode/decode T61Strings correctly. They encode for example umlauts using
ISO8859-1 and expect T61String to carry this encoding, which is wrong. In
T.61 "München" has to be encoded as "MÈunchen" (hopefully these special
characters make it to everyone on this list) but Microsoft and Netscape
write and expects to get "München". Since DER require T.61 encoding for
the word "München" (I've been told), you end up with the options:

encode wrong but get the correct display of the certificate in those
applications (which may cause problems with applications that
decode/encode certs prior to signature calculation and other operations),

encode right but get an odd display,

do not use anything else then PrintableString encodable items in certs.

None of these options look very attractive. For me this problem looks
harder to resolve cleanly. (By the way, Microsoft screwed the T.61
encoding up in LDAP v2 requests as well).

--
Olaf Schlüter, Manager Trust Center Systems and Services
Giesecke & Devrient GmbH, Prinzregentenstr. 159, D-81607 München
Phone: [phone], Fax: [phone]
http://www.gieseckedevrient.com





"Anders Rundgren" <[e-mail]>
18.09.00 18:25


        To:     "PKIX-List" <[e-mail]>
        cc:
        Subject:        2459 disapproved by MSFT and VeriSign?


Hi,

>From RFC2459

"In addition, legacy implementations exist where an RFC 822 name is
   embedded in the subject distinguished name as an EmailAddress
   attribute.  The attribute value for EmailAddress is of type IA5String
   to permit inclusion of the character '@', which is not part of the
   PrintableString character set.  EmailAddress attribute values are not
   case sensitive (e.g., "[e-mail]" is the same as
   "[e-mail]").

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name field (see sec. 4.2.1.7) to describe such
   identities.  "

Now, the problem (correct me if I am wrong) is that s.c. legacy is what is
actually
sold, shipped and marketed by two really major vendors, Microsoft in their
latest Certificate Server and VeriSign through their class #1 e-mail
certificates.

IMO these guys have a higher weight than 2459 and son-of-2459 should be
updated
accordingly.  I can hardly see that the others will ever change their
stuff.  Particularly
as just about every system out there already is compatible with "legacy".

Regards
Anders







Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17787 for <[e-mail]>; Mon, 18 Sep 2000 08:46:07 -0700 (PDT)
Received: from tsg1 ([12.72.112.232]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000918154802.RIWM8992.mtiwmhc26.worldnet.att.net@tsg1>; Mon, 18 Sep 2000 15:48:02 +0000
Message-ID: <00b101c02187$d0c4e4c0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Date: Mon, 18 Sep 2000 08:28:15 -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.3018.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.3018.1300

Sorry Peter, Yes of course . Let me say this publicly for all -

I will remove my objections to the TSP being advanced to "proposed Draft
Standard", but I have to ask the WG Chairs - Hey Stephen/Tim - Is this TSP
effort intended to be PKIX's "One and only" Time Stamping Protocol?

By the way - I still think it is silly to do this, to advance this
particular draft without the mods I have asked for (esp. the AD), and at the
very least I really want to get the term "TTP"  into the name of the Draft
effort so it more accurately reflects the process of what it provides.

But I understand that this effort (the TSP one) is being perceived now as
one of those "Bill's that languish in committee too long" - and the need to
advance it or to kill it.

Todd

----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>
Sent: Monday, September 18, 2000 7:37 AM
Subject: Re: Fw: The need for two grades of time data.


> >
> > All - this is a conversation between Denis Pinkas and myself in which:
> >
> >     1)     I removed my objections to the TSP Draft being advanced to
draft
> > standard
>
> I guess You mean PROPOSED STANDARD?
>
>



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15905 for <[e-mail]>; Mon, 18 Sep 2000 08:23:35 -0700 (PDT)
Received: from mega (t4o69p8.telia.com [62.20.145.128]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id RAA12225 for <[e-mail]>; Mon, 18 Sep 2000 17:26:10 +0200 (CEST)
Message-ID: <000301c0218c$ffe500f0$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: "PKIX-List" <[e-mail]>
Subject: 2459 disapproved by MSFT and VeriSign?
Date: Mon, 18 Sep 2000 18:25:01 +0200
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 ns.secondary.com id IAA15910

Hi,

>From RFC2459

"In addition, legacy implementations exist where an RFC 822 name is
   embedded in the subject distinguished name as an EmailAddress
   attribute.  The attribute value for EmailAddress is of type IA5String
   to permit inclusion of the character '@', which is not part of the
   PrintableString character set.  EmailAddress attribute values are not
   case sensitive (e.g., "[e-mail]" is the same as
   "[e-mail]").

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name field (see sec. 4.2.1.7) to describe such
   identities.  "

Now, the problem (correct me if I am wrong) is that s.c. legacy is what is actually
sold, shipped and marketed by two really major vendors, Microsoft in their
latest Certificate Server and VeriSign through their class #1 e-mail certificates.

IMO these guys have a higher weight than 2459 and son-of-2459 should be updated
accordingly.  I can hardly see that the others will ever change their stuff.  Particularly
as just about every system out there already is compatible with "legacy".

Regards
Anders




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13501 for <[e-mail]>; Mon, 18 Sep 2000 08:13:59 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA26739; Mon, 18 Sep 2000 11:16:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220801b5ebe1d3cb63@[171.78.30.107]>
In-Reply-To: <003701c0217c$18af0b00$020aff0c@tsg1>
References: <003701c0217c$18af0b00$020aff0c@tsg1>
Date: Mon, 18 Sep 2000 11:15:12 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Fw: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

I don't think the name needs to be changed, but I think the intro 
should contain  text that notes the TTP context in which TSP operates.

Steve


Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11449 for <[e-mail]>; Mon, 18 Sep 2000 07:22:07 -0700 (PDT)
Received: from tsg1 ([12.72.65.167]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000918142409.MHEK2687.mtiwmhc23.worldnet.att.net@tsg1> for <[e-mail]>; Mon, 18 Sep 2000 14:24:09 +0000
Message-ID: <003701c0217c$18af0b00$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Subject: Fw: The need for two grades of time data.
Date: Mon, 18 Sep 2000 07:23:07 -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.3018.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.3018.1300

All - this is a conversation between Denis Pinkas and myself in which:

    1)     I removed my objections to the TSP Draft being advanced to draft
standard

    2)    I also recommend that we include the term TTP in the title of the
Draft and Denis re]torts with that PKIX may object but he is OK with it? So
how does the rest of PKIX feel about this?.

I would like to have the phrase "TTP" inserted into the title of the draft
as it is advanced to "Draft Standard" so that the use model of the Protocol
is defined by its title more accurately

Any problems with this?


Todd Glassey

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "todd glassey" <[e-mail]>
Sent: Monday, September 18, 2000 4:13 AM
Subject: Re: The need for two grades of time data.


Todd,

> Denis - Good morning how is France today? California is a bit overcast
here
> in the Valley (North end of Stanford Campus area). Anyway your responses
are
> good here.

Thanks. :-)


SNIP

> So I interpret your statement as being implicitely supportive of
> advancement to Proposed Standard, and at this time not supportive of
> advancement to Standard. Mee too. So let us close this issue.
>
> YES at this time I will remove my objections

 .. so could you simply reply to this message while copying the PKIX
mailing ?

I am not sure that the PKIX group will accept the addition of the
word "TTP" in the title, because TTP has several co-notations
according to who you speak to, but you can try.

--- SNIP ---


Regards,

Denis


> and I think I can get the Notary Associations to
> accept it if you make the mods I have requested. If you woulnd't mind
adding
> an author I will make the first pass at them and submit the new reviser
> Notary Protocol to the Group.
>
> > if it allowed
> > for multiple use models, and updating to address emerging and audit
driven
> > needs. As it sits now it is too closed and restricted.
> >
> > What we have in the TSP now  is a TTP based service model that does not
> > authenticate the time data it claims is evidence - so the total reliance
> on
> > the marque is based in proving some nebulous time data instance without
a
> > proofing model. Might as well be human testimony.
> >
> > Your included text starts here
> > --------------
> > It seems that you are trying to re-open a discussion that took place
> > in May 1999 (along BERT). So let me provide you with a copy of some
> > E-mails from May 1999 so that we can *definitively* close this
> > discussion.
> >
> > Denis
> > --------------
> >
> > Since you have thrown the "this is a closed issue" down, let me say I
> > disagree - it is my opinion that this was not decided by the group, or
> even
> > debated openly.
>
> IT IS A CLOSED ISSUE. Let me report the official minutes of the 45
> th IETF meeting to prove this (as far as I remember, you were not
> present at this meeting).
>
> " Temporal Data Token (M. Duren-WetStone)
>
> Presentation focused on format for TDT (in the TSA) that helps
> attest to the integrity of the time source, i.e., providing a link
> to a trusted time source. This approach pushes evidence of time
> source into a token, vs. other, external measures that a TSA
> akes to ensure the accuracy and integrity of its time source.
> A claimed feature of this approach is that it allows a client
> to be able to verify the utility (for non-repudiation) of the
> returned token immediately, vs. the deferred verification more
> typical of TSA operation. As with the BERT presentation, the
> speaker was asked about possible intellectual property claims
> nd about the breadth of vendor support for the propose
> TDT format. The speaker asserted that he was aware of no IP
> claims, and that he was aware of at least two vendors who had
> expressed interest in this format, although no more than one
> was building products to this spec at this time. The WG Chairs
> and the Security ADs also will need to discuss whether this is
> within the scope of PKIX, before this item progresses. "
>
> Please read very carefully the last sentence.
>
> Then, after the meeting, Stephen Kent and Warwick Ford (i.e. the two
> co-chairs of the PKIX WG) decided that BERT was not appropriate for
> PKIX. They suggested that it be brought to STIME. It was, and STIME
> rejected it as well.
>
> So, PLEASE, leave the bandwith of the PKIX mailing list for other
> maters of discussions.
>
> Denis
>
> > I understand what the TSP is and does, I think from a commercial
> standpoint
> > this is really not what time stamping systems want to be. Lets answer
the
> > following questions and see where that leads the group.
> >
> > 1)    If the purpose of the time stamping protocol is to enable decision
> > support processes by "validating signatures in time", then how is that
the
> > time data authentication process was overlooked? It seems to me that the
> > credibility of the time data is directly tied to the believability
> resource
> > produced by the Signature Validation Process, isn't it?  If so, then why
> > would we leave that to an external CPS that was tied to the Host's
> operating
> > environment or OS operation practices???
> >
> > 2)    If the purpose of  the timestamp is evidentiary, then the quality
of
> > the time data, how it is authenticated, where it came from, and who it
was
> > certified by is critical to the trust process.
> >
> > The need for a grade of time data that is nonrepudiated and is traceable
> to
> > the BIPM or UTC /GeT is very important to the big picture and every
trust
> > process we build. To put our heads in the sand and claim that this is
the
> > OS's problem or that of the people that operate the system is also
> > ludicrous.
> >
> > The point is whether you are building an evidentiary system that can
stand
> > on its own, or one that requires the TSA to validate/use the marques of.
> > You use PKI and other technologies to authenticate the source of the
> > non-parametric data points, but not the time data. Why? and why cant the
> > token stand on its own two feet?
> >
> > 3)    Why constrain the system to a TTP architecture only? many of the
> legal
> > processes we do today are based in Ceremony. Notorial, filing a legal
> > document, etc. these are all based in ceremony. So the creation of the
> > timestamp is essentially that ceremony. that means that the time stamp
> > itself is the evidentiary token representing the completion of the
> > ceremonial process and so the timestamps by themselves have value and
> worth
> > in token exchange and processing models.
> >
> > This is why BERT was so important - and as long as we are talking about
> the
> > BERT...
> >
> > BERT
> > ------
> > I agree with your commentary about how fast BERT was shot down - the
BERT
> > Token structure is clearly a threat to the TSP in that it does exactly
> what
> > is defined in the three requirements above. Now I do have to admit that
> the
> > initial BERT-1 Token Structure has some interesting problems with its
> > granularity representation and a possible potential for the dual-events
> > within the same granularity window, but that was fixed in the 2nd
> generation
> > BERT-II  Structure, which I suppose I should file.
> >
> > FYI - BERT-II turns the best of the XML and IOTP token processes into a
> TSP
> > Evidentiary Token and not only addresses the content certification, but
> the
> > type of the event as well. BERT-II supports virtually all key or crypto
> > techniques and has plugin capabilities for building an event
> representation
> > specific to the end-use needs. Its small  and expandable to also contain
> the
> > content it watermarks as well and with this model, you don't need the
Time
> > Stamp
> > Server just the BERT tool Set to extract or validate any of the
> components.
> >
> > Just follow the use rules and there you are.
> >
> > If anyone is interested in the BERT-II token structure prior to the
Draft
> > being filed in the next 2 weeks, send me a email and I will send the
> > preliminary draft to you.
> >
> > Todd
> >
> > ---- Original Message -----
> > From: "Denis Pinkas" <[e-mail]>
> > To: "todd glassey" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Wednesday, September 13, 2000 3:57 AM
> > Subject: Re: The need for two grades of time data.
> >
> > Todd,
> >
> > > Thanks for responding Steve, but again the real issue with
> > > this concept of evidentiary time is in treating the parametric
> > > time data as content rather than control process elements.
> > > Once you do that it gets to be obvious that you need a
> > > auth/certification stream and chain-of-custody model for that
> > > time data to meet these evidentiary needs.
> >
> > > So I have to ask - "What is the problem with treating time and
> > > perhaps other parametric data like location data, as through
> > > it had the same risks with it that the Human or Entity Identity
> > > issues that spawned PKIX in the first place? because it does?"
> >
> > > We seem to as a group have restricted our relating to time and
> > > other parametric evidentiary processes as though they were only
> > > part of the plumbing and it just aint so.
> >
> > > Any of the data points that are use inside the decision support
> > > process protocols that we are building (OCSP, TSP, etc etc etc)
> > > are all tied to the requirement of some evidentiary anchor -
> > > Someone or something has to sign that top level cert, some key
> > > generator has to pump out that key pairing, and that data has been
> > > sanctified by PKIX to date as it rightly should, but the use of
> > > traditional Control Data points a parts of the larger evidentiary
> > > or decision support process warrants that that data have the same
> > > integrity as any other.
> >
> > > Just my two cents.
> >
> > =================================================================
> >
> > Object:  Re: Comments on time-stamp-01: Identification of TSA
> > Date:    Thu, 27 May 1999 13:55:18 -0400
> > From:    Stephen Kent <[e-mail]>
> > To:     "Todd S. Glassey - ELN" <[e-mail]>
> > Copies:  <[e-mail]>
> >
> > 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
> >
> > =================================================================
> >
> > Object: Re: Comments on time-stamp-01: Identification of TSA
> > Date:   Fri, 28 May 1999 11:43:40 +0200
> > From:   Denis Pinkas <[e-mail]>
> > To:     "Todd S. Glassey - ELN" <[e-mail]>
> > Copies: [e-mail]
> >
> > 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
> >
> > =================================================================
> >
> > ... and finally an E-mail sent by Todd to me, not to the PKIX
> > mailing list that is worth to mention:
> >
> > Object:  Re: Long-term validation of signatures
> > Date:    Mon, 26 Apr 1999 14:37:55 -0700
> > From:    "Todd S. Glassey" <[e-mail]>
> > To:      "Denis Pinkas" <[e-mail]>, "Hans Nilsson"
> > <[e-mail]>
> >
> > Denis, don't take my commentary wrong.
> > The Draft(s) that you Pat, Carlisle, Robert produced are
> > FANTASTIC!!!. They represent the first credible mechanism for a
> > subsumable timebase service model and thats top-notch.
> >
> > (snip)



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10318 for <[e-mail]>; Mon, 18 Sep 2000 06:33:35 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA08436; Mon, 18 Sep 2000 15:41:04 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA37954; Mon, 18 Sep 2000 15:35:39 +0200
Message-ID: <[e-mail]>
Date: Mon, 18 Sep 2000 15:35:39 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

Sorry. The time for new comments/text improvements/ text
clarifications is now closed. We are only processing commments
received during the IESG last call period. Of course, if the comment
is purely editorial, e.g. a typo, we can still certainly take it.

Regards,

Denis

> > The resolution of the 24 comments from Russ is on its way and a
> > draft response is being circulated between the co-editors of the
> > document. So I should be able to send a reply to Russ and to the
> > mailing list before the end of next week.
> >
> 
> Would it be possible to add a few lines of text to the descriptions
> of the transport protocols, i.e. giving for each a possible
> value of a AccessMethod to be usable in a Subject Information Access
> Extension?
> 
> Peter Sylvester


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA09607 for <[e-mail]>; Mon, 18 Sep 2000 06:13:46 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA00221; Mon, 18 Sep 2000 15:16:22 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 18 Sep 2000 15:16:22 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA20248; Mon, 18 Sep 2000 15:16:21 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA19964; Mon, 18 Sep 2000 15:16:20 +0200 (MET DST)
Date: Mon, 18 Sep 2000 15:16:20 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [e-mail]

> The resolution of the 24 comments from Russ is on its way and a
> draft response is being circulated between the co-editors of the
> document. So I should be able to send a reply to Russ and to the
> mailing list before the end of next week.
> 

Would it be possible to add a few lines of text to the descriptions
of the transport protocols, i.e. giving for each a possible
value of a AccessMethod to be usable in a Subject Information Access
Extension? 

Peter Sylvester


Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16107 for <[e-mail]>; Sun, 17 Sep 2000 11:14:31 -0700 (PDT)
Received: from tsg1 ([12.72.102.88]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000917181622.DIIV8992.mtiwmhc26.worldnet.att.net@tsg1>; Sun, 17 Sep 2000 18:16:22 +0000
Message-ID: <001901c020d3$59ea75e0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1><[e-mail]><03a101c01dd0$52afa620$020aff0c@tsg1><v0422080ab5e6c934afc6@[171.78.30.107]><062701c01e8c$de010f40$020aff0c@tsg1><06d901c01eab$69904f80$020aff0c@tsg1> <v04220804b5e7dff18902@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Sun, 17 Sep 2000 11:15:54 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Actually Stephen, irrelevant of the intent of the original design the NTP
protocol works wonderfully as a time stamping source and movement transport.
This is exactly my point. From an audit model perspective NTP has been there
and has been doing this duty for years, and as valiant as it is, the
industry already has tens of millions of NTP instances deployed and that
also is part of the point I want to make here.

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, September 15, 2000 7:31 AM
Subject: Re: The need for two grades of time data.


> Todd,
>
> NTP is a time distribution system, but not a time stamping system.

Maybe by how it is used, but that just aint true with regard to its
functionality. Time data, via NTP or ACTS, is moved about in the form of a
token or data stream. After receipt it is processed to produce the component
data by the application that receives it. In exactly those terms it is a
timestamping system. Sign and upload your identity and you get back a server
signed response token showing the both of you together. How cozy. Add the
Client Side Time and you have a Differential Stamp showing Delta T between
the two systems. Put this token into a DB of tokens and you have a TS DB
System.

My point here again is that this is identical in mechanism to the TSP, the
question is whether the process' intention was to set the OS level Clock
and/or to create some evidentiary mark with the data it got. In the case of
the new NTP, it can do both. What NTP does not provide that the TSP API does
is the ability to validate the internal components of the marque (TST), but
that
is really just a use specific service API. So this could easily be added at
the Application Level since the NTP Tokens are so well received globally.

By the way, NTP generically does do something critical for a TSP (IMHO) that
the TSP does not do and that is to Log its Data to the Local System's
Logging Instance whatever that is. Although this is a functionality that is
really added in the implementation of the protocol as a client/server
rather than in the core protocol, still it is a formal part of the BCP for
using NTP and that is something that the TSP clearly does not have. Myself,
I think this was an oversight in the functionality of the TSP system, but
what the hey, a simple App. Desc. might have solved this.

Not that I am suggesting  scrapping the TSP as I have said many a time, but
it is important to realize that there are other protocols out there that can
and will perform this task as well, and unless PKIX intends to do more than
just enact a standard and wait for the world to come to it, with this new
PKI ability in NTP, my feeling is that it will be too easy to do exactly
what the TSP does with NTP. Admittedly through a different API and process
flow but the end result I think is actually a better stamp. Not only is the
token structure already compliant with millions of environments it clearly
can talk about the time data itself. Something else that the TSA/TSP cant do
yet.

> Looking at the latest NTP security draft from Dave Mills, the
> services offered by NTP have not changed in this regard.  Thus a TSA
> might choose to employ NTP, but it need not do so. TSP is flexible in
> allowing a TSA to choose the method(s) that it employs, and in
> allowing the market and the legal system to decide which methods are
> appropriate.

Steve, the TSP is essentially an API of services for managing and producing
marques, yes? So then it could easily convert those API Services  to NTP
service calls and then the TSP would work layered on the New NTP.  Hmmmm.
New Product Idea here. Put the TS Token into the Client-Uploadable Payload
for the NTP Stream and viola Timestamper and OS level Time Management in one
clean environment.Use the API as an extension to manage the specific
components/contents of the tokens itself.

Anyway - trying to fight something that is already ubiquitously deployed
seems a bit feeble as well to me. But what they hey, what do I know?
>
> Steve
>




Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06016 for <[e-mail]>; Fri, 15 Sep 2000 18:04:11 -0700 (PDT)
Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id SAA01051 for <[e-mail]>; Fri, 15 Sep 2000 18:03:04 -0700 (PDT)
Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id <SWY1SPFM>; Fri, 15 Sep 2000 18:06:06 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: [e-mail]
Subject: OCSPv2 and OCSP extensions drafts
Date: Fri, 15 Sep 2000 18:06:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

Ealier today I sent to IETF three OCSP-related drafts as followup to our
Pittsburg meeting, developed in collaboration with Carlisle Adams and
Stephen Farrell.  I trust these drafts will soon be available for your
consideration.  If you wish a more immediate copy, please let me know
directly.

Two of these drafts propose Internet standard extensions to OCSP.  These are
Delegated Path Validation (DPV) and Delegated Path Discovery (DPD).  The DPV
extension enables offloading of certificate path processing to an OCSP
server while the DPD extension enables acquisition of the PKI data an OCSP
server would otherwise use in meeting the DPV requirements.

The third draft is OCSPv2.  This is the "2560bis" work I referred to
earlier.  It proposes to extend the existing certID structure to more fully
enable the use of OCSP in wireless and other contexts.  The v2 proposal
interoperably subsumes RFC 2560.  There is no technical linkage between the
v2 proposal and the DPV and DPD drafts.  The latter two are specifically
defined to enable their application to existing OCSP implementations.

Mike



Received: from harry.cmr.gov (harry.cmr.gov [140.162.6.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01304 for <[e-mail]>; Fri, 15 Sep 2000 13:08:58 -0700 (PDT)
Received: from dolphin.cmr.gov (dolphin [140.162.3.135]) by harry.cmr.gov (8.9.3/8.9.3) with ESMTP id QAA21563; Fri, 15 Sep 2000 16:10:20 -0400 (EDT)
Received: from cais.com (localhost [127.0.0.1]) by dolphin.cmr.gov (8.9.1b+Sun/8.9.1) with ESMTP id QAA26550; Fri, 15 Sep 2000 16:10:20 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 15 Sep 2000 16:10:19 -0400
From: "Patrick G. Moore" <[e-mail]>
Organization: Center for Monitoring Research
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: The need for two grades of time data.
References: <[e-mail]> <06dd01c01eab$77b44e40$020aff0c@tsg1> <[e-mail]> <079f01c01f43$9f244c80$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

todd glassey wrote:
> 
> ----- Original Message -----
> From: "Patrick G. Moore" <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, September 15, 2000 8:21 AM
> Subject: Re: The need for two grades of time data.
> 
> > todd glassey wrote:
> > >
> > > If there is proofing data included inside the TS as evidentiary content
> then
> > > the TST itself can easily be self authenticating.
> > >
> > > The reason that the PKI
> > > you are discussing has an external TRUST REFERENCE is because it was
> > > designed that way. There is no reason that the proofing constraints
> could
> > > not go into the token as well, then just the "rules on how to interpret
> the
> > > token" remain to be defined here.
> > >
> > Fundamental problem here.  Nothing can be self authenticating without an
> > external reference.
> 
> Yes but the question is what that external reference is -  an externally
> supplied keying data  scheme or an externally supplied interpretation
> framework, and that is exactly the issue. In the existing model the process
> requires BOTH the external validation process and externally supplied keying
> or control information to process the event structures that are created by
> the TSP.
> 
> > That is why we don't trust self signed certs, even if
> > they purport to be a CA, without verifying the fingerprint offline. (Never
> > mind that most people blindly accept the ones that come in thier
> browsers.)
> 
> Actually the real reason we "dont trust self-signed certs" has to do with
> who is financially responsible for actions done with them. The technology is
> fine for many application sincluding BtoB extranet type services.
> 
> > A painting signed by Picaso means nothing, if no one had ever seen his
> > signature before, or asked him if he really signed it.
> 
> How do you figure this? Assume we are not talking about the human cognitive
> process of "enjoying or absorbing the style" of the art, so what is it we
> are talking about here? Identifying the paingting by the techniique of the
> person doing it and the breakdown of the molecular components of the
> painting...
> 
> "Gee this unsigned painting has the same molecular makeup in the paint as
> this signed Picasso does, donw to the meyal componets and their oxidation
> state, as well as the oprganic components - the technique is identical, and
> the canvas carbon dates out to the same period."
> 
> It is likely that the risk providers and auditors (art experts) will proclam
> this as an original. hence the parametric content of the TST was used in
> this case to authenticate it.
> 
> I must have been confused somewhere but I thought the point of the TSP
> Protocol was to build some form of evidentiary grade control systems so that
> people could create these "things" that could be used to universally
> represent events. Am I wrong?
> 
> See the point  is really the Token becuase that's where the rubber meets the
> road. The API is a nicety but what TSP really needs to be is this set of
> token processing rules and a set of recommended uses for the API and the
> processing of the tokens themselves. Nothing more,. nothing less.
> 
> > They don't need
> > to ask him if they are already familiar with his signature.  All the same
> > logic applies between the wet world and e-world.
> 
> Interesting analogy - But  I disagree. Authenticate any of the master's
> unsigned  work as the example I cited above clearly doews and you are stuck
> with Parametric validation models.
> 
All of the examples you cite require external references.  Such as knowledge of
a
known authentic example, and comparison to it.  You cannot simply collect
a bunch of data which is self consistent and say it is authentic.  Unless
you can undeniably link it to some verifiable trust point, the whole chain
of evidence could be faked.

A self signed CA is NOT acceptable for security without verification.  Granted,
the shear number of copies of the most common CA certs, and the unliklyhood of
someone tampering with your browser download, gives some measure of confidence
that noone will try to fake one of those.

I will not waste more time on this.

Cheers
Pat

> >
> > Either you trust your TSA, or it's CAs integrity or you don't.
> 
> The world is not so Binary I think.
> 
> > You must
> > also choose a TSA who will be trusted by the relying party to which you
> offer
> > your proof.
> 
> Not necessarily. Just one that can substantiate its process under
> prosecution. That's the point, there is no trust relationship really between
> the TSP and its users whatsoever, unless it offer insurance against its
> services At least this is the way of it in the real world.
> 
> But how that evidentiary process is carried in the form of the TSA output is
> exactly the point. The ability to prove the TSA's operations and process
> inline is very valuable in the mechanics of using these trust anchor
> instruments.
> >
> > Sorry, enough BW.
> > Pat


Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00387 for <[e-mail]>; Fri, 15 Sep 2000 12:23:56 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id PAA22914 for <[e-mail]>; Fri, 15 Sep 2000 15:26:17 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 15 Sep 2000 15:24:58 -0400
To: <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: The need for two grades of time data.
In-Reply-To: <078a01c01f3f$ccb9c020$020aff0c@tsg1>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yikes!  I'm out of the office three days (sorry Steve!), and I'm billyuns 
and billyuns of messages behind.  I printed this thread to save my eyes - 
and wiped out a small forest in the process.

After reading this thread and rereading the TSP document, I have a few 
opinions of my own:

(1) The TSP document defines a protocol.  A client system can use this 
protocol to obtain a time stamp token from a time stamp server.  The token 
can be used to demonstrate that a datum existed at a particular point in time.

(2) Different time stamp servers may deliver different "grades" of time 
data.  The grade of time data is a function of the hardware, software, and 
procedures [including time source] used to implement the time stamp 
server.  The grade of time data is *not* a function of the protocol.

(3) The time data includes a policy field, which includes an object 
identifier and an optional qualifier.  When a CA wishes to indicate the 
"grade" of an X.509 certificate, it uses *precisely* this 
mechanism.  Relying parties use this information to determine if an X.509 
certificate is acceptable for their application.  In my opinion, this 
mechanism is also sufficient to indicate the grade of time data.

(4) The time stamp token can optionally include extensions.  These 
extensions field is a generic mechanism to convey additional 
information.  For those that find the policy field insufficient, this field 
could be used to convey additional and specific information regarding the 
time source and other operational aspects of the time stamp server.  The 
BERT token might be such a candidate.

(5) I understand that Todd and some others would like to "formally define 
what an evidentiary grade source is and what it must conform to."  A 
commendable goal, but I am not sure that PKIX is the place to draft this 
definition.  It is certainly outside my narrow field of competency!  I also 
fear that this definition will be different for each "local" legal 
system.  However, the TSP should certainly be able to convey this 
information when a standard definition emerges.  In light of (4), I do 
*not* believe that this requires any changes to the TSP specification.

In summary, I believe that the TSP specification provides just the right 
level of specificity.  It requires time stamp servers to implicitly 
indicate the grade of time data through an OID.  Relying parties can use 
this information to decide if the time data is acceptable for their 
application.  The TSP specification *permits* time stamp servers to 
explicitly indicate the grade of time data through an extension field.  As 
legal frameworks emerge, this will support an explicit inclusion of locally 
relevant time data grading information.

My two cents.

Thanks,

Tim Polk




Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28128 for <[e-mail]>; Fri, 15 Sep 2000 11:06:29 -0700 (PDT)
Received: from tsg1 ([12.72.64.238]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000915180822.EVJJ6605.mtiwmhc25.worldnet.att.net@tsg1>; Fri, 15 Sep 2000 18:08:22 +0000
Message-ID: <078a01c01f3f$ccb9c020$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Fri, 15 Sep 2000 10:55: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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, September 15, 2000 3:10 AM
Subject: Re: The need for two grades of time data.


> > I want everyone to understand that I am not trying to be a jerk here, I
> > probably should have used more benign language - I just think that with
the
> > sheer number of NTP Servers out there already, that NTP as a common
> > timestamping system may actually make a lot of sense and PKIX might not
be
> > able to stop its use to focus favor on the TSP. That's all.
> >
> > T.
>
> Are we getting back to an example of the encoding wars?

Possibly but as more and more of the types of functionality that we need in
Commercial Audit process becoems autonomic this will happen.

>
> I don't think that PKIX regards NTP as a time 'stamping' system.

I do understand that, but the fact remains that NTP is easily used as a TS
transport and with AutoKey will do most of what the TSP protocol was
architected to do and that there are already tens of millions of NTP systems
out there.

I  am just brining up the point that it might not matter collectively here
what we think. It may be moot that applications providers and users just
code up TS processes that work for thier exising apps by simply using the
already in place NTP system.

> the NTP network can be a provider of time, and a client may also use
> it in order to determine the validity of a time stamp.

NTP surveying is alo a good one to add. That and the concept of Clock
Steering.

>
> NTP times are used to synchronize clocks, not necessarily to show them
> in a court.

No and this is the subtle discinction here. The NTP protocol is used to
transport time data and hashes for timestamping. becuase of the NTP packet
and the process of how NTP Clients talke to their NTP Servers they also
include their own timesense in the timing request. The addition of the
payload was there to allow endpoint authentication but if that also includes
a hash of the blob to be stamped so be it, there it is. The NTP response
packet will be the TST stream itself.

> Once you've set the clock, you're done, or are you
> keeping it for saying, I have receive that stamp to set my clock.

Your talking about two processes, one that uses the time data as content,
that being the Time Stamp, and the other that uses that content as control
and policy information, thats the NTP TOD Timesetting Process - remember
that the mechanical management of the clock is based in the "what the client
application does" and not in the NTP protocol itself.

> Well, when did you set your clock, and to what value. Where's the proof
> or evidence? Who cares and when?

yes, that's the idea.

>
> I might be wrong, but when I make an abstract form of what is provided
> in BERT, the only difference concerning the time value (besides that
> it is in NTP form) is that there is an indication of what source
> it came from.

the BERT 1 Token was originally only designed for indicating a Time and
Location for a minimal payload. The second generation of BERT uses a more
modular approach to allow any number of event types and contains a fixed
location Token Header for processing that defines the rules or engagement
and the trust level of the token.

>If someone believes that this is important, please
> make a specification of how to encode such data. I don't think that
> the TSA often changes a provider, thus it might be sufficient to
> add this to a policy for the moment.

The issue becomes 'what do I do to manage the TST after the TSA is gone?'

> Transforming an NTP value into a GENERALIZEDTIME doesn't seem to me a
> totally impossible task, or if ncessary, one might consider to
> just add an OCTETSTRING with an encoded NTP time in there.
>
> The rest in BERT could be regarded as nih symdrome provoked Sinatra
> solution to encode names, certificates, signature values etc. of
> information that can be probably already be assembled in other proposed
> or existing secured token formats. Sorry for the flame, I'd be glad
> to be corrected if my assumption isn't true.

Its not, but the Sinatra commentary is amusing, and  Peter - I have been
bashed so many times already for this here and on other lists - its no
problem partner.

As to NIH being at play, what the intent behind the BERT is is that there
needs to be a set of stamping data structures that are all 'standardized"
that is agreed upon by the vendors such that their systems can all
inter-relate with  eachother over these evidentiary interplay tranports.

Thats a 50,000 foot concept but the idea behind the BERT was that
evidentiary services have to work with existing systems and these are all
predominently based in DB environments. That means that the TST needs to be
manageable from within the DB context and that is not happeneing here yet
that I can tell .

Todd



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26416 for <[e-mail]>; Fri, 15 Sep 2000 09:34:42 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA13371; Fri, 15 Sep 2000 18:37:04 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 15 Sep 2000 18:37:04 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA11990; Fri, 15 Sep 2000 18:37:03 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA18921; Fri, 15 Sep 2000 18:37:02 +0200 (MET DST)
Date: Fri, 15 Sep 2000 18:37:02 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [e-mail]

> > Without going into the details, I think most parts are wordsmithing
> > or simple grammatical issues.
> 
> The resolution of the 24 comments from Russ is on its way and a
> draft response is being circulated between the co-editors of the
> document. So I should be able to send a reply to Russ and to the
> mailing list before the end of next week.
> 

Thanks, that's sounds reasonable.



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25736 for <[e-mail]>; Fri, 15 Sep 2000 09:06:18 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA02447; Fri, 15 Sep 2000 12:08:39 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220809b5e7f0b278bf@[171.78.30.107]>
In-Reply-To: <69A40A314934D41190C70050DAD7F99063B5FF@MAIL>
References: <69A40A314934D41190C70050DAD7F99063B5FF@MAIL>
Date: Fri, 15 Sep 2000 12:04:16 -0400
To: Mathew  Butler <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: The need for two grades of time data.
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mat,

>(Just a note, I prefer to have my name shortened to 'Mat', not 'Matt'.  Is
>all okay. :>)

Sorry 'bout that!

>
>Federal computer systems have the banner that states that activity on those
>systems may be monitored, etc.  However, the federal law applies to any
>computer system that has any impact at all on interstate commerce.  (Which
>is, to be perfectly honest, any system that downloads a single banner ad
>from the Web, or any system that is purchased from someone else.)  This is
>why the FBI gets involved in prosecuting web site vandalism.

OK.

>Second, with SSH, the bitstream -is- verified as being from the host in
>question.  (Why do you think there are 'host keys'?)  With SSL, the
>bitstream -is- verified as being from the host in question.  (Why do you
>think there are 'server certificates'?)  SSL is the more applicable standard
>here, but it's still a two-way authentication street.

The verification for both SSH and SSL is authentication, but not 
non-repudiation. In SSL, client certs are rarely used. Without their 
use, the strong authentication is just one way, from serve to client. 
User authentication, when performed via password, is not even part of 
SSL; no aspect of the protocol addresses password authentication. If 
client certs are used,  the signature generated by the client, which 
covers a hash of handshake messages, would not be my idea of NR. It 
certainly does not provide NR for the later SSL session, where the 
messages are covered by a MAC generated using a symmetric key that is 
SHARED by both ends of the session. Any application data sent to the 
system, after establishment of the secure session, would thus be 
repudiable.

>Third, there is a presumption that you are aware of the fact that you're
>authorizing whatever digital signature is generated for the purpose that
>it's being generated -- in this case, doing something to give you access to
>whatever it is that you want access to.  You may not be aware of all the
>details, but to expect a common user to be aware of all the details that
>we're trying to specify in PKIX is sheer folly.

The awareness presumption applied to SSL is rather questionable. If a 
user is issued a client cert for authentication with his browser, he 
activates it, and all others he may have, by entering a password once 
per session. (At least that's the way it work in my version of 
Netscape.) Thus the user could find himself vectored to site B as a 
side effect of visiting site A, and have the browser automatically 
log him into site B, without any explicit user authorization to log 
into site B. Hardly informed consent, right?

>The act of attempting to authenticate to a remote system is, by its nature,
>a non-repudiable act.  (Logs are generated, etc, even for attempts that
>provide the wrong authentication token.)  The only difference is that you
>are not uniquely identified by your attempt to log in, if you do not use the
>signature-generation authority of something that you have agreed uniquely
>represents you.  (like a password.)

Look at my example above and reconsider the assertion that logon is 
intrinsically an NR act. Logs maintained by the system are NOT a 
sound technical basis for NR, as they could be tamperer with by the 
system. Technical NR mechanisms are based on designs which, in 
principle., preclude manipulation of the NR evidence by the RP.

>Nothing is -absolutely- secure.  Smart cards will eventually have exploited
>vulnerabilities, as well.  Most users will store their signature keys on
>their PC, because it's easier for them.  (Especially since this work cannot
>specify 'the key MUST NOT be stored on any computer system that is used for
>any other processing', because that's a trust issue and not a validation
>issue.)

Yes, it's jyst a matter of degree. And, by the way, smart cards HAVE 
been exploited and the exploits have been discussed in the public 
literatire for several years.

Steve



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24877 for <[e-mail]>; Fri, 15 Sep 2000 08:33:59 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA07548; Fri, 15 Sep 2000 17:41:11 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA23774; Fri, 15 Sep 2000 17:35:47 +0200
Message-ID: <[e-mail]>
Date: Fri, 15 Sep 2000 17:35:42 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,

> > Russ,
> >
> > I have been away from some time and I picked up your message. I fear
> > that your message, whatever its content is, has been addressed to
> > the wrong mailing list.
> 
> Denis,
> 
> I fear that your answer is not really the most encouraging reaction
> that could have been made. Does this mean that you don't want to
> make any comments or whatever to the content, just because it
> has not been send to the right list.

In the mean time, I have contacted the chairs to tell them I was not
entitled to respond to comments sent to the PKIX mailing list,
unless told to do so by the IESG. The security area Director
responded that we must address Russ's issues before TSP progresses. 
 
> Without going into the details, I think most parts are wordsmithing
> or simple grammatical issues.

The resolution of the 24 comments from Russ is on its way and a
draft response is being circulated between the co-editors of the
document. So I should be able to send a reply to Russ and to the
mailing list before the end of next week.

Denis


Received: from harry.cmr.gov (harry.cmr.gov [140.162.6.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22260 for <[e-mail]>; Fri, 15 Sep 2000 08:20:36 -0700 (PDT)
Received: from dolphin.cmr.gov (dolphin [140.162.3.135]) by harry.cmr.gov (8.9.3/8.9.3) with ESMTP id LAA05191; Fri, 15 Sep 2000 11:21:48 -0400 (EDT)
Received: from cais.com (localhost [127.0.0.1]) by dolphin.cmr.gov (8.9.1b+Sun/8.9.1) with ESMTP id LAA22186; Fri, 15 Sep 2000 11:21:47 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 15 Sep 2000 11:21:47 -0400
From: "Patrick G. Moore" <[e-mail]>
Organization: Center for Monitoring Research
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: The need for two grades of time data.
References: <[e-mail]> <06dd01c01eab$77b44e40$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

todd glassey wrote:
> 
> If there is proofing data included inside the TS as evidentiary content then
> the TST itself can easily be self authenticating.
> 
> The reason that the PKI
> you are discussing has an external TRUST REFERENCE is because it was
> designed that way. There is no reason that the proofing constraints could
> not go into the token as well, then just the "rules on how to interpret the
> token" remain to be defined here.
> 
Fundamental problem here.  Nothing can be self authenticating without an
external reference.  That is why we don't trust self signed certs, even if
they purport to be a CA, without verifying the fingerprint offline. (Never
mind that most people blindly accept the ones that come in thier browsers.)
A painting signed by Picaso means nothing, if no one had ever seen his
signature before, or asked him if he really signed it.  They don't need
to ask him if they are already familiar with his signature.  All the same
logic applies between the wet world and e-world.

Either you trust your TSA, or it's CAs integrity or you don't.  You must
also choose a TSA who will be trusted by the relying party to which you offer
your proof.

Sorry, enough BW.
Pat


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19441 for <[e-mail]>; Fri, 15 Sep 2000 08:06:30 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA22411; Fri, 15 Sep 2000 11:08:47 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220805b5e7e33b4eda@[171.78.30.107]>
In-Reply-To: <05e901c01e85$ecec59d0$020aff0c@tsg1>
References:  <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107 ]><[e-mail]><009301c01d21$be4d5800$020aff0c@tsg1 > <[e-mail]><01c501c01d9b$c3eefe10$020aff0c@tsg1> <v04220804b5e6c23009d7@[171.78.30.107]> <05e901c01e85$ecec59d0$020aff0c@tsg1>
Date: Fri, 15 Sep 2000 11:00:57 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

><snip>
>
>Thats the breakdown between what I am saying and what a number of people are
>hearing. Let me try again, I suggest that PKIX not build protocol that the
>legal or audit people have to declare publically brain dead or worse,
>commercially of less use than we would all like them to be.

We agree on this goal.

>The issue here is that PKIX is moving into the realm of applications level
>decision support instead of core crypto enablement, and with this there are
>the use mdoels that the real world mandates.

There is considerable literature to suggest that the TTP TSA model in 
the TSP spec is adequate.

>
>  > I
>  > maintain that, for the digital signature environment, the laws are
>  > fragmented along national lines and we have no significant body of
>  > case law from which to draw inspiration.
>
>Stop this here. We are not talking about settinglaw or policy here in the
>IETF we have legislature and Government for that. What we are talking about
>is not building technologies that do not answer any particular need in the
>user community.

You maintain that the model upon which TSP is based is inadequate to 
meet the needs of NR support. I see little or no evidence to 
substantiate this claim. Your messages contain vague references but 
nothing concrete. If you provided text from some regulation and show 
how the proposed technology was inadequate, that would be a start. 
However, the laws associated with NR are fragmented and not yet 
tested in courts. So, even if you were to find one such instance in 
some NR regulation, it would not prove that the TSP model is 
generally inadequate.

<snip>

>  > >As to the need for two grades of time. One is simply plumbing and the
>other
>  > >is the water that flows through the pipes. Much care is already given to
>  > >authenticate digital entities and any auditor will tell you that if that
>  > >much care is placed on authenticating abstract data like "Who" then the
>  > >"When" deserves the same or better.
>  >
>  > This analogy is opaque to me.
>
>What does this mean, that you do not understand that time as content
>deserves the same contextual processing that other evedentiary content does?
>
>Or is it the physics issues of how to deploy and audit the deployment of
>time, or that time data's syncghronicity with a National Timing Standard and
>being able to prove so some time in the future through a imple mechanical
>process. What is it that is opaque?

The opacity is a result of your choice of language, e.g., "time as content
deserves the same contextual processing that other [sic] evedentiary 
content does."

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18153 for <[e-mail]>; Fri, 15 Sep 2000 07:36:29 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA17747; Fri, 15 Sep 2000 10:38:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220804b5e7dff18902@[171.78.30.107]>
In-Reply-To: <06d901c01eab$69904f80$020aff0c@tsg1>
References:  <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107 ]><006d01c01d1e$a8403b20$020aff0c@tsg1> <[e-mail]><03a101c01dd0$52afa620$020aff0c@tsg1> <v0422080ab5e6c934afc6@[171.78.30.107]> <062701c01e8c$de010f40$020aff0c@tsg1> <06d901c01eab$69904f80$020aff0c@tsg1>
Date: Fri, 15 Sep 2000 10:31:00 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

NTP is a time distribution system, but not a time stamping system. 
Looking at the latest NTP security draft from Dave Mills, the 
services offered by NTP have not changed in this regard.  Thus a TSA 
might choose to employ NTP, but it need not do so. TSP is flexible in 
allowing a TSA to choose the method(s) that it employs, and in 
allowing the market and the legal system to decide which methods are 
appropriate.

Steve


Received: from SOTTMXS01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16942 for <[e-mail]>; Fri, 15 Sep 2000 07:11:59 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2650.21) id <S954DYBG>; Fri, 15 Sep 2000 10:15:59 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Kwon, YongChul'" <[e-mail]>
Cc: PKIX Working Group <[e-mail]>
Subject: RE: revoking certificate when confirm verify fails
Date: Fri, 15 Sep 2000 10:08:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain

Hi YongChul,

> ----------
> From: 	Kwon, YongChul[SMTP:[e-mail]]
> Sent: 	Friday, September 15, 2000 1:06 AM
> To: 	PKIX Working Group
> Subject: 	revoking certificate when confirm verify fails
> 
> There is such sentence in the bottom of section 2.2.2.2 of RFC-2510 and
> RFC-2510bis.
> 
> (Where verification of the cert confirmation message fails, the RA/CA MUST
> revoke the newly issued certificate if it has been published or otherwise
> made
> available.)
> 
> but, above sentence accepts following situation.
> 
> CA/RA sent certificate as normal certificate - not encrypted and
> CA/RA couldn't receive the confirm message or failed to verify confirm
> message.
> 
> At this time, CA/RA hasn't published this certificate yet it can be
> problem.
> 
> because client was handed certificate itself already!
> and client can use this certificate as if the certificate is correct one.
> 
> I don't know "otherwise made available" means this situation.
> am I correct?
 
Yes, "otherwise made available" includes exactly this situation.  If the
certificate is returned in plaintext, then it is "available" to anyone who
happens to see the message (the requester and any other eavesdroppers on the
line).

Carlisle.



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15258 for <[e-mail]>; Fri, 15 Sep 2000 06:36:46 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA11586; Fri, 15 Sep 2000 15:38:52 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 15 Sep 2000 15:38:52 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA11367; Fri, 15 Sep 2000 15:38:45 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA18879; Fri, 15 Sep 2000 15:38:45 +0200 (MET DST)
Date: Fri, 15 Sep 2000 15:38:45 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [e-mail]

> 
> Russ,
> 
> I have been away from some time and I picked up your message. I fear
> that your message, whatever its content is, has been addressed to
> the wrong mailing list.

Denis,

I fear that your answer is not really the most encouraging reaction
that could have been made. Does this mean that you don't want to
make any comments or whatever to the content, just because it
has not been send to the right list. 

Without going into the details, I think most parts are wordsmithing
or simple grammatical issues.  


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA07176 for <[e-mail]>; Fri, 15 Sep 2000 03:58:03 -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 HAA17352; Fri, 15 Sep 2000 07:00:24 -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-dcs-06.txt
Date: Fri, 15 Sep 2000 07:00:23 -0400
Sender: [e-mail]

--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 Data 
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-06.txt
	Pages		: 48
	Date		: 14-Sep-00
	
This document describes a general Data Validation and Certification
Server (DVCS) and the protocols to be used when communicating with
it.  The Data Validation and Certification Server is a Trusted Third
Party (TTP) that can be used as one component in building reliable
non-repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to assert the validity of signed documents, public key
certificates, and the possession or existence of data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-06.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-dcs-06.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-dcs-06.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-dcs-06.txt

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

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

--OtherAccess--

--NextPart--




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03293 for <[e-mail]>; Fri, 15 Sep 2000 03:12:11 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA09934; Fri, 15 Sep 2000 12:10:58 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 15 Sep 2000 12:10:58 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA10891; Fri, 15 Sep 2000 12:10:56 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA18801; Fri, 15 Sep 2000 12:10:56 +0200 (MET DST)
Date: Fri, 15 Sep 2000 12:10:56 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: The need for two grades of time data.
Cc: [e-mail]

> I want everyone to understand that I am not trying to be a jerk here, I
> probably should have used more benign language - I just think that with the
> sheer number of NTP Servers out there already, that NTP as a common
> timestamping system may actually make a lot of sense and PKIX might not be
> able to stop its use to focus favor on the TSP. That's all.
> 
> T.

Are we getting back to an example of the encoding wars? 
 
I don't think that PKIX regards NTP as a time 'stamping' system.
the NTP network can be a provider of time, and a client may also use
it in order to determine the validity of a time stamp. 

NTP times are used to synchronize clocks, not necessarily to show them
in a court. Once you've set the clock, you're done, or are you
keeping it for saying, I have receive that stamp to set my clock.
Well, when did you set your clock, and to what value. Where's the proof
or evidence? Who cares and when? 

I might be wrong, but when I make an abstract form of what is provided
in BERT, the only difference concerning the time value (besides that
it is in NTP form) is that there is an indication of what source
it came from. If someone believes that this is important, please
make a specification of how to encode such data. I don't think that
the TSA often changes a provider, thus it might be sufficient to
add this to a policy for the moment. 

Transforming an NTP value into a GENERALIZEDTIME doesn't seem to me a
totally impossible task, or if ncessary, one might consider to
just add an OCTETSTRING with an encoded NTP time in there. 

The rest in BERT could be regarded as nih symdrome provoked Sinatra
solution to encode names, certificates, signature values etc. of
information that can be probably already be assembled in other proposed
or existing secured token formats. Sorry for the flame, I'd be glad
to be corrected if my assumption isn't true. 



Peter Sylvester







Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA24564 for <[e-mail]>; Fri, 15 Sep 2000 00:44:25 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA18780; Fri, 15 Sep 2000 09:51:35 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA21042; Fri, 15 Sep 2000 09:46:08 +0200
Message-ID: <[e-mail]>
Date: Fri, 15 Sep 2000 09:46:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: The need for two grades of time data.
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <006d01c01d1e$a8403b20$020aff0c@tsg1> <[e-mail]> <03a101c01dd0$52afa620$020aff0c@tsg1>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Todd,

> Denis,
> I apologize for the length of this response but you hit some hot spots for
> me - and I really dislike the provincial tone this has taken on, including
> my own. It is clear to me that there is emotional content for all concerned
> here and we need to rise above that as Time Stamping is way to
> important to the bigger picture of eBusiness and Audit/.Risk management.
> 
> Before you goon and read the response below and get ticked off  - let me say
> I myself  would support advancing the TSP Draft to Standard 

You are a little bit ahead of your time. BTW, which time reference
are you using ? :-). We are not advancing the TSP Draft to
"Standard", but to "Proposed Standard". It can only be advanced to
"Standard" once it has reached the "Proposed Standard" status and
when other conditions apply.

So I interpret your statement as being implicitely supportive of
advancement to Proposed Standard, and at this time not supportive of
advancement to Standard. Mee too. So let us close this issue.

> if it allowed
> for multiple use models, and updating to address emerging and audit driven
> needs. As it sits now it is too closed and restricted.
> 
> What we have in the TSP now  is a TTP based service model that does not
> authenticate the time data it claims is evidence - so the total reliance on
> the marque is based in proving some nebulous time data instance without a
> proofing model. Might as well be human testimony.
> 
> Your included text starts here
> --------------
> It seems that you are trying to re-open a discussion that took place
> in May 1999 (along BERT). So let me provide you with a copy of some
> E-mails from May 1999 so that we can *definitively* close this
> discussion.
> 
> Denis
> --------------
> 
> Since you have thrown the "this is a closed issue" down, let me say I
> disagree - it is my opinion that this was not decided by the group, or even
> debated openly.

IT IS A CLOSED ISSUE. Let me report the official minutes of the 45
th IETF meeting to prove this (as far as I remember, you were not
present at this meeting).

" Temporal Data Token (M. Duren-WetStone) 

Presentation focused on format for TDT (in the TSA) that helps
attest to the integrity of the time source, i.e., providing a link
to a trusted time source. This approach pushes evidence of time 
source into a token, vs. other, external measures that a TSA 
akes to ensure the accuracy and integrity of its time source.
A claimed feature of this approach is that it allows a client 
to be able to verify the utility (for non-repudiation) of the 
returned token immediately, vs. the deferred verification more 
typical of TSA operation. As with the BERT presentation, the 
speaker was asked about possible intellectual property claims 
nd about the breadth of vendor support for the propose
TDT format. The speaker asserted that he was aware of no IP 
claims, and that he was aware of at least two vendors who had 
expressed interest in this format, although no more than one 
was building products to this spec at this time. The WG Chairs 
and the Security ADs also will need to discuss whether this is 
within the scope of PKIX, before this item progresses. "

Please read very carefully the last sentence.

Then, after the meeting, Stephen Kent and Warwick Ford (i.e. the two
co-chairs of the PKIX WG) decided that BERT was not appropriate for
PKIX. They suggested that it be brought to STIME. It was, and STIME
rejected it as well.

So, PLEASE, leave the bandwith of the PKIX mailing list for other
maters of discussions.

Denis

 
> I understand what the TSP is and does, I think from a commercial standpoint
> this is really not what time stamping systems want to be. Lets answer the
> following questions and see where that leads the group.
> 
> 1)    If the purpose of the time stamping protocol is to enable decision
> support processes by "validating signatures in time", then how is that the
> time data authentication process was overlooked? It seems to me that the
> credibility of the time data is directly tied to the believability resource
> produced by the Signature Validation Process, isn't it?  If so, then why
> would we leave that to an external CPS that was tied to the Host's operating
> environment or OS operation practices???
> 
> 2)    If the purpose of  the timestamp is evidentiary, then the quality of
> the time data, how it is authenticated, where it came from, and who it was
> certified by is critical to the trust process.
> 
> The need for a grade of time data that is nonrepudiated and is traceable to
> the BIPM or UTC /GeT is very important to the big picture and every trust
> process we build. To put our heads in the sand and claim that this is the
> OS's problem or that of the people that operate the system is also
> ludicrous.
> 
> The point is whether you are building an evidentiary system that can stand
> on its own, or one that requires the TSA to validate/use the marques of.
> You use PKI and other technologies to authenticate the source of the
> non-parametric data points, but not the time data. Why? and why cant the
> token stand on its own two feet?
> 
> 3)    Why constrain the system to a TTP architecture only? many of the legal
> processes we do today are based in Ceremony. Notorial, filing a legal
> document, etc. these are all based in ceremony. So the creation of the
> timestamp is essentially that ceremony. that means that the time stamp
> itself is the evidentiary token representing the completion of the
> ceremonial process and so the timestamps by themselves have value and worth
> in token exchange and processing models.
> 
> This is why BERT was so important - and as long as we are talking about the
> BERT...
> 
> BERT
> ------
> I agree with your commentary about how fast BERT was shot down - the BERT
> Token structure is clearly a threat to the TSP in that it does exactly what
> is defined in the three requirements above. Now I do have to admit that the
> initial BERT-1 Token Structure has some interesting problems with its
> granularity representation and a possible potential for the dual-events
> within the same granularity window, but that was fixed in the 2nd generation
> BERT-II  Structure, which I suppose I should file.
> 
> FYI - BERT-II turns the best of the XML and IOTP token processes into a TSP
> Evidentiary Token and not only addresses the content certification, but the
> type of the event as well. BERT-II supports virtually all key or crypto
> techniques and has plugin capabilities for building an event representation
> specific to the end-use needs. Its small  and expandable to also contain the
> content it watermarks as well and with this model, you don't need the Time
> Stamp
> Server just the BERT tool Set to extract or validate any of the components.
> 
> Just follow the use rules and there you are.
> 
> If anyone is interested in the BERT-II token structure prior to the Draft
> being filed in the next 2 weeks, send me a email and I will send the
> preliminary draft to you.
> 
> Todd
> 
> ---- Original Message -----
> From: "Denis Pinkas" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, September 13, 2000 3:57 AM
> Subject: Re: The need for two grades of time data.
> 
> Todd,
> 
> > Thanks for responding Steve, but again the real issue with
> > this concept of evidentiary time is in treating the parametric
> > time data as content rather than control process elements.
> > Once you do that it gets to be obvious that you need a
> > auth/certification stream and chain-of-custody model for that
> > time data to meet these evidentiary needs.
> 
> > So I have to ask - "What is the problem with treating time and
> > perhaps other parametric data like location data, as through
> > it had the same risks with it that the Human or Entity Identity
> > issues that spawned PKIX in the first place? because it does?"
> 
> > We seem to as a group have restricted our relating to time and
> > other parametric evidentiary processes as though they were only
> > part of the plumbing and it just aint so.
> 
> > Any of the data points that are use inside the decision support
> > process protocols that we are building (OCSP, TSP, etc etc etc)
> > are all tied to the requirement of some evidentiary anchor -
> > Someone or something has to sign that top level cert, some key
> > generator has to pump out that key pairing, and that data has been
> > sanctified by PKIX to date as it rightly should, but the use of
> > traditional Control Data points a parts of the larger evidentiary
> > or decision support process warrants that that data have the same
> > integrity as any other.
> 
> > Just my two cents.
> 
> =================================================================
> 
> Object:  Re: Comments on time-stamp-01: Identification of TSA
> Date:    Thu, 27 May 1999 13:55:18 -0400
> From:    Stephen Kent <[e-mail]>
> To:     "Todd S. Glassey - ELN" <[e-mail]>
> Copies:  <[e-mail]>
> 
> 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
> 
> =================================================================
> 
> Object: Re: Comments on time-stamp-01: Identification of TSA
> Date:   Fri, 28 May 1999 11:43:40 +0200
> From:   Denis Pinkas <[e-mail]>
> To:     "Todd S. Glassey - ELN" <[e-mail]>
> Copies: [e-mail]
> 
> 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
> 
> =================================================================
> 
> ... and finally an E-mail sent by Todd to me, not to the PKIX
> mailing list that is worth to mention:
> 
> Object:  Re: Long-term validation of signatures
> Date:    Mon, 26 Apr 1999 14:37:55 -0700
> From:    "Todd S. Glassey" <[e-mail]>
> To:      "Denis Pinkas" <[e-mail]>, "Hans Nilsson"
> <[e-mail]>
> 
> Denis, don't take my commentary wrong.
> The Draft(s) that you Pat, Carlisle, Robert produced are
> FANTASTIC!!!. They represent the first credible mechanism for a
> subsumable timebase service model and thats top-notch.
> 
> (snip)


Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA18545 for <[e-mail]>; Thu, 14 Sep 2000 22:06:17 -0700 (PDT)
Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id e8F55Ka00156 for <[e-mail]>; Fri, 15 Sep 2000 14:05:20 +0900 (KST)
From: "Kwon, YongChul" <[e-mail]>
To: "PKIX Working Group" <[e-mail]>
Subject: revoking certificate when confirm verify fails
Date: Fri, 15 Sep 2000 14:06:55 +0900
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="EUC-KR"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal

There is such sentence in the bottom of section 2.2.2.2 of RFC-2510 and
RFC-2510bis.

(Where verification of the cert confirmation message fails, the RA/CA MUST
revoke the newly issued certificate if it has been published or otherwise
made
available.)

but, above sentence accepts following situation.

CA/RA sent certificate as normal certificate - not encrypted and
CA/RA couldn't receive the confirm message or failed to verify confirm
message.

At this time, CA/RA hasn't published this certificate yet it can be problem.

because client was handed certificate itself already!
and client can use this certificate as if the certificate is correct one.

I don't know "otherwise made available" means this situation.
am I correct?



Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12479 for <[e-mail]>; Thu, 14 Sep 2000 19:13:54 -0700 (PDT)
Received: by MAIL with Internet Mail Service (5.5.2650.21) id <S7HAW8PZ>; Thu, 14 Sep 2000 19:10:57 -0700
Message-ID: <69A40A314934D41190C70050DAD7F99063B5FF@MAIL>
From: Mathew  Butler <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Mathew  Butler <[e-mail]>
Cc: [e-mail]
Subject: RE: The need for two grades of time data.
Date: Thu, 14 Sep 2000 19:10:55 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

(Just a note, I prefer to have my name shortened to 'Mat', not 'Matt'.  Is
all okay. :>)

Federal computer systems have the banner that states that activity on those
systems may be monitored, etc.  However, the federal law applies to any
computer system that has any impact at all on interstate commerce.  (Which
is, to be perfectly honest, any system that downloads a single banner ad
from the Web, or any system that is purchased from someone else.)  This is
why the FBI gets involved in prosecuting web site vandalism.

Second, with SSH, the bitstream -is- verified as being from the host in
question.  (Why do you think there are 'host keys'?)  With SSL, the
bitstream -is- verified as being from the host in question.  (Why do you
think there are 'server certificates'?)  SSL is the more applicable standard
here, but it's still a two-way authentication street.

Third, there is a presumption that you are aware of the fact that you're
authorizing whatever digital signature is generated for the purpose that
it's being generated -- in this case, doing something to give you access to
whatever it is that you want access to.  You may not be aware of all the
details, but to expect a common user to be aware of all the details that
we're trying to specify in PKIX is sheer folly.

The act of attempting to authenticate to a remote system is, by its nature,
a non-repudiable act.  (Logs are generated, etc, even for attempts that
provide the wrong authentication token.)  The only difference is that you
are not uniquely identified by your attempt to log in, if you do not use the
signature-generation authority of something that you have agreed uniquely
represents you.  (like a password.)

Nothing is -absolutely- secure.  Smart cards will eventually have exploited
vulnerabilities, as well.  Most users will store their signature keys on
their PC, because it's easier for them.  (Especially since this work cannot
specify 'the key MUST NOT be stored on any computer system that is used for
any other processing', because that's a trust issue and not a validation
issue.)

-Mat Butler

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, September 14, 2000 4:36 PM
To: Mathew Butler
Cc: [e-mail]
Subject: RE: The need for two grades of time data.


Matt,

>Yes, there is.  Under the rules of the US Code of Federal Regulations,
>"Unauthorized access to computer systems shall be a felony."  When you sign
>an authentication challenge with a private key, you're attesting to the
fact
>that you're authorized to use the private key, and that if the signature is
>accepted by the server, you are (to the best of your knowledge) utilizing
>resources which you are authorized to access.

First, I thought this applied only to federal computer systems, but I 
may be wrong. Second,  signing the authentication challenge is not a 
non-repudiable act. The security function is authentication, an input 
to an access control function. There is no presumption that I am 
aware of what is being signed, because it may be (in some protocols) 
random looking data that was generated under the control of the 
system that issued the challenge.  Worse yet, if this is typical, 
one-way authentication, I don't even know that the challenge was 
issued by the system in question.  So, from a technical perspective, 
I'm comfortable that this is not a legally binding digital signature, 
and that position is consistent with our document on technical 
aspects of NR.

>The same could be said of typing a password to a terminal -- "I am
>authorized to use this password, and if you accept this password, I shall
be
>utilizing resources which I am authorized to access."
>
>The problem is, with passwords the user can't truly take due diligence to
>prevent the theft of their authentication credential.  With PK, they can.

In most respects, this is a quantitative difference, not a 
qualitative one. With SSL or SSH, we usually protect the password in 
transit, if we send it as a raw password. Yes, it's true that I never 
need to share a private key with the system to which I authenticate 
myself, but there are numerous password-based schemes that have the 
same property.  So long as we store private keys in software, which 
is common practice, there are many equivalent ways to steal my 
private key or my password from my PC.

The bottom line is that a real time user authentication process is 
characterized by many features that distinguish it from a NR 
signature process.

Steve


Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09370 for <[e-mail]>; Thu, 14 Sep 2000 17:24:40 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000915002629.STJW6605.mtiwmhc25.worldnet.att.net@tsg1>; Fri, 15 Sep 2000 00:26:29 +0000
Message-ID: <06dd01c01eab$77b44e40$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 17:25:06 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

If there is proofing data included inside the TS as evidentiary content then
the TST itself can easily be self authenticating. 

The reason that the PKI
you are discussing has an external TRUST REFERENCE is because it was
designed that way. There is no reason that the proofing constraints could
not go into the token as well, then just the "rules on how to interpret the
token" remain to be defined here.

> >
> > My vote is that stamps optionally be capable of standing on their own
two
> > feet instead of requiring the external reference.
>
>
> Assuming the TSA gets it's time from a PKI-protected National Time
> Authority, how does that translate into "proofing internal to the TS"?
> If I receive a document apparently timestamped using your PC-attached
> device, what assurance do I have that the device is not only receiving
> time traceable to a National Timing Authority, but actually using that
> time to generate accurate timestamps?  What assurance do I have that
> the document actually was stamped by one of your devices, and not some
> knockoff pretending to be your device?
>
> No stamp can stand on its own two feet.  It is trusted because there
> are external written claims (marketing literature, a Stamp Practices
> Statement, or a Common Criteria Security Target) which are either
> believed on faith or have been validated by a disinterested
> testing/auditing organization.

Not necessarily.

>




Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09195 for <[e-mail]>; Thu, 14 Sep 2000 17:24:16 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000915002605.STFQ6605.mtiwmhc25.worldnet.att.net@tsg1>; Fri, 15 Sep 2000 00:26:05 +0000
Message-ID: <06d901c01eab$69904f80$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1> <[e-mail]><03a101c01dd0$52afa620$020aff0c@tsg1> <v0422080ab5e6c934afc6@[171.78.30.107]> <062701c01e8c$de010f40$020aff0c@tsg1>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 17:24:17 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Stephen and group -
----- Original Message -----

SNIP

> Stephen,
> One simple and elegant solution would be to change the name from "The PKIX
> Time Stamping Protocol" to "The PKIX TTP Time Stamping Protocol", and
allow
> other TS protocols that are not TTP in nature to progress as well.
>
> By the way, If the response is no because we only need one TTP protocol
the
> TSP protocol itself violates that rule. NTP has offered its uses
timestamps
> and many people have used the NTP protocol for timestamping for years.
What
> this means is that are production systems relying on discreet NTP TST's
for
> their validation and this has been going on for at least 8 years that I am
> aware of.
>
> And now that the old-hat NTP 3.x symmetric crypto has given way to the PKI
> based AutoKey, as in the additions recently filed by Dave Mills against
his
> NTP 4,0 Standard, the facility offered by the generic NTP 4.0 PKI Server
> does most if not all of what the TSP wants to do and it authenticates the
> time source. Oh and the real win is that there are already tens of
millions
> of NTP instances deployed out there and whether the PKIX group likes it or
> not its the way it is. So Unicast Timestamping with NTP is something that
> has been available for years but in a somewhat undocumented state.

I want everyone to understand that I am not trying to be a jerk here, I
probably should have used more benign language - I just think that with the
sheer number of NTP Servers out there already, that NTP as a common
timestamping system may actually make a lot of sense and PKIX might not be
able to stop its use to focus favor on the TSP. That's all.

T.

>




Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09089 for <[e-mail]>; Thu, 14 Sep 2000 17:23:26 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000915002515.SSXP6605.mtiwmhc25.worldnet.att.net@tsg1>; Fri, 15 Sep 2000 00:25:15 +0000
Message-ID: <06c801c01eab$4ba59e80$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 17:16:13 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

If there is proofing data included inside the TS as evidentiary content then
the TST itself can easily be self authenticating. The reason that the PKI
you are discussing has an external TRUST REFERENCE is because it was
designed that way. There is no reason that the proofing constraints could
not go into the token as well, then just the "rules on how to interpret the
token" remain to be defined here.

> >
> > My vote is that stamps optionally be capable of standing on their own
two
> > feet instead of requiring the external reference.
>
>
> Assuming the TSA gets it's time from a PKI-protected National Time
> Authority, how does that translate into "proofing internal to the TS"?
> If I receive a document apparently timestamped using your PC-attached
> device, what assurance do I have that the device is not only receiving
> time traceable to a National Timing Authority, but actually using that
> time to generate accurate timestamps?  What assurance do I have that
> the document actually was stamped by one of your devices, and not some
> knockoff pretending to be your device?
>
> No stamp can stand on its own two feet.  It is trusted because there
> are external written claims (marketing literature, a Stamp Practices
> Statment, or a Common Criteria Security Target) which are either
> believed on faith or have been validated by a disinterested
> testing/auditing organization.

Not necessarily.

>



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06787 for <[e-mail]>; Thu, 14 Sep 2000 16:32:17 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA20972; Thu, 14 Sep 2000 19:34:33 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422081cb5e70e8efb10@[171.78.30.107]>
In-Reply-To: <69A40A314934D41190C70050DAD7F99063B5FE@MAIL>
References: <69A40A314934D41190C70050DAD7F99063B5FE@MAIL>
Date: Thu, 14 Sep 2000 19:36:17 -0400
To: Mathew  Butler <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: The need for two grades of time data.
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Matt,

>Yes, there is.  Under the rules of the US Code of Federal Regulations,
>"Unauthorized access to computer systems shall be a felony."  When you sign
>an authentication challenge with a private key, you're attesting to the fact
>that you're authorized to use the private key, and that if the signature is
>accepted by the server, you are (to the best of your knowledge) utilizing
>resources which you are authorized to access.

First, I thought this applied only to federal computer systems, but I 
may be wrong. Second,  signing the authentication challenge is not a 
non-repudiable act. The security function is authentication, an input 
to an access control function. There is no presumption that I am 
aware of what is being signed, because it may be (in some protocols) 
random looking data that was generated under the control of the 
system that issued the challenge.  Worse yet, if this is typical, 
one-way authentication, I don't even know that the challenge was 
issued by the system in question.  So, from a technical perspective, 
I'm comfortable that this is not a legally binding digital signature, 
and that position is consistent with our document on technical 
aspects of NR.

>The same could be said of typing a password to a terminal -- "I am
>authorized to use this password, and if you accept this password, I shall be
>utilizing resources which I am authorized to access."
>
>The problem is, with passwords the user can't truly take due diligence to
>prevent the theft of their authentication credential.  With PK, they can.

In most respects, this is a quantitative difference, not a 
qualitative one. With SSL or SSH, we usually protect the password in 
transit, if we send it as a raw password. Yes, it's true that I never 
need to share a private key with the system to which I authenticate 
myself, but there are numerous password-based schemes that have the 
same property.  So long as we store private keys in software, which 
is common practice, there are many equivalent ways to steal my 
private key or my password from my PC.

The bottom line is that a real time user authentication process is 
characterized by many features that distinguish it from a NR 
signature process.

Steve



Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06050 for <[e-mail]>; Thu, 14 Sep 2000 15:55:36 -0700 (PDT)
Received: by MAIL with Internet Mail Service (5.5.2650.21) id <S7HAW8JX>; Thu, 14 Sep 2000 15:52:39 -0700
Message-ID: <69A40A314934D41190C70050DAD7F99063B5FE@MAIL>
From: Mathew  Butler <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, todd glassey <[e-mail]>
Cc: [e-mail]
Subject: RE: The need for two grades of time data.
Date: Thu, 14 Sep 2000 15:52:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Yes, there is.  Under the rules of the US Code of Federal Regulations,
"Unauthorized access to computer systems shall be a felony."  When you sign
an authentication challenge with a private key, you're attesting to the fact
that you're authorized to use the private key, and that if the signature is
accepted by the server, you are (to the best of your knowledge) utilizing
resources which you are authorized to access.

The same could be said of typing a password to a terminal -- "I am
authorized to use this password, and if you accept this password, I shall be
utilizing resources which I am authorized to access."

The problem is, with passwords the user can't truly take due diligence to
prevent the theft of their authentication credential.  With PK, they can.

-Mat Butler

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, September 14, 2000 11:22 AM
To: todd glassey
Cc: [e-mail]
Subject: Re: The need for two grades of time data.

<snip>

>Sure they do. Anything I sign with my Digital Cert is represented as my wet
>signature under the law . Making it essentially  a legal instrument of my
>agency. That's just the way it is.


No, it's not. I sign authentication challenges with a private key and 
there is no legal (NR) implication associated with that.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04132 for <[e-mail]>; Thu, 14 Sep 2000 14:26:46 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA12798; Thu, 14 Sep 2000 17:29:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220817b5e6e9d95b20@[171.78.30.107]>
In-Reply-To: <05f901c01e8a$356b52c0$020aff0c@tsg1>
References: <[e-mail]> <v04220800b5e687a247f9@[171.78.30.107]> <05f901c01e8a$356b52c0$020aff0c@tsg1>
Date: Thu, 14 Sep 2000 17:22:50 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>----- Original Message -----
>From: "Stephen Kent" <[e-mail]>
>To: "Bob Jueneman" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, September 14, 2000 11:26 AM
>Subject: Re: The need for two grades of time data.
>
>
>  > Bob,
>  >
>  > >I believe that what Todd is trying to say is that the question isn't,
>  > >"What time is it?" but rather "What time is it, and who says so, and
>  > >why should anyone believe them?"
>  >
>  > Since Todd agrees with Bob's concise translation, I think this is really
>easy:
>  >
>  > - by choosing to use the service of a given TSA, the client
>  > is relying on the TSA to state the time
>  >
>  > - the TSA has a cert to identity it, and that cert is issued
>  > by a CA, who vouches for the accuracy of the ID, consistent with our
>  > usual CA model
>  >
>  > - a TSA publishes the technical basis for its time keeping,
>  > which provides the basis for the last value judgement
>
>How is this available to the Time Validator in the Client? I want to check
>the time sources inline to make sure all is OK.

I don't know what a "Time Validator" is, but I'll make a guess. 
First, the software checks the TSA's signature on the response, to 
verify its integrity and data origin authentication. It also checks 
the nonce for timeliness.  As is the case with CA policies, one would 
expect client to be configured with a list of TSA policy OIDs, to 
confirm that the time stamp is issued under a policy that, according 
to the folks who configured the software for this app, is appropriate 
for the app.  Does that address your question?

Steve



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02900 for <[e-mail]>; Thu, 14 Sep 2000 13:45:38 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000914204725.PLNW6605.mtiwmhc25.worldnet.att.net@tsg1>; Thu, 14 Sep 2000 20:47:25 +0000
Message-ID: <062701c01e8c$de010f40$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1> <[e-mail]><03a101c01dd0$52afa620$020aff0c@tsg1> <v0422080ab5e6c934afc6@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 13:38:42 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Stephen,
One simple and elegant solution would be to change the name from "The PKIX
Time Stamping Protocol" to "The PKIX TTP Time Stamping Protocol", and allow
other TS protocols that are not TTP in nature to progress as well.

By the way, If the response is no because we only need one TTP protocol the
TSP protocol itself violates that rule. NTP has offered its uses timestamps
and many people have used the NTP protocol for timestamping for years. What
this means is that are production systems relying on discreet NTP TST's for
their validation and this has been going on for at least 8 years that I am
aware of.

And now that the old-hat NTP 3.x symmetric crypto has given way to the PKI
based AutoKey, as in the additions recently filed by Dave Mills against his
NTP 4,0 Standard, the facility offered by the generic NTP 4.0 PKI Server
does most if not all of what the TSP wants to do and it authenticates the
time source. Oh and the real win is that there are already tens of millions
of NTP instances deployed out there and whether the PKIX group likes it or
not its the way it is. So Unicast Timestamping with NTP is something that
has been available for years but in a somewhat undocumented state.

My point is that there is already one fully entrenched TS enable protocol
that has successfully had global deployment accomplished for it.

PKIX might want to take that into account.  The concept that by rolling the
rev levels of NTP in every Cisco Router magically becoming a timestamper
capable of legally binding marques.. seems to me to be the real win for
timestamping.

Just my two cents

Todd

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>; <[e-mail]>
Sent: Thursday, September 14, 2000 12:35 PM
Subject: Re: The need for two grades of time data.


> Todd,
>
> >Denis,
> >I apologize for the length of this response but you hit some hot spots
for
> >me - and I really dislike the provincial tone this has taken on,
including
> >my own. It is clear to me that there is emotional content for all
concerned
> >here and we need to rise above that as Time Stamping is way to
> >important to the bigger picture of eBusiness and Audit/.Risk management.
> >
> >Before you goon and read the response below and get ticked off  - let me
say
> >I myself  would support advancing the TSP Draft to Standard if it allowed
> >for
> >multiple use models, and updating to address emerging and audit driven
> >needs. As it sits now it is too closed and restricted.
>
> I.e., it does not support the model you proposed.
>
> >
> >What we have in the TSP now  is a TTP based service model that does not
> >authenticate the time data it claims is evidence - so the total reliance
on
> >the marque is based in proving some nebulous time data instance without a
> >proofing model. Might as well be human testimony.
>
> The use of a TTP as a basis for time stamping is consistent with the
> use of a TTP as a CA. In each case, clients evaluate the policies and
> procedures employed by the TTP and decide if they are sufficient for
> the application context of interest. there is no single, right set of
> policies and procedures that is adequate for all applications, and
> thus we leave it to the clients to decide what is good enough in each
> case.  A government may choose to establish minimum criteria for TTPs
> to operate WITHIN ITS JURISDICTION, but that is outside the scope of
> what the IETF does.
>
> >Your included text starts here
> >--------------
> >It seems that you are trying to re-open a discussion that took place
> >in May 1999 (along BERT). So let me provide you with a copy of some
> >E-mails from May 1999 so that we can *definitively* close this
> >discussion.
> >
> >Denis
> >--------------
> >
> >Since you have thrown the "this is a closed issue" down, let me say I
> >disagree - it is my opinion that this was not decided by the group, or
even
> >debated openly.
>
> Yes, it was, and we're past that point.
>
>
> <snip>
>
> I'll cut to the chase, for those who may have trouble deciphering
> what Todd is saying.
>
> Todd's model calls for a secure, highly accurate time stamp device to
> be inserted into every workstation that generates a document that
> needs to be time stamped.  The device, if one has confidence in it
> and the system by which it receive its time source, provides the
> "authenticated" time source that Todd alludes to. Todd has been
> affiliated with a company that manufactures a device which meets the
> criteria he has established. TSP does not encompass this model, hence
> the problem.
>
> I don't mean to pass judgement on the model Todd espouses, or on
> devices that implement it. However, the model that TSP supports is
> one that has been discussed in the literature for at least 15, maybe
> 25, years, and which is very widely accepted. It is a simple one,
> that appears to be free of IP claims at this time, although certain
> implementations of a TSA might be covered by patents.
>
> Most folks I have spoken with do not believe that most business
> transactions require extremely precise time stamps, accurate to a
> millisecond. Most folks I have spoken with do believe that the TTP
> model encompassed by TSP is sufficient for most business needs. Most
> believe that a TSA will be able to employ a set of mechanisms to
> ensure reasonable accuracy and protect against undetected tampering
> with the clock, so as to convince clients that it is reasonable to
> rely on the TSA.  Some means of doing this may be patented, other
> probably are not. The market will decide what's good enough, and the
> courts will eventually decide if the market got it right.
>
> Note that in many business contexts, the adequacy of information
> security measures, with regard to legal liability, is determined not
> on an absolute scale, but based on what is common, accepted practice.
> So, if most businesses use NT as a platform for hosting a security
> sensitive application, you are not legally negligent for doing so,
> even if security experts point out that there are better choices. In
> that light, the TTP TSA model, if accepted in the marketplace, may
> well become a definition of "good enough."
>
> Steve
>
>



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02868 for <[e-mail]>; Thu, 14 Sep 2000 13:45:34 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id QAA24588 for <[e-mail]>; Thu, 14 Sep 2000 16:32:04 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 14 Sep 2000 16:40:55 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: The need for two grades of time data.
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: MRZyvss2bvykIbREBwRKeA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "todd glassey" <[e-mail]>
...
> >
> > - by choosing to use the service of a given TSA, the client
> > is relying on the TSA to state the time
> >
> > - the TSA has a cert to identity it, and that cert is issued
> > by a CA, who vouches for the accuracy of the ID, consistent with our
> > usual CA model
> 
> One of the use issues here then is whether the proofing is internal to the
> TS or whether the TS mandates an external Stamp Practices Statement to
> process.
> 
> My vote is that stamps optionally be capable of standing on their own two
> feet instead of requiring the external reference.


Assuming the TSA gets it's time from a PKI-protected National Time
Authority, how does that translate into "proofing internal to the TS"?
If I receive a document apparently timestamped using your PC-attached
device, what assurance do I have that the device is not only receiving
time traceable to a National Timing Authority, but actually using that
time to generate accurate timestamps?  What assurance do I have that
the document actually was stamped by one of your devices, and not some
knockoff pretending to be your device?

No stamp can stand on its own two feet.  It is trusted because there
are external written claims (marketing literature, a Stamp Practices
Statment, or a Common Criteria Security Target) which are either
believed on faith or have been validated by a disinterested
testing/auditing organization.



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02285 for <[e-mail]>; Thu, 14 Sep 2000 13:26:35 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000914202823.PDVT6605.mtiwmhc25.worldnet.att.net@tsg1>; Thu, 14 Sep 2000 20:28:23 +0000
Message-ID: <05f901c01e8a$356b52c0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <v04220800b5e687a247f9@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 13:12:52 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, September 14, 2000 11:26 AM
Subject: Re: The need for two grades of time data.


> Bob,
>
> >I believe that what Todd is trying to say is that the question isn't,
> >"What time is it?" but rather "What time is it, and who says so, and
> >why should anyone believe them?"
>
> Since Todd agrees with Bob's concise translation, I think this is really
easy:
>
> - by choosing to use the service of a given TSA, the client
> is relying on the TSA to state the time
>
> - the TSA has a cert to identity it, and that cert is issued
> by a CA, who vouches for the accuracy of the ID, consistent with our
> usual CA model
>
> - a TSA publishes the technical basis for its time keeping,
> which provides the basis for the last value judgement

How is this available to the Time Validator in the Client? I want to check
the time sources inline to make sure all is OK.

>
> So, if the goal is to answer Bob's questions, I think we're done.  If
> one believes that we should move on to establishing criteria for
> different grades of time stamps, you're probably subscribed to the
> wrong WG list, and the wrong standards body, i.e., the IETF is not in
> the business of generating assurance standards of this sort.

Its not the standards themselves we are generating its the process of
enabling them to be put in place by adding the ability to certify the time
data in the time stamp independantly of the stamp as a total entity.

>
> Steve
>



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01463 for <[e-mail]>; Thu, 14 Sep 2000 12:59:59 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 14 Sep 2000 13:02:11 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 14 Sep 2000 13:02:11 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <SZY3K4TJ>; Thu, 14 Sep 2000 13:01:38 -0700
Content-return: allowed
Date: Thu, 14 Sep 2000 13:01:38 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: The need for two grades of time data.
To: "'Stephen Kent'" <[e-mail]>, Mathew Butler <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

Steve Kent said:

> Let me give a simple, direct, analogy analogy. We don't say (in 2459) 
> that a CA should or must use a FIPS 140-1 certified crypto module to 
> protect its private signature keys. This is outside the scope of our 
> standard, and it is a very significant aspect of the confidence that 
> a client would place in a CA.

Two more examples:

1. Section 6.1 of RFC 2459 does not define how a public key may be trusted:

"The text assumes that the trusted public key (and related information) is
contained in a "self-signed" certificate.  This simplifies the description
of the path processing procedure.  Note that the signature on the
self-signed certificate does not provide any security services.  The trusted
public key (and related information) may be obtained in other formats; the
information is trusted because of other procedures used to obtain and
protect it."

2. RFC 2459 does not even specify how a signature is generated (e.g., via a
monolithic or fragmented private key).

In this way RFC 2459 does its job while allowing others to do their jobs.

Frank


Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01113 for <[e-mail]>; Thu, 14 Sep 2000 12:56:11 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000914195758.OSBT6605.mtiwmhc25.worldnet.att.net@tsg1>; Thu, 14 Sep 2000 19:57:58 +0000
Message-ID: <05eb01c01e85$f5d5b140$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1><v04220803b5e548bbeeb9@[171.78.30.107]><01d901c01d9e$7d678b30$020aff0c@tsg1><[e-mail]> <01f101c01da4$1b7c58f0$020aff0c@tsg1> <v04220807b5e6c6bc1b32@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 12:49:05 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Stephen - Response inline below.


SNIP

> >
> >
> >  > > we ignore the need to provide proofing as to what the time data is
and
> >  > > where it came from
> >  >
> >  > This makes sense.  It also reinforces my belief that it doesn't
belong
> >  > in the IETF any more than proof that IBM.COM really is, IBM. :)
> >
> >Except that what you are now talking about is operating the trust process
> >rather than architecting it, and of course the IETF is not a commercial
> >trust provider.

What I meant is that the above example was particular to the operations of a
Trust Business model rather than the process of designing one which is what
I thought we were up to. That is the stating that IBM.COM is actually
IBM.COM is part of a real worlds operations process not a technological one.

> > That goes without saying. the issue here is in architecing
> >systems that do not support the needs of current and obviously emerging
> >laws, standards, and BCP models, and since we set so few of those in the
> >Techno Puratory of the PKIX WG we ned to be aware of them above us. Heck,
> >even the forges of the underworld took input from Zeus.

I was watching the Baron von Munchahusen the other night and thinking to the
Uma Thermond scene where she is dancing away with the Baron while Lucifer is
getting madder and madder on the floor. That is the source of this analogy.

>
> By Jove, this is hard to parse! Note that PKIX also has not chosen to
> generate a set of standards for CA operation, defining different
> grades of "trust."  A BCP is out of the question at this point,
> because there is insufficient experience to generate such a document
> for a TSP.  It might be called a BCS (Best Current Speculation), but
> the IETF does not publish BCS's.

I apologize. My thoughts get jumbled sometimes.

>
> >  > > In fact that the X509 Digitally Signed Documents now automatically
have
> >  > > legal consequence here in the States, in my mind opens a whole new
realm
> >  > > of requirements for us to have to take into account. Does this
explain
> >  > > what I mean?
> >  >
> >  > They don't automatically have legal consequence; they lost the
automatic
> >  > non-legal status.
> >
> >Sure they do. Anything I sign with my Digital Cert is represented as my
wet
> >signature under the law . Making it essentially  a legal instrument of my
> >agency. That's just the way it is.
>
> No, it's not. I sign authentication challenges with a private key and
> there is no legal (NR) implication associated with that.

Yes it is  - and I think you are dead wrong here - The document still has
your legally binding signature process attached to/on it. If the document is
not a one of Legal Conveyance, i.e some instrument, then the signature holds
no more importance than the signing of this note, but if it were a contract,
then the same signature would be evidentiary in form and binding.

The point is that anything signed with a DS now has the potential of being
legally binding in a contractural manner and that also needs to be taken
into account with the TS Protocol.

>
> Steve
>



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01072 for <[e-mail]>; Thu, 14 Sep 2000 12:55:57 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000914195743.ORZP6605.mtiwmhc25.worldnet.att.net@tsg1>; Thu, 14 Sep 2000 19:57:43 +0000
Message-ID: <05e901c01e85$ecec59d0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Ben Laurie" <[e-mail]>, "Rich Salz" <[e-mail]>, <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><[e-mail]><009301c01d21$be4d5800$020aff0c@tsg1> <[e-mail]><01c501c01d9b$c3eefe10$020aff0c@tsg1> <v04220804b5e6c23009d7@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 12:35:11 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Ben Laurie" <[e-mail]>; "Rich Salz" <[e-mail]>;
<[e-mail]>
Sent: Thursday, September 14, 2000 11:27 AM
Subject: Re: The need for two grades of time data.


> Todd,
>
> >Ben, I have to respond on two subjects here -
> >Nobody is asking the IETF to be a COP or to do squat about actually
> >enforcing laws; but for PKIX in particular to continue to develop
protocols
> >that do not take into account that there may be some legal precedent or
> >issue with the use of its Protocols, then PKIX is negligent, IMHO and
> >unfortunately so would its members and management be in my opinion if
they
> >did nothing about this.
>
> We seem to be talking past one another here.  You suggest that PKIX
> develop protocols that take into account laws and legal precedents.


No I do not.

Thats the breakdown between what I am saying and what a number of people are
hearing. Let me try again, I suggest that PKIX not build protocol that the
legal or audit people have to declare publically brain dead or worse,
commercially of less use than we would all like them to be.

The issue here is that PKIX is moving into the realm of applications level
decision support instead of core crypto enablement, and with this there are
the use mdoels that the real world mandates.

> I
> maintain that, for the digital signature environment, the laws are
> fragmented along national lines and we have no significant body of
> case law from which to draw inspiration.

Stop this here. We are not talking about settinglaw or policy here in the
IETF we have legislature and Government for that. What we are talking about
is not building technologies that do not answer any particular need in the
user community.

> Since the IETF does not want
> to create standards that are parochial, and because there is
> considerable variation here, it seems appropriate to NOT tailor our
> work to any existing body of regulations.

Or likewise find that our work is invalidated because of existing ones.

>
> >Bluntly - If you knowingly say "that is not important to me as I only
design
> >the process model", then when that process model gets blown out  of the
> >water by an auditor, we collectively look pretty stupid.
>
> Don't speak for the Wg as a while when you say that :-).

Steven You are the chair here with Tim and what you say carries a lot of
weight. Lets face it.

>
> >What is PKIX's problem with realizing that it has a responsibility to the
> >community it serves, and that has nothing to do with its members? The
> >reality is that the pace in the PKI world is now starting to pick up to
the
> >point where things are going to get mooshed, and bluntly we can save
> >ourselves a lot of effort and worry about end use applicability and
> >requirements by just adding the Applicability Documents to our efforts.
This
> >is part of enabling the people that use our work to make determinations
on
> >its applicability - unless that is not what the IETF or PKIX as a
collective
> >wants...
>
> I have to be blunt here too. What really seems to be going on is that
> you have previously proposed a time stamping model that is not
> congruent with what the WG has decided to standardize via TSP. Denis
> alluded to this in his message about BERT, which this WG rejected
> over a year ago, and which was rejected by the STIME WG as well. Your
> most recent response to Denis confirms this.
>
> Let me clarify, in my role as co-chair: the WG rejected BERT.

No it did not. You and one or two others specific to this argument made that
decison and the Archive clearly replays this to anyone that looks. There was
never a Poll taken anywhere. Lets get that straight.

If anyone has any concern regarding that, they might want to look it up in
the archive. I chose at that time to not argue with the management of the
WG. Now that the same draft is stuck at the Standard's Gate its time to
speak up.

>
> >As to the need for two grades of time. One is simply plumbing and the
other
> >is the water that flows through the pipes. Much care is already given to
> >authenticate digital entities and any auditor will tell you that if that
> >much care is placed on authenticating abstract data like "Who" then the
> >"When" deserves the same or better.
>
> This analogy is opaque to me.

What does this mean, that you do not understand that time as content
deserves the same contextual processing that other evedentiary content does?

Or is it the physics issues of how to deploy and audit the deployment of
time, or that time data's syncghronicity with a National Timing Standard and
being able to prove so some time in the future through a imple mechanical
process. What is it that is opaque?

>
> Steve
>
>



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00557 for <[e-mail]>; Thu, 14 Sep 2000 12:37:11 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA27931; Thu, 14 Sep 2000 15:39:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080ab5e6c934afc6@[171.78.30.107]>
In-Reply-To: <03a101c01dd0$52afa620$020aff0c@tsg1>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <006d01c01d1e$a8403b20$020aff0c@tsg1> <[e-mail]> <03a101c01dd0$52afa620$020aff0c@tsg1>
Date: Thu, 14 Sep 2000 15:35:17 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Denis,
>I apologize for the length of this response but you hit some hot spots for
>me - and I really dislike the provincial tone this has taken on, including
>my own. It is clear to me that there is emotional content for all concerned
>here and we need to rise above that as Time Stamping is way to
>important to the bigger picture of eBusiness and Audit/.Risk management.
>
>Before you goon and read the response below and get ticked off  - let me say
>I myself  would support advancing the TSP Draft to Standard if it allowed
>for
>multiple use models, and updating to address emerging and audit driven
>needs. As it sits now it is too closed and restricted.

I.e., it does not support the model you proposed.

>
>What we have in the TSP now  is a TTP based service model that does not
>authenticate the time data it claims is evidence - so the total reliance on
>the marque is based in proving some nebulous time data instance without a
>proofing model. Might as well be human testimony.

The use of a TTP as a basis for time stamping is consistent with the 
use of a TTP as a CA. In each case, clients evaluate the policies and 
procedures employed by the TTP and decide if they are sufficient for 
the application context of interest. there is no single, right set of 
policies and procedures that is adequate for all applications, and 
thus we leave it to the clients to decide what is good enough in each 
case.  A government may choose to establish minimum criteria for TTPs 
to operate WITHIN ITS JURISDICTION, but that is outside the scope of 
what the IETF does.

>Your included text starts here
>--------------
>It seems that you are trying to re-open a discussion that took place
>in May 1999 (along BERT). So let me provide you with a copy of some
>E-mails from May 1999 so that we can *definitively* close this
>discussion.
>
>Denis
>--------------
>
>Since you have thrown the "this is a closed issue" down, let me say I
>disagree - it is my opinion that this was not decided by the group, or even
>debated openly.

Yes, it was, and we're past that point.


<snip>

I'll cut to the chase, for those who may have trouble deciphering 
what Todd is saying.

Todd's model calls for a secure, highly accurate time stamp device to 
be inserted into every workstation that generates a document that 
needs to be time stamped.  The device, if one has confidence in it 
and the system by which it receive its time source, provides the 
"authenticated" time source that Todd alludes to. Todd has been 
affiliated with a company that manufactures a device which meets the 
criteria he has established. TSP does not encompass this model, hence 
the problem.

I don't mean to pass judgement on the model Todd espouses, or on 
devices that implement it. However, the model that TSP supports is 
one that has been discussed in the literature for at least 15, maybe 
25, years, and which is very widely accepted. It is a simple one, 
that appears to be free of IP claims at this time, although certain 
implementations of a TSA might be covered by patents.

Most folks I have spoken with do not believe that most business 
transactions require extremely precise time stamps, accurate to a 
millisecond. Most folks I have spoken with do believe that the TTP 
model encompassed by TSP is sufficient for most business needs. Most 
believe that a TSA will be able to employ a set of mechanisms to 
ensure reasonable accuracy and protect against undetected tampering 
with the clock, so as to convince clients that it is reasonable to 
rely on the TSA.  Some means of doing this may be patented, other 
probably are not. The market will decide what's good enough, and the 
courts will eventually decide if the market got it right.

Note that in many business contexts, the adequacy of information 
security measures, with regard to legal liability, is determined not 
on an absolute scale, but based on what is common, accepted practice. 
So, if most businesses use NT as a platform for hosting a security 
sensitive application, you are not legally negligent for doing so, 
even if security experts point out that there are better choices. In 
that light, the TTP TSA model, if accepted in the marketplace, may 
well become a definition of "good enough."

Steve



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00123 for <[e-mail]>; Thu, 14 Sep 2000 12:25:29 -0700 (PDT)
Received: from tsg1 ([12.72.112.203]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000914192716.OGAB6605.mtiwmhc25.worldnet.att.net@tsg1>; Thu, 14 Sep 2000 19:27:16 +0000
Message-ID: <05ca01c01e81$abf8d600$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Mathew  Butler" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
References: <69A40A314934D41190C70050DAD7F99063B5FA@MAIL>
Subject: Re: The need for two grades of time data.
Date: Thu, 14 Sep 2000 12:22:03 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

More inline below -
----- Original Message -----
From: "Mathew Butler" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>; "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, September 14, 2000 11:36 AM
Subject: RE: The need for two grades of time data.


 SNIP

>
> (My opinion is that if we give the lawyers something that they -can't-
> bicker over, then they can go off and leave us alone while we do other
> things.  Otherwise, there will be demand in the future for the same type
of
> 'certification of time' as I'm talking about -- which is exactly what the
> TSA is supposed to provide, but which is not going to be certified
> elsewise.)
>
> -Mat
>
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Thursday, September 14, 2000 11:26 AM
> To: Bob Jueneman
> Cc: [e-mail]
> Subject: Re: The need for two grades of time data.
>
>
> Bob,
>
> >I believe that what Todd is trying to say is that the question isn't,
> >"What time is it?" but rather "What time is it, and who says so, and
> >why should anyone believe them?"
>
> Since Todd agrees with Bob's concise translation, I think this is really
> easy:

One solution would be to add some data. perhaps in the Timestamp as a
content_header that is added to talk of whcih of these three classes of
items the TS contains and/or how to intrpret it. Myself I think this would
be very valuable and would be worth the overhead on the per marque basis.

Just a thought.

>
> - by choosing to use the service of a given TSA, the client
> is relying on the TSA to state the time
>
> - the TSA has a cert to identity it, and that cert is issued
> by a CA, who vouches for the accuracy of the ID, consistent with our
> usual CA model

One of the use issues here then is whether the proofing is internal to the
TS or whether the TS mandates an external Stamp Practices Statement to
process.

My vote is that stamps optionally be capable of standing on their own two
feet instead of requiring the external reference.

>
> - a TSA publishes the technical basis for its time keeping,
> which provides the basis for the last value judgement

Also the TSA may not be the source of the time and to make this TSA's,
marques comparable to those of other TSA's that needs to be addressed I
think.

I think that the TSA itself would not, from a trust perspective, want to be
its own source of time data. It would want to be a commercial or private
user of some higher timing authorites Time Resource like that provided by
the new PKI extensions to NTP.

>

Todd




Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29728 for <[e-mail]>; Thu, 14 Sep 2000 12:20:59 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 14 Sep 2000 12:23:15 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 14 Sep 2000 12:23:15 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <SZY3K4NQ>; Thu, 14 Sep 2000 12:22:43 -0700
Content-return: allowed
Date: Thu, 14 Sep 2000 12:22:42 -0700
From: Peter Williams <[e-mail]>
Subject: RE: The need for two grades of time data.
To: Bob Jueneman <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/signed;	protocol="application/x-pkcs7-signature"; micalg=SHA1;	boundary="----=_NextPart_000_0000_01C01E45.A8EC5090"

This is a multi-part message in MIME format.

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

To sidestep the CA-oriented control model for grades of time
distribution, and stay within IETF compliance guidelines, what a 
TSA can do is use a Validation Authority (VA) to provide an 
OCSP response to the relying party.  This OCSP response attests to a 
status of Steve's TSA certificate, as normal. The VA's policy can be 
tuned to the needs of the relying parties, however. And, these
parties require more than the assurance of the TSA's network 
identity when relying upon time for security, according to Todd.

Any VA can be tuned to the needs of the relying parties 
trust model. That is, it can base its OCSP response off of 
(a) the CA repository of certificate management information
(b) one or more CRLs issued by a CRL issuer
(c) "other information" pertinent to the reliance model

The great thing about separating CAs from VAs 
is that we get application-specific, and party--specific
signed-transaction reliance models, for free. Lets apply 
now what IETF has given us:

As per IETF standardized options, using private OCSP extensions,
the augmented information in the OCSP response (issued by a VA
acting in support of a high-grade TSP policy) can be:
"Todd's evidence trail"! As Steve said, this information
is private to the TSA's policy, and is not necessarily the 
subject of IETF standardization. Local security
policy is, by definition, outside IETF
scope.

These evidentiary objects can, if you believe Todd's marketing, 
authenticate & qualify the *source* of the timing information 
values. The TSA agent originates in its signed
response msg a message bearing these values: the OCSP
response bears the "evidence" that enables a relying
party to obtain a supporting proof trail for the TSA response.
This (apparently) shows to third-parties that the TSA had 
access to a reliable time source, when preparing its 
signed response.

Once we do this, we can have n levels of time quality,
and n systems (some patented probably) for proving 
access to a reliable time source.

The user is insulated from patents, but can leverage
the proprietary timing-evidences, when there is value,
by choosing which VA to use.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, September 14, 2000 11:26 AM
To: Bob Jueneman
Cc: [e-mail]
Subject: Re: The need for two grades of time data.


Bob,

>I believe that what Todd is trying to say is that the question isn't,
>"What time is it?" but rather "What time is it, and who says so, and
>why should anyone believe them?"

Since Todd agrees with Bob's concise translation, I think this is really
easy:

	- by choosing to use the service of a given TSA, the client 
is relying on the TSA to state the time

	- the TSA has a cert to identity it, and that cert is issued 
by a CA, who vouches for the accuracy of the ID, consistent with our 
usual CA model

	- a TSA publishes the technical basis for its time keeping, 
which provides the basis for the last value judgement

So, if the goal is to answer Bob's questions, I think we're done.  If 
one believes that we should move on to establishing criteria for 
different grades of time stamps, you're probably subscribed to the 
wrong WG list, and the wrong standards body, i.e., the IETF is not in 
the business of generating assurance standards of this sort.

Steve

------=_NextPart_000_0000_01C01E45.A8EC5090
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE4TCCBN0w
ggSHoAMCAQICCmFGnFQAAAAABDAwDQYJKoZIhvcNAQEFBQAwgZsxIDAeBgkqhkiG9w0BCQEWEXdp
bGRpZEB3aWxkaWQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEPMA0GA1UE
BxMGVmVuaWNlMQ8wDQYDVQQKEwZXaWxkSUQxIjAgBgNVBAsTGVRvdGFsbHkgRnJlZSBEaWdpdGFs
IEkuRC4xDzANBgNVBAMTBldpbGRJRDAeFw0wMDA4MzAwMTQ4MzZaFw0wMDA5MjkwMTU4MzZaMGAx
IjAgBgkqhkiG9w0BCQEWE3BldGVyd0B2YWxpY2VydC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTEQMA4GA1UEBxMHRnJlbW9udDEOMAwGA1UEAxMFUGV0ZXIwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAMW8EUTQVXAVF9IVzKUUd8qetmKkvqT9/Dxnp1E0lIvdogzbS4Jh8bvROju4C6gG
Ep/pBHHX+2i7JoDhisXTXXy0PEqW3yg0hQyEOQiOlAFqs+DAOizlR9RVOWsNgMtWAOLUVlt69ZGi
2aUWMpqpKCwZo/zIpnofu5CQPujOBvXRAgMBAAGjggKhMIICnTAOBgNVHQ8BAf8EBAMCBPAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR0Yezt69JX/BHQFUJcfE8nuFvm
xTCB1wYDVR0jBIHPMIHMgBQVLSR/WI70zcWFy2Vw0MyXTdFFP6GBoaSBnjCBmzEgMB4GCSqGSIb3
DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVl
IERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEghBYYc07qTXLu0dEUcR2pp/pMIGRBgNVHR8E
gYkwgYYwQKA+oDyGOmh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5y
b2xsL1dpbGRJRC5jcmwwQqBAoD6GPGZpbGU6Ly9cXGRhbDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4u
Y29tXENlcnRFbnJvbGxcV2lsZElELmNybDCB3gYIKwYBBQUHAQEEgdEwgc4wZAYIKwYBBQUHMAKG
WGh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5yb2xsL2RhbDAwMjA4
MDN3MDAxLmRhdGFyZXR1cm4uY29tX1dpbGRJRC5jcnQwZgYIKwYBBQUHMAKGWmZpbGU6Ly9cXGRh
bDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4uY29tXENlcnRFbnJvbGxcZGFsMDAyMDgwM3cwMDEuZGF0
YXJldHVybi5jb21fV2lsZElELmNydDANBgkqhkiG9w0BAQUFAANBAAtW+yr27kv/q5QxjuQgPtJ7
r/8S5HnBAma0qADwKk3As4Z6xi7Kj4ajN3nqr/sZnNHL2g5nxsyue2Oslzy5+04xggKuMIICqgIB
ATCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMw
EQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAG
A1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEAgphRpxUAAAA
AAQwMAkGBSsOAwIaBQCgggFZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDkxNDE5MTY1MFowIwYJKoZIhvcNAQkEMRYEFJh5FMvOYbScg5MjbU8xTainaH8jMDwG
CSqGSIb3DQEJDzEvMC0wBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcN
AgUwgbsGCSsGAQQBgjcQBDGBrTCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5j
b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzAN
BgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UE
AxMGV2lsZElEAgphRpxUAAAAAAQwMA0GCSqGSIb3DQEBAQUABIGAOvCIuBqqlFNcAH7sn05xBaow
8/LIbgDb4sXi9ZQbYWVoRONkFt3osQc/RVhSDIvUXdVWFJxM9OVz7ZpparkjgBGyxzfrG4Ohv25z
4GaCGfw/W51t6WMoUR6oVX77BHjgUxrdOFdWrD7kif26ytzDjV9hBIIhWlguifPnKSK2WgEAAAAA
AAA=

------=_NextPart_000_0000_01C01E45.A8EC5090--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29438 for <[e-mail]>; Thu, 14 Sep 2000 12:17:20 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id PAA24375; Thu, 14 Sep 2000 15:19:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v0422080db5e6d25dd6b9@[171.78.30.107]>
In-Reply-To: <69A40A314934D41190C70050DAD7F99063B5FA@MAIL>
References: <69A40A314934D41190C70050DAD7F99063B5FA@MAIL>
Date: Thu, 14 Sep 2000 15:14:24 -0400
To: Mathew  Butler <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: The need for two grades of time data.
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Mat,

>If this is the case, then the work that the IETF is attempting to do here is
>going to be for naught, because nobody is going to use it for its intended
>purpose.
>
>(For that matter, what do you think the intended purpose of this
>specification is?  If it's not to create a system that can be used simply
>and reliably to verify assertions made within signatures [i.e., the person
>who signed it is who he says he is, the signature was generated on the date
>he said he generated it, and that the signature was applied to the data that
>it is attached to] then we might as well give up now and save ourselves
>further headache.  Shall I trot out some hypothetical examples of -why- this
>level pedantism is necessary and useful?)

We are developing standards that support all of these functions. What 
we are not doing is establishing the parameters of what is good 
enough from an assurance perspective.

>"Time-Stamping Authority" -- Okay, I can see your point.  However, at what
>point does the TSA actually see the blob that it's expected to timestamp?
>And perhaps more importantly, is there any way to verify that the TSA is
>doing its job correctly, and not putting out bogus information (because
>their clocks got skewed 24 minutes, for example)?  Is there a way to certify
>the time that they have comes from a "reliable source"?  If there isn't, why
>should we trust it?  If there is, then why not embed the trusted
>certification?  It's a little more work, for a lot less hassle in the end.

A TSA NEVER sees the data on which the message imprint is calculated. 
That's a security feature of the model.  the specific measures a TSA 
employs to convince its clients that the time stampts are accurate is 
just the sort of assurance detail that we do not address, for the 
reasons already cited.

>(My opinion is that if we give the lawyers something that they -can't-
>bicker over, then they can go off and leave us alone while we do other
>things.  Otherwise, there will be demand in the future for the same type of
>'certification of time' as I'm talking about -- which is exactly what the
>TSA is supposed to provide, but which is not going to be certified
>elsewise.)

If you believe that we could define the mechanisms and operational 
procedures that would satisfy EVERY time stamping application, or 
even try to define the set of applications that are appropriate 
served by a TSA that implemented a specific set of mechanisms and 
procedures, then I think you would be creating a target for lawyers.

Let me give a simple, direct, analogy analogy. We don't say (in 2459) 
that a CA should or must use a FIPS 140-1 certified crypto module to 
protect its private signature keys. This is outside the scope of our 
standard, and it is a very significant aspect of the confidence that 
a client would place in a CA.

Steve



Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28901 for <[e-mail]>; Thu, 14 Sep 2000 11:57:23 -0700 (PDT)
Received: from [195.99.54.20] (helo=vaio) by carbon.btinternet.com with smtp (Exim 3.03 #83) id 13ZeEI-0005nV-00; Thu, 14 Sep 2000 19:59:27 +0100
Message-ID: <000801c01e7e$73d93060$143663c3@vaio>
Reply-To: "Liaquat Khan" <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "Khaja Ahmed" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: RFC 2560 - OCSP - Clarification
Date: Thu, 14 Sep 2000 20:03:14 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C01E86.D13A8C60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C01E86.D13A8C60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: RFC 2560 - OCSP - ClarificationHi Khaja,

Sorry for responding so late to this. But, as per our discussion today, =
this is not a major issue to me.  I agree that the RFC is quite clear, =
and if all the processing is done beforehand, then 'good' should really =
mean good.

I was just worried that the messages end-user are provided with by their =
software application should be as clear or precise as possible.  They =
should not have to hunt for definitions in standards.  I realise that =
this is quite hard to achieve in practice and this may not be the most =
appropriate place to discuss such issues anyway.=20

I also accept that legal implications may not really be tied to the =
words being used.=20

Regards,
Liaquat
  ----- Original Message -----=20
  From: Khaja Ahmed=20
  To: 'Liaquat Khan' ; Denis Pinkas ; Michael Myers=20
  Cc: [e-mail]=20
  Sent: Sunday, September 03, 2000 7:43 PM
  Subject: RE: RFC 2560 - OCSP - Clarification


  It sound to me like the debate is really about good choice of words to =
describe something.  Looks like everyone (or most) know exactly what =
"good" means in rfc.2560.  After all, it is explained there quite =
clearly.  The question then is: Why should "good" or any other word =
describing a state of anything "imply" anything?  The precise meaning =
should be, and in this case is, described in the standard.  From time to =
time common English words may be used to describe precise and narrow =
technical matter.  As long as the precise meaning in the context is =
described in the spec one does not need to fall back on English =
dictionaries.  I would argue that "not revoked" isn't any clearer.  "Not =
revoked and may not have been issued" is getting close but is too =
verbose.  Ultimately there needs to be a handle and some text explaining =
what is meant by the handle.  I am not sure it is important to worry =
excessively about the choice of handle.

  Secondly, a case can be made, that "good" in the context is actually =
the right term.  An OCSP query is, after all, not a substitute for basic =
path validation.  Someone, somewhere - the relying party or a trusted =
agent or a server or X is meant to have done quite a lot of work before =
checking the revocation status of a certificate.  OCSP was not meant to =
do remote path processing as far as I know.  The relying party is =
expected to have at least done the following two things in addition to =
whatever application specific checking is required:

  1.) Verify the signature.=20
  2.) Do RFC.2459 section 6.1 compliant basic path validation=20

  After these two steps the relying party is checking to see if the =
certificate has been revoked.  The certificate in question is a =
certificate (chain) which the relying party is in physical possession of =
and has cryptographically verified. =20

  What then is the value of being told at this point that the =
certificate is no only not revoked but has been issued?  Unless the CA =
private key has been compromised or RSA has been broken this =
additionally info is of no value.  If one of these two thing have =
happened, then whatever the riches of the OCSP "good" semantics - they =
are of little value.  In this context, as far as I can see, "good" is =
good.

  ...or have I misunderstood the whole thing and neglected to consider =
some factors?=20

  Khaja=20

  -----Original Message-----=20
  From: Liaquat Khan [mailto:[e-mail]]=20
  Sent: Sunday, September 03, 2000 1:26 AM=20
  To: Denis Pinkas; Michael Myers=20
  Cc: [e-mail]=20
  Subject: Re: RFC 2560 - OCSP - Clarification=20



  I tend to agree... a certificate status of "good" is a bit misleading, =
not=20
  only from the viewpoint that the certificate may never been issued in =
the=20
  first place, but also because it kind of implies that the certificate =
is=20
  acceptable for a particular purpose.  It might be better to have a =
status of=20
  "not-revoked", which simply means that the CA has not revoked the=20
  certificate, for what ever reason  (i.e. either it never issued the=20
  certificate in the first place or because the certificate is still =
valid).=20
  From a legal point of view this may be better for the CA, than =
claiming the=20
  certificate is good.=20

  Regards,=20
  Liaquat Khan=20




  ----- Original Message -----=20
  From: Denis Pinkas <[e-mail]>=20
  To: Michael Myers <[e-mail]>=20
  Cc: Liaquat Khan <[e-mail]>; <[e-mail]> =

  Sent: Saturday, September 02, 2000 5:34 PM=20
  Subject: Re: RFC 2560 - OCSP - Clarification=20



  > Michael,=20
  >=20
  > > Liaquat,=20
  > >=20
  > > Thanks for taking a careful look at 2560 regarding CRLs.  This =
thread=20
  will=20
  > > feed productively into 2560bis.=20
  > >=20
  > > But I do need to point out that OCSP does not, nor was ever =
intended, to=20
  > > require the use of CRLs.=20
  >=20
  > As you said, OSCP does not require, but does allow the use of CRLs=20
  > as the primary information used by the OCSP server to respond.=20
  >=20
  >=20
  > > In fact, here are a few references from 2560 as=20
  > > currently written:=20
  > >=20
  > > Abstract=20
  > > "This document specifies a protocol useful in determining the =
current=20
  status=20
  > > of a digital certificate without requiring CRLs."=20
  > >             ^^^^^^^^^^^^^^^^^^^^^^=20
  > >=20
  > > 2.  Protocol Overview=20
  > > "OCSP may be used to satisfy some of the operational requirements =
of=20
  > > providing more timely revocation information than is possible with =
CRLs=20
  . .=20
  > > . ."=20
  > >                        ^^^^^^^^^^^^^^^^^^^^^^^^^^=20
  > >=20
  > > Now, that said, 2560 does recognize that CRLs are a useful input =
to OCSP=20
  and=20
  > > so we made certain to accomodate that data source in the event =
that=20
  > > periodically produced CRLs were the ONLY means by which an OCSP =
service=20
  > > could be offered.  We enabled the use of CRL extensions to =
accomodate=20
  > > environments where this feature was useful.=20
  > >=20
  > > But OCSP is and was primarly intended to address immediate =
timeliness, a=20
  > > feature that is inherently beyond the scope of periodically =
produced=20
  CRLs.=20
  > >=20
  >=20
  > The problem is that the protocol does not take advantage of this=20
  > feature. So the notion of "immediate timeliness" does not reaaly=20
  > make sense, since anyway there is some delay in the overall process. =

  > A "good" status does not guarantee in any way that the certificate=20
  > is presently "good", but only that it has not be declared to be=20
  > revoked at some previous *undefined* time which may be a few=20
  > minutes,=20
  > hours (or even days) from the current time.=20
  >=20
  > So let me propose a "clarification" about the meaning of the "good"=20
  > status.=20
  >=20
  >  The "good" state indicates a positive response to the status=20
  >  inquiry. At a minimum, this positive response indicates=20
  >  that the certificate  has not be declared or requested=20
  >  to be revoked at some point  of time prior the current time,=20
  >  and does not necessarily mean  that the certificate was=20
  >  ever issued by the CA or that the time  at which the=20
  >  response was produced is within the certificate's validity=20
  >  interval.=20
  >=20
  > I do know that this definition gives less than the previous one, but =

  > it provides a better reality of the situation: no assurance that, at =

  > the time of the response, the private key is not compromised or the=20
  > association between the key value and the content of the certificate =

  > is still correct.=20
  >=20
  > > 2560bis will clarify this intent.=20
  >=20
  > I think it is important to maintain that the use of CRLs as the=20
  > primary information used by the OCSP server is one of the options to =

  > provide the real=20
  > time information. So be *very* careful when making the=20
  > "clarification".=20
  >=20
  > Denis=20
  >=20
  > P.S. Since in your message from August 31, you said:=20
  >=20
  > " Given the current work underway regarding 2560bis, I propose to=20
  > include in=20
  > the 2560bis work effort an optional "ValidAt" (or some such) field=20
  > in the=20
  > request syntax to accomodate this requirement."=20
  >=20
  > I do not support your proposal and I fear you are planning to change =

  > RFC 2560 by adding new functionality. So, here is my question: *In=20
  > addition* to 2560bis, when are you expecting to provide a draft for=20
  > OSCP extensions (i.e. OCSP-X) able to cover additional functionality =

  > ?=20
  >=20
  >=20
  > > Mike=20
  > >=20
  > > > -----Original Message-----=20
  > > > From: Liaquat Khan [mailto:[e-mail]]=20
  > > > Sent: Wednesday, August 30, 2000 9:02 AM=20
  > > > To: [e-mail]=20
  > > > Subject: Re: RFC 2560 - OCSP - Clarification=20
  > > >=20
  > > >=20
  > > > The problem is linked to the fact that OCSP generally uses=20
  > > > CRLs as the base=20
  > > > information (although of course this doesn't have to be the=20
  > > > case). And CRLs=20
  > > > basically contain identifiers for those certificates that=20
  > > > have been revoked=20
  > > > (or suspended).  Therefore, if a particular certificates=20
  > > > serial number is=20
  > > > not on a CRL, it maybe because it is still valid or maybe=20
  > > > because it was=20
  > > > never issued in the first place.=20
  > > >=20
  > > > Note that the OCSP standard makes a reference that extensions=20
  > > > should be used=20
  > > > for providing additional information.=20
  > > >=20
  > > > Regards,=20
  > > > Liaquat Khan=20
  > > > Technical Manager=20
  > > > Global Trust Authority=20
  > > >=20
  > > >=20
  > > >=20
  > > > ----- Original Message -----=20
  > > > From: Mathew Butler <[e-mail]>=20
  > > > To: 'Rich Salz' <[e-mail]>; Sam Schaen=20
  > > > <[e-mail]>;=20
  > > > <[e-mail]>=20
  > > > Sent: Monday, August 28, 2000 9:13 PM=20
  > > > Subject: RE: RFC 2560 - OCSP - Clarification=20
  > > >=20
  > > >=20
  > > > > I think that there's a problem with this idea.  If the=20
  > > > responder doesn't=20
  > > > > know about the CA, or have the ability to verify the CA's=20
  > > > signature on the=20
  > > > > certificate versus the CRL, the response should be=20
  > > > "unknown" rather than=20
  > > > > "good".=20
  > > > >=20
  > > > > "Good" should indicate: "The certificate was apparently=20
  > > > issued by a CA=20
  > > > that=20
  > > > > the responder has current revocation information for, and=20
  > > > the certificate=20
  > > > > has not been revoked."=20
  > > > >=20
  > > > > Forgive me for not reading the draft as thoroughly as I=20
  > > > should have; is=20
  > > > > there any call for the responder to cryptographically check =
the=20
  > > > certificate=20
  > > > > at any point during the request?=20
  > > > >=20
  > > > > -Mat Butler=20
  > > > >=20
  > > > > -----Original Message-----=20
  > > > > From: Rich Salz [mailto:[e-mail]]=20
  > > > > Sent: Monday, August 28, 2000 8:08 AM=20
  > > > > To: Sam Schaen=20
  > > > > Cc: '[e-mail]'=20
  > > > > Subject: Re: RFC 2560 - OCSP - Clarification=20
  > > > >=20
  > > > >=20
  > > > > The text in uppercase is contradicted by the sentence that=20
  > > > immediately=20
  > > > > follows.  If good doesn't mean the certificate was issued,=20
  > > > then there=20
  > > > > need not be a CA that issued it. :)=20
  > > > >=20
  > > > >=20
  > > > > > 'The "good" state indicates that THE RESPONDER HAS=20
  > > > CURRENT REVOCATION=20
  > > > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND=20
  > > > the certificate=20
  > > > > has not=20
  > > > > > been revoked. It=20
  > > > > > does not indicate whether the certificate was ever=20
  > > > issued, is still=20
  > > > valid=20
  > > > > or=20
  > > > > > any other assertion.=20
  > > > >=20
  > > >=20
  >=20
  >=20
  >=20


------=_NextPart_000_0005_01C01E86.D13A8C60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: RFC 2560 - OCSP - Clarification</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Khaja,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sorry for responding so late to =
this.</FONT><FONT=20
face=3DArial size=3D2> But, as per our discussion today, this is not a =
major issue=20
to me.&nbsp; I agree that the RFC is quite clear, and if all the =
processing is=20
done beforehand, then 'good' should really mean good.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I was just worried that the messages =
end-user are=20
provided with by their software application should be as clear or =
precise as=20
possible.&nbsp; They should not have to hunt for definitions in =
standards.&nbsp;=20
I&nbsp;realise that this is quite hard to achieve in practice and this =
may not=20
be the most appropriate place to discuss such issues anyway. =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I also accept that legal implications =
may not=20
really be tied to the words being used. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]" =
title=[e-mail]>Khaja=20
  Ahmed</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[e-mail]"=20
  title=[e-mail]>'Liaquat Khan'</A> ; <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>Denis=20
  Pinkas</A> ; <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>Michael Myers</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, September 03, =
2000 7:43=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: RFC 2560 - OCSP -=20
  Clarification</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>It sound to me like the debate is really about good =
choice of=20
  words to describe something.&nbsp; Looks like everyone (or most) know =
exactly=20
  what "good" means in rfc.2560.&nbsp; After all, it is explained there =
quite=20
  clearly.&nbsp; The question then is: Why should "good" or any other =
word=20
  describing a state of anything "imply" anything?&nbsp; The precise =
meaning=20
  should be, and in this case is, described in the standard.&nbsp; From =
time to=20
  time common English words may be used to describe precise and narrow =
technical=20
  matter.&nbsp; As long as the precise meaning in the context is =
described in=20
  the spec one does not need to fall back on English dictionaries.&nbsp; =
I would=20
  argue that "not revoked" isn't any clearer.&nbsp; "Not revoked and may =
not=20
  have been issued" is getting close but is too verbose.&nbsp; =
Ultimately there=20
  needs to be a handle and some text explaining what is meant by the=20
  handle.&nbsp; I am not sure it is important to worry excessively about =
the=20
  choice of handle.</FONT></P>
  <P><FONT size=3D2>Secondly, a case can be made, that "good" in the =
context is=20
  actually the right term.&nbsp; An OCSP query is, after all, not a =
substitute=20
  for basic path validation.&nbsp; Someone, somewhere - the relying =
party or a=20
  trusted agent or a server or X is meant to have done quite a lot of =
work=20
  before checking the revocation status of a certificate.&nbsp; OCSP was =
not=20
  meant to do remote path processing as far as I know.&nbsp; The relying =
party=20
  is expected to have at least done the following two things in addition =
to=20
  whatever application specific checking is required:</FONT></P>
  <P><FONT size=3D2>1.) Verify the signature.</FONT> <BR><FONT =
size=3D2>2.) Do=20
  RFC.2459 section 6.1 compliant basic path validation</FONT> </P>
  <P><FONT size=3D2>After these two steps the relying party is checking =
to see if=20
  the certificate has been revoked.&nbsp; The certificate in question is =
a=20
  certificate (chain) which the relying party is in physical possession =
of and=20
  has cryptographically verified.&nbsp; </FONT></P>
  <P><FONT size=3D2>What then is the value of being told at this point =
that the=20
  certificate is no only not revoked but has been issued?&nbsp; Unless =
the CA=20
  private key has been compromised or RSA has been broken this =
additionally info=20
  is of no value.&nbsp; If one of these two thing have happened, then =
whatever=20
  the riches of the OCSP "good" semantics - they are of little =
value.&nbsp; In=20
  this context, as far as I can see, "good" is good.</FONT></P>
  <P><FONT size=3D2>...or have I misunderstood the whole thing and =
neglected to=20
  consider some factors?</FONT> </P>
  <P><FONT size=3D2>Khaja</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Liaquat Khan [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
lticert.org</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Sunday, September 03, 2000 1:26 AM</FONT> =
<BR><FONT=20
  size=3D2>To: Denis Pinkas; Michael Myers</FONT> <BR><FONT size=3D2>Cc: =

  [e-mail]</FONT> <BR><FONT size=3D2>Subject: Re: RFC 2560 - =
OCSP -=20
  Clarification</FONT> </P><BR>
  <P><FONT size=3D2>I tend to agree... a certificate status of "good" is =
a bit=20
  misleading, not</FONT> <BR><FONT size=3D2>only from the viewpoint that =
the=20
  certificate may never been issued in the</FONT> <BR><FONT =
size=3D2>first place,=20
  but also because it kind of implies that the certificate is</FONT> =
<BR><FONT=20
  size=3D2>acceptable for a particular purpose.&nbsp; It might be better =
to have a=20
  status of</FONT> <BR><FONT size=3D2>"not-revoked", which simply means =
that the=20
  CA has not revoked the</FONT> <BR><FONT size=3D2>certificate, for what =
ever=20
  reason&nbsp; (i.e. either it never issued the</FONT> <BR><FONT=20
  size=3D2>certificate in the first place or because the certificate is =
still=20
  valid).</FONT> <BR><FONT size=3D2>From a legal point of view this may =
be better=20
  for the CA, than claiming the</FONT> <BR><FONT size=3D2>certificate is =

  good.</FONT> </P>
  <P><FONT size=3D2>Regards,</FONT> <BR><FONT size=3D2>Liaquat =
Khan</FONT>=20
  </P><BR><BR>
  <P><FONT size=3D2>----- Original Message -----</FONT> <BR><FONT =
size=3D2>From:=20
  Denis Pinkas &lt;[e-mail]&gt;</FONT> <BR><FONT =
size=3D2>To: Michael=20
  Myers &lt;[e-mail]&gt;</FONT> <BR><FONT size=3D2>Cc: =
Liaquat Khan=20
  &lt;[e-mail]&gt;; =
&lt;[e-mail]&gt;</FONT>=20
  <BR><FONT size=3D2>Sent: Saturday, September 02, 2000 5:34 PM</FONT> =
<BR><FONT=20
  size=3D2>Subject: Re: RFC 2560 - OCSP - Clarification</FONT> </P><BR>
  <P><FONT size=3D2>&gt; Michael,</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Liaquat,</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Thanks for taking a careful look at 2560 regarding=20
  CRLs.&nbsp; This thread</FONT> <BR><FONT size=3D2>will</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; feed productively into 2560bis.</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; But I do need to point out =
that OCSP=20
  does not, nor was ever intended, to</FONT> <BR><FONT size=3D2>&gt; =
&gt; require=20
  the use of CRLs.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt; As=20
  you said, OSCP does not require, but does allow the use of CRLs</FONT> =

  <BR><FONT size=3D2>&gt; as the primary information used by the OCSP =
server to=20
  respond.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; In fact, here are a few references from =
2560=20
  as</FONT> <BR><FONT size=3D2>&gt; &gt; currently written:</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; Abstract</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; "This document specifies a protocol useful in =
determining the=20
  current</FONT> <BR><FONT size=3D2>status</FONT> <BR><FONT =
size=3D2>&gt; &gt; of a=20
  digital certificate without requiring CRLs."</FONT> <BR><FONT =
size=3D2>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
  ^^^^^^^^^^^^^^^^^^^^^^</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; 2.&nbsp; Protocol Overview</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  "OCSP may be used to satisfy some of the operational requirements =
of</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; providing more timely revocation =
information than=20
  is possible with CRLs</FONT> <BR><FONT size=3D2>. .</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; . ."</FONT> <BR><FONT size=3D2>&gt;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  ^^^^^^^^^^^^^^^^^^^^^^^^^^</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Now, that said, 2560 does recognize that CRLs are a =
useful=20
  input to OCSP</FONT> <BR><FONT size=3D2>and</FONT> <BR><FONT =
size=3D2>&gt; &gt; so=20
  we made certain to accomodate that data source in the event =
that</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; periodically produced CRLs were the ONLY =
means by=20
  which an OCSP service</FONT> <BR><FONT size=3D2>&gt; &gt; could be=20
  offered.&nbsp; We enabled the use of CRL extensions to =
accomodate</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; environments where this feature was =
useful.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; But =
OCSP is and=20
  was primarly intended to address immediate timeliness, a</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; feature that is inherently beyond the scope of =
periodically=20
  produced</FONT> <BR><FONT size=3D2>CRLs.</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; The =
problem is=20
  that the protocol does not take advantage of this</FONT> <BR><FONT =
size=3D2>&gt;=20
  feature. So the notion of "immediate timeliness" does not =
reaaly</FONT>=20
  <BR><FONT size=3D2>&gt; make sense, since anyway there is some delay =
in the=20
  overall process.</FONT> <BR><FONT size=3D2>&gt; A "good" status does =
not=20
  guarantee in any way that the certificate</FONT> <BR><FONT =
size=3D2>&gt; is=20
  presently "good", but only that it has not be declared to be</FONT> =
<BR><FONT=20
  size=3D2>&gt; revoked at some previous *undefined* time which may be a =

  few</FONT> <BR><FONT size=3D2>&gt; minutes,</FONT> <BR><FONT =
size=3D2>&gt; hours=20
  (or even days) from the current time.</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; So let me propose a "clarification" about the =
meaning of=20
  the "good"</FONT> <BR><FONT size=3D2>&gt; status.</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;&nbsp; The "good" state =
indicates a=20
  positive response to the status</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
inquiry. At=20
  a minimum, this positive response indicates</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;=20
  that the certificate&nbsp; has not be declared or requested</FONT> =
<BR><FONT=20
  size=3D2>&gt;&nbsp; to be revoked at some point&nbsp; of time prior =
the current=20
  time,</FONT> <BR><FONT size=3D2>&gt;&nbsp; and does not necessarily =
mean&nbsp;=20
  that the certificate was</FONT> <BR><FONT size=3D2>&gt;&nbsp; ever =
issued by the=20
  CA or that the time&nbsp; at which the</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;=20
  response was produced is within the certificate's validity</FONT> =
<BR><FONT=20
  size=3D2>&gt;&nbsp; interval.</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; I do know that this definition gives less than the =
previous one,=20
  but</FONT> <BR><FONT size=3D2>&gt; it provides a better reality of the =

  situation: no assurance that, at</FONT> <BR><FONT size=3D2>&gt; the =
time of the=20
  response, the private key is not compromised or the</FONT> <BR><FONT=20
  size=3D2>&gt; association between the key value and the content of the =

  certificate</FONT> <BR><FONT size=3D2>&gt; is still correct.</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; 2560bis will clarify =
this=20
  intent.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; =
I think it=20
  is important to maintain that the use of CRLs as the</FONT> <BR><FONT=20
  size=3D2>&gt; primary information used by the OCSP server is one of =
the options=20
  to</FONT> <BR><FONT size=3D2>&gt; provide the real</FONT> <BR><FONT =
size=3D2>&gt;=20
  time information. So be *very* careful when making the</FONT> =
<BR><FONT=20
  size=3D2>&gt; "clarification".</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; Denis</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;=20
  P.S. Since in your message from August 31, you said:</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; " Given the current work =
underway=20
  regarding 2560bis, I propose to</FONT> <BR><FONT size=3D2>&gt; include =
in</FONT>=20
  <BR><FONT size=3D2>&gt; the 2560bis work effort an optional "ValidAt" =
(or some=20
  such) field</FONT> <BR><FONT size=3D2>&gt; in the</FONT> <BR><FONT =
size=3D2>&gt;=20
  request syntax to accomodate this requirement."</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt; I do not support your =
proposal and I=20
  fear you are planning to change</FONT> <BR><FONT size=3D2>&gt; RFC =
2560 by=20
  adding new functionality. So, here is my question: *In</FONT> =
<BR><FONT=20
  size=3D2>&gt; addition* to 2560bis, when are you expecting to provide =
a draft=20
  for</FONT> <BR><FONT size=3D2>&gt; OSCP extensions (i.e. OCSP-X) able =
to cover=20
  additional functionality</FONT> <BR><FONT size=3D2>&gt; ?</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  Mike</FONT> <BR><FONT size=3D2>&gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  -----Original Message-----</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
From:=20
  Liaquat Khan [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
lticert.org</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; Sent: Wednesday, August 30, 2000 =
9:02=20
  AM</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; To: =
[e-mail]</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; Subject: Re: RFC 2560 - OCSP -=20
  Clarification</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; The =
problem is=20
  linked to the fact that OCSP generally uses</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; CRLs as the base</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
information=20
  (although of course this doesn't have to be the</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; case). And CRLs</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
basically=20
  contain identifiers for those certificates that</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; have been revoked</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
(or=20
  suspended).&nbsp; Therefore, if a particular certificates</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; serial number is</FONT> <BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  not on a CRL, it maybe because it is still valid or maybe</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; because it was</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  never issued in the first place.</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; Note that the OCSP standard makes a =
reference=20
  that extensions</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; should be =
used</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; for providing additional =
information.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;=20
  Regards,</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; Liaquat Khan</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; Technical Manager</FONT> <BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  Global Trust Authority</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt; ----- Original Message -----</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt; From: Mathew Butler =
&lt;[e-mail]&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; To: 'Rich Salz'=20
  &lt;[e-mail]&gt;; Sam Schaen</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; &lt;[e-mail]&gt;;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;=20
  &lt;[e-mail]&gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
Sent: Monday,=20
  August 28, 2000 9:13 PM</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
Subject: RE:=20
  RFC 2560 - OCSP - Clarification</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt; &gt; I=20
  think that there's a problem with this idea.&nbsp; If the</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; responder doesn't</FONT> <BR><FONT =
size=3D2>&gt; &gt; &gt;=20
  &gt; know about the CA, or have the ability to verify the CA's</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; signature on the</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; &gt; certificate versus the CRL, the response should =
be</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; "unknown" rather than</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; &gt; "good".</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; "Good" should =
indicate: "The=20
  certificate was apparently</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
issued by a=20
  CA</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; that</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; &gt; the responder has current revocation information for,=20
  and</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; the certificate</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; &gt; has not been revoked."</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; Forgive =
me for not=20
  reading the draft as thoroughly as I</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  should have; is</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; there =
any call for=20
  the responder to cryptographically check the</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; certificate</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; at any =
point=20
  during the request?</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; &gt; -Mat Butler</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; =
-----Original=20
  Message-----</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; From: Rich =
Salz [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]=
</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; &gt; Sent: Monday, August 28, 2000 =
8:08=20
  AM</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; To: Sam Schaen</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; &gt; Cc: '[e-mail]'</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt; &gt; Subject: Re: RFC 2560 - OCSP - =
Clarification</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; The text in =
uppercase is=20
  contradicted by the sentence that</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;=20
  immediately</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; =
follows.&nbsp; If good=20
  doesn't mean the certificate was issued,</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; then there</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; need not =
be a CA=20
  that issued it. :)</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; =
&gt; &gt;=20
  &gt; &gt; 'The "good" state indicates that THE RESPONDER HAS</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; CURRENT REVOCATION</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt; &gt; &gt; INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE =
AND</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt; the certificate</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt; &gt; has not</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; =
&gt; been=20
  revoked. It</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; &gt; &gt; does =
not indicate=20
  whether the certificate was ever</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;=20
  issued, is still</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; valid</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt; &gt; or</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt; &gt; &gt;=20
  any other assertion.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT =
size=3D2>&gt;</FONT> <BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;</FONT> =
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0005_01C01E86.D13A8C60--



Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA28563 for <[e-mail]>; Thu, 14 Sep 2000 11:48:47 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA24563; Thu, 14 Sep 2000 19:56:17 +0100
Message-ID: <[e-mail]>
Date: Thu, 14 Sep 2000 19:50:09 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
MIME-Version: 1.0
To: Mathew Butler <[e-mail]>
CC: "'Stephen Kent'" <[e-mail]>, Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: The need for two grades of time data.
References: <69A40A314934D41190C70050DAD7F99063B5FA@MAIL>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mathew Butler wrote:
> "Time-Stamping Authority" -- Okay, I can see your point.  However, at what
> point does the TSA actually see the blob that it's expected to timestamp?

Presumably at the point it timestamps it.

> And perhaps more importantly, is there any way to verify that the TSA is
> doing its job correctly, and not putting out bogus information (because
> their clocks got skewed 24 minutes, for example)?  Is there a way to certify
> the time that they have comes from a "reliable source"?  If there isn't, why
> should we trust it?  If there is, then why not embed the trusted
> certification?  It's a little more work, for a lot less hassle in the end.

Errr ... we specify a way to check that a source you have chosen to
consider is reliable is actually the source of the timestamp. You still
have to do the choosing. Or am I missing something?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28082 for <[e-mail]>; Thu, 14 Sep 2000 11:39:19 -0700 (PDT)
Received: by MAIL with Internet Mail Service (5.5.2650.21) id <S7HAW78H>; Thu, 14 Sep 2000 11:36:17 -0700
Message-ID: <69A40A314934D41190C70050DAD7F99063B5FA@MAIL>
From: Mathew  Butler <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Bob Jueneman <[e-mail]>
Cc: [e-mail]
Subject: RE: The need for two grades of time data.
Date: Thu, 14 Sep 2000 11:36:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

If this is the case, then the work that the IETF is attempting to do here is
going to be for naught, because nobody is going to use it for its intended
purpose.

(For that matter, what do you think the intended purpose of this
specification is?  If it's not to create a system that can be used simply
and reliably to verify assertions made within signatures [i.e., the person
who signed it is who he says he is, the signature was generated on the date
he said he generated it, and that the signature was applied to the data that
it is attached to] then we might as well give up now and save ourselves
further headache.  Shall I trot out some hypothetical examples of -why- this
level pedantism is necessary and useful?)

"Time-Stamping Authority" -- Okay, I can see your point.  However, at what
point does the TSA actually see the blob that it's expected to timestamp?
And perhaps more importantly, is there any way to verify that the TSA is
doing its job correctly, and not putting out bogus information (because
their clocks got skewed 24 minutes, for example)?  Is there a way to certify
the time that they have comes from a "reliable source"?  If there isn't, why
should we trust it?  If there is, then why not embed the trusted
certification?  It's a little more work, for a lot less hassle in the end.

(My opinion is that if we give the lawyers something that they -can't-
bicker over, then they can go off and leave us alone while we do other
things.  Otherwise, there will be demand in the future for the same type of
'certification of time' as I'm talking about -- which is exactly what the
TSA is supposed to provide, but which is not going to be certified
elsewise.)

-Mat

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, September 14, 2000 11:26 AM
To: Bob Jueneman
Cc: [e-mail]
Subject: Re: The need for two grades of time data.


Bob,

>I believe that what Todd is trying to say is that the question isn't,
>"What time is it?" but rather "What time is it, and who says so, and
>why should anyone believe them?"

Since Todd agrees with Bob's concise translation, I think this is really
easy:

	- by choosing to use the service of a given TSA, the client 
is relying on the TSA to state the time

	- the TSA has a cert to identity it, and that cert is issued 
by a CA, who vouches for the accuracy of the ID, consistent with our 
usual CA model

	- a TSA publishes the technical basis for its time keeping, 
which provides the basis for the last value judgement

So, if the goal is to answer Bob's questions, I think we're done.  If 
one believes that we should move on to establishing criteria for 
different grades of time stamps, you're probably subscribed to the 
wrong WG list, and the wrong standards body, i.e., the IETF is not in 
the business of generating assurance standards of this sort.

Steve


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27406 for <[e-mail]>; Thu, 14 Sep 2000 11:22:26 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA16184; Thu, 14 Sep 2000 14:24:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220807b5e6c6bc1b32@[171.78.30.107]>
In-Reply-To: <01f101c01da4$1b7c58f0$020aff0c@tsg1>
References:  <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107 ]><006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]> <01d901c01d9e$7d678b30$020aff0c@tsg1> <[e-mail]> <01f101c01da4$1b7c58f0$020aff0c@tsg1>
Date: Thu, 14 Sep 2000 14:22:14 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Rich I still disagree with you and pretty strongly too -
>----- Original Message -----
>From: "Rich Salz" <[e-mail]>
>To: "todd glassey" <[e-mail]>
>Cc: "Stephen Kent" <[e-mail]>; <[e-mail]>
>Sent: Wednesday, September 13, 2000 9:41 AM
>Subject: Re: The need for two grades of time data.
>
>
>  > > we ignore the need to provide proofing as to what the time data is and
>  > > where it came from
>  >
>  > This makes sense.  It also reinforces my belief that it doesn't belong
>  > in the IETF any more than proof that IBM.COM really is, IBM. :)
>
>Except that what you are now talking about is operating the trust process
>rather than architecting it, and of course the IETF is not a commercial
>trust provider. That goes without saying. the issue here is in architecing
>systems that do not support the needs of current and obviously emerging
>laws, standards, and BCP models, and since we set so few of those in the
>Techno Puratory of the PKIX WG we ned to be aware of them above us. Heck,
>even the forges of the underworld took input from Zeus.

By Jove, this is hard to parse! Note that PKIX also has not chosen to 
generate a set of standards for CA operation, defining different 
grades of "trust."  A BCP is out of the question at this point, 
because there is insufficient experience to generate such a document 
for a TSP.  It might be called a BCS (Best Current Speculation), but 
the IETF does not publish BCS's.


>  > > In fact that the X509 Digitally Signed Documents now automatically have
>  > > legal consequence here in the States, in my mind opens a whole new realm
>  > > of requirements for us to have to take into account. Does this explain
>  > > what I mean?
>  >
>  > They don't automatically have legal consequence; they lost the automatic
>  > non-legal status.
>
>Sure they do. Anything I sign with my Digital Cert is represented as my wet
>signature under the law . Making it essentially  a legal instrument of my
>agency. That's just the way it is.


No, it's not. I sign authentication challenges with a private key and 
there is no legal (NR) implication associated with that.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27399 for <[e-mail]>; Thu, 14 Sep 2000 11:22:25 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA16180; Thu, 14 Sep 2000 14:24:40 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b5e687a247f9@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 14 Sep 2000 14:26:26 -0400
To: "Bob Jueneman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

>I believe that what Todd is trying to say is that the question isn't,
>"What time is it?" but rather "What time is it, and who says so, and
>why should anyone believe them?"

Since Todd agrees with Bob's concise translation, I think this is really easy:

	- by choosing to use the service of a given TSA, the client 
is relying on the TSA to state the time

	- the TSA has a cert to identity it, and that cert is issued 
by a CA, who vouches for the accuracy of the ID, consistent with our 
usual CA model

	- a TSA publishes the technical basis for its time keeping, 
which provides the basis for the last value judgement

So, if the goal is to answer Bob's questions, I think we're done.  If 
one believes that we should move on to establishing criteria for 
different grades of time stamps, you're probably subscribed to the 
wrong WG list, and the wrong standards body, i.e., the IETF is not in 
the business of generating assurance standards of this sort.

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27213 for <[e-mail]>; Thu, 14 Sep 2000 11:17:20 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA15345; Thu, 14 Sep 2000 14:19:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220805b5e6c4a39cf5@[171.78.30.107]>
In-Reply-To: <01d901c01d9e$7d678b30$020aff0c@tsg1>
References:  <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107 ]><006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]> <01d901c01d9e$7d678b30$020aff0c@tsg1>
Date: Thu, 14 Sep 2000 14:11:35 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1243166811==_ma============"

--============_-1243166811==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Steven - group ----> Let me try again.
>
>     1)    The issue is that many of our systems address time as 
>though it were part of the control infrastructure and we ignore the 
>need to provide proofing as to what the time data is and where it 
>came from - Does that answer this comment?

No, it does not.

>
>     2)    We are building many protocols that provide a layered 
>framework for building transaction services and processing. In fact 
>that the X509 Digitally Signed Documents now automatically have 
>legal consequence here in the States, in my mind opens a whole new 
>realm of requirements for us to have to take into account.

I don't believe this is an accurate characterization of current law 
in the U.S., by a long shot. According to current law, I believe that 
a lot of this that are divorced from digital signatures and the X.509 
PKI model have legal standing, and many things that are based on 
these standards do NOT automatically have such standing. So, this is 
a vast oversimplification.

>
>Does this explain what I mean?
>

Not really.

--============_-1243166811==_ma============
Content-Type: text/enriched; charset="us-ascii"

Todd,


<excerpt>Steven - group ----> Let me try again.

 

    1)    The issue is that many of our systems address time as though
it were part of the control infrastructure and we ignore the need to
provide proofing as to what the time data is and where it came from -
Does that answer this comment?

</excerpt>

No, it does not.


<excerpt> 

    2)    We are building many protocols that provide a layered
framework for building transaction services and processing. In fact
that the X509 Digitally Signed Documents now automatically have legal
consequence here in the States, in my mind opens a whole new realm of
requirements for us to have to take into account.

</excerpt>

I don't believe this is an accurate characterization of current law in
the U.S., by a long shot. According to current law, I believe that a
lot of this that are divorced from digital signatures and the X.509 PKI
model have legal standing, and many things that are based on these
standards do NOT automatically have such standing. So, this is a vast
oversimplification.


<excerpt>

<fontfamily><param>Arial</param>Does this explain what I mean?

 

</fontfamily></excerpt><fontfamily><param>Arial</param>

</fontfamily>Not really.

--============_-1243166811==_ma============--


Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17503 for <[e-mail]>; Thu, 14 Sep 2000 07:13:03 -0700 (PDT)
From: [e-mail]
Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id OAA11905 for <[e-mail]>; Thu, 14 Sep 2000 14:14:49 GMT env-from ([e-mail])
Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9eemt3n.in; 14 Sep 2000 14:58:00 +0200
To: <[e-mail]>
Date: Thu, 14 Sep 2000 05:23:49
Message-Id: <[e-mail]>
Subject: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN 
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE 
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO 
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A 
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with 
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP 
CHARGE.

FOR DETAILS CALL 1 888 248 0765  

Webhosting International

 
 
 
 
 
 
 
 
 
 
 
 
 


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13397 for <[e-mail]>; Thu, 14 Sep 2000 04:42:09 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id EAA20101; Thu, 14 Sep 2000 04:43:49 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Sep 2000 11:05:28 -0400
To: Stephen Kent <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <v04220810b5e2fd870ec2@[171.78.30.107]>
References: <006f01c019ac$2f9b7380$020aff0c@tsg1> <[e-mail]> <006f01c019ac$2f9b7380$020aff0c@tsg1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Steve:

At 06:33 PM 09/11/2000 -0400, Stephen Kent wrote:
>>  > Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says
>>  > that the client SHOULD make the check, but that the client MAY elect to
>>  > skip the check.  The checking requirement is either a SHOULD or a MAY, it
>>  > cannot be both.
>>
>>Russ - I agree -  the word SHOULD is specific to a USE MODEL as it is a
>>recommedation . i.e If you are using this as XYZ then you SHOULD... The word
>>MAY creates an choice on the part of the user that is separate of the
>>recommendation. This is one of the confusing things in the "Restricted Word"
>>definitions. But in this instance since there is no USE MODEL for the TSP
>>Defined maybe both are appropriate.
>
>I know that use models are a favorite topic of yours, Todd, but we're not 
>going to start adopting them here. Russ's comments address a concern over 
>consistency of terminology.  I would assert that it is always the case 
>that the client SHOULD check the policy field to determine if the time 
>stamp will be useful, in context. The "MAY" here should be used 
>differently, e.g., "The client MAY elect to ignore the results of this 
>check.' This is not a deep issue, just a matter of wording.
>
>We need to review the rest of Russ's comments, and see what changes may be 
>necessary, but I don't see any of these as show stoppers.


I agree.  None of my comments are show stoppers.  Although, I do think that 
building the interoperability matrix necessary to advance from Proposed 
Standard to Draft Standard will be straightforward if the cited paragraph 
is not reworded.

Russ




Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA08842 for <[e-mail]>; Thu, 14 Sep 2000 03:08:30 -0700 (PDT)
Received: (qmail 13528 invoked from network); 14 Sep 2000 09:59:59 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 14 Sep 2000 09:59:59 -0000
Message-ID: <[e-mail]>
Date: Thu, 14 Sep 2000 11:11:48 +0100
From: Bruno Salgueiro <[e-mail]>
Organization: SIBS
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: pt,en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: The need for two grades of time data.
References: <69A40A314934D41190C70050DAD7F99063B5F4@MAIL>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8E5C1FF41AA0D5B6E6B1B173"

This is a cryptographically signed message in MIME format.

--------------ms8E5C1FF41AA0D5B6E6B1B173
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi to all.

  That's why the DVCS standard is important. Please take a look at the
latest standard and see why with DVCS you can be sure that a document
was signed at least at a particular time, also verifying signatures and
certificates.

  I think that we're trying to overkill TSP with this discussion. TSP
only asserts that some bytes were delivered at a particular time and
the TSP's policy will say specifically what kind of source was used
to get the timestamp. Couldn't we say, for the sake of clarity and pet
projects aside, that there should be a kind of CP for TSPs regarding
time accuracy?

  Finally, I went to the BERT site, read the "standard" quickly and I
don't think that it (or something similar) might solve this issue. The
trust on the time source and the signature of the token being
timestamped
must come from the TSA, IMHO.

Regards,

Mathew Butler wrote:
> 
> Oooh, this is a 'pet project' thing.
> 
> I agree that the time needs to be authenticated, and perhaps more
> importantly, the source of the time needs to be authenticated.  Network Time
> Protocol et al notwithstanding, it's far too easy for a single machine's
> clock to be adjusted for whatever reason.  (And, with NTP, for the entire
> network's time to be adjusted.)
> 
> So, we cannot trust anything that comes out of a single network.  Now, if
> there's a device that provides an accurate source of time data (such as by
> listening to the US Naval Observatory time radio frequency, or the GPS
> date/time), is there anything to say that the manufacturer of such
> data-providing device should not have a CA key that could then be used to
> sign embedded timestamping certificates in the devices themselves?  Perhaps
> either by passing the data in to be timestamped, or by generating a
> self-contained "timestamp token" that would be embedded in the data before
> signing?
> 
> (I can see a market for a network-based service, as well... get a signed
> timetoken for $0.33, as much as it costs to get something postmarked at the
> USPS? :>)
> 
> The time data must be authenticated.  Otherwise, I could set my machine's
> clock in the past and sign something with an expired certificate that will
> -appear- to be valid.  There are two things that I can see that could stop
> this:
> 
> 1) A 'secure notary log' form of software, that logs everything that I sign,
> or
> 2) A 'trusted timestamp'.
> 
> With a 'trusted timestamp', we have a problem, though... what if I want to
> generate something later, but make it appear to be earlier?  I could request
> a timestamp of, say, 3 years ago, and not embed that into the data I want to
> sign until now.  So, we have to have a kind of dual-process system, where
> the embedded timestamp is the 'was-not-signed-before' date, and the wrapping
> timestamp is the 'was-not-signed-after' date.  And if the timesource is
> someone or something that is "trusted", then it's the window inside that
> makes the difference.
> 
> (Incidentally, I'm a techie who just got burned on not being able to prove
> when a physical document was signed, so I have my own agenda here, that is
> perhaps useful to more than just myself.)
> 
> -Mat Butler
> 
> -----Original Message-----
> From: todd glassey [mailto:[e-mail]]
> Sent: Wednesday, September 13, 2000 3:17 PM
> To: Denis Pinkas
> Cc: [e-mail]
> Subject: Re: The need for two grades of time data.
> 
> Denis,
> I apologize for the length of this response but you hit some hot spots for
> me - and I really dislike the provincial tone this has taken on, including
> my own. It is clear to me that there is emotional content for all concerned
> here and we need to rise above that as Time Stamping is way to
> important to the bigger picture of eBusiness and Audit/.Risk management.
> 
> Before you goon and read the response below and get ticked off  - let me say
> I myself  would support advancing the TSP Draft to Standard if it allowed
> for
> multiple use models, and updating to address emerging and audit driven
> needs. As it sits now it is too closed and restricted.
> 
> What we have in the TSP now  is a TTP based service model that does not
> authenticate the time data it claims is evidence - so the total reliance on
> the marque is based in proving some nebulous time data instance without a
> proofing model. Might as well be human testimony.
> 
> Your included text starts here
> --------------
> It seems that you are trying to re-open a discussion that took place
> in May 1999 (along BERT). So let me provide you with a copy of some
> E-mails from May 1999 so that we can *definitively* close this
> discussion.
> 
> Denis
> --------------
> 
> Since you have thrown the "this is a closed issue" down, let me say I
> disagree - it is my opinion that this was not decided by the group, or even
> debated openly.
> 
> I understand what the TSP is and does, I think from a commercial standpoint
> this is really not what time stamping systems want to be. Lets answer the
> following questions and see where that leads the group.
> 
> 1)    If the purpose of the time stamping protocol is to enable decision
> support processes by "validating signatures in time", then how is that the
> time data authentication process was overlooked? It seems to me that the
> credibility of the time data is directly tied to the believability resource
> produced by the Signature Validation Process, isn't it?  If so, then why
> would we leave that to an external CPS that was tied to the Host's operating
> environment or OS operation practices???
> 
> 2)    If the purpose of  the timestamp is evidentiary, then the quality of
> the time data, how it is authenticated, where it came from, and who it was
> certified by is critical to the trust process.
> 
> The need for a grade of time data that is nonrepudiated and is traceable to
> the BIPM or UTC /GeT is very important to the big picture and every trust
> process we build. To put our heads in the sand and claim that this is the
> OS's problem or that of the people that operate the system is also
> ludicrous.
> 
> The point is whether you are building an evidentiary system that can stand
> on its own, or one that requires the TSA to validate/use the marques of.
> You use PKI and other technologies to authenticate the source of the
> non-parametric data points, but not the time data. Why? and why cant the
> token stand on its own two feet?
> 
> 3)    Why constrain the system to a TTP architecture only? many of the legal
> processes we do today are based in Ceremony. Notorial, filing a legal
> document, etc. these are all based in ceremony. So the creation of the
> timestamp is essentially that ceremony. that means that the time stamp
> itself is the evidentiary token representing the completion of the
> ceremonial process and so the timestamps by themselves have value and worth
> in token exchange and processing models.
> 
> This is why BERT was so important - and as long as we are talking about the
> BERT...
> 
> BERT
> ------
> I agree with your commentary about how fast BERT was shot down - the BERT
> Token structure is clearly a threat to the TSP in that it does exactly what
> is defined in the three requirements above. Now I do have to admit that the
> initial BERT-1 Token Structure has some interesting problems with its
> granularity representation and a possible potential for the dual-events
> within the same granularity window, but that was fixed in the 2nd generation
> BERT-II  Structure, which I suppose I should file.
> 
> FYI - BERT-II turns the best of the XML and IOTP token processes into a TSP
> Evidentiary Token and not only addresses the content certification, but the
> type of the event as well. BERT-II supports virtually all key or crypto
> techniques and has plugin capabilities for building an event representation
> specific to the end-use needs. Its small  and expandable to also contain the
> content it watermarks as well and with this model, you don't need the Time
> Stamp
> Server just the BERT tool Set to extract or validate any of the components.
> 
> Just follow the use rules and there you are.
> 
> If anyone is interested in the BERT-II token structure prior to the Draft
> being filed in the next 2 weeks, send me a email and I will send the
> preliminary draft to you.
> 
> Todd
> 
> ---- Original Message -----
> From: "Denis Pinkas" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, September 13, 2000 3:57 AM
> Subject: Re: The need for two grades of time data.
> 
> Todd,
> 
> > Thanks for responding Steve, but again the real issue with
> > this concept of evidentiary time is in treating the parametric
> > time data as content rather than control process elements.
> > Once you do that it gets to be obvious that you need a
> > auth/certification stream and chain-of-custody model for that
> > time data to meet these evidentiary needs.
> 
> > So I have to ask - "What is the problem with treating time and
> > perhaps other parametric data like location data, as through
> > it had the same risks with it that the Human or Entity Identity
> > issues that spawned PKIX in the first place? because it does?"
> 
> > We seem to as a group have restricted our relating to time and
> > other parametric evidentiary processes as though they were only
> > part of the plumbing and it just aint so.
> 
> > Any of the data points that are use inside the decision support
> > process protocols that we are building (OCSP, TSP, etc etc etc)
> > are all tied to the requirement of some evidentiary anchor -
> > Someone or something has to sign that top level cert, some key
> > generator has to pump out that key pairing, and that data has been
> > sanctified by PKIX to date as it rightly should, but the use of
> > traditional Control Data points a parts of the larger evidentiary
> > or decision support process warrants that that data have the same
> > integrity as any other.
> 
> > Just my two cents.
> 
> =================================================================
> 
> Object:  Re: Comments on time-stamp-01: Identification of TSA
> Date:    Thu, 27 May 1999 13:55:18 -0400
> From:    Stephen Kent <[e-mail]>
> To:     "Todd S. Glassey - ELN" <[e-mail]>
> Copies:  <[e-mail]>
> 
> 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
> 
> =================================================================
> 
> Object: Re: Comments on time-stamp-01: Identification of TSA
> Date:   Fri, 28 May 1999 11:43:40 +0200
> From:   Denis Pinkas <[e-mail]>
> To:     "Todd S. Glassey - ELN" <[e-mail]>
> Copies: [e-mail]
> 
> 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
> 
> =================================================================
> 
> ... and finally an E-mail sent by Todd to me, not to the PKIX
> mailing list that is worth to mention:
> 
> Object:  Re: Long-term validation of signatures
> Date:    Mon, 26 Apr 1999 14:37:55 -0700
> From:    "Todd S. Glassey" <[e-mail]>
> To:      "Denis Pinkas" <[e-mail]>, "Hans Nilsson"
> <[e-mail]>
> 
> Denis, don't take my commentary wrong.
> The Draft(s) that you Pat, Carlisle, Robert produced are
> FANTASTIC!!!. They represent the first credible mechanism for a
> subsumable timebase service model and thats top-notch.
> 
> (snip)

-- 
=======================================================
Bruno Salgueiro       (mailto:[e-mail])
                   
Grupo de Trabalho de Certificação Digital
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

This message was digitally signed with a MULTICERT cer-
tificate to give an identity assurance. In order to
download the root MULTICERT certificate please go to :
             http://www.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================
--------------ms8E5C1FF41AA0D5B6E6B1B173
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

MIIFjwYJKoZIhvcNAQcCoIIFgDCCBXwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A80wggPJMIIDMqADAgECAgQ3TuB5MA0GCSqGSIb3DQEBBQUAMCgxCzAJBgNVBAYTAlBUMRkw
FwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MB4XDTAwMDYyNjExMDM0MVoXDTAxMDYyNjExMzM0
MVowYDELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTALBgNVBAsT
BFNJQlMxDTALBgNVBAsTBEdUQ0QxGDAWBgNVBAMTD0JydW5vIFNhbGd1ZWlybzCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA3qTimm/D/EzITGUcMQMaTxFpO1EvnQVN9te/6aGOz0B0
erA5D23/GZ8zd2WRefZoIjBBgZiYK90b1y7bcAbDp06iVhZcN6HtBfQvlgYij9q2+zBkfCG4
bmNQKsJK2RxGCd/YbJ2XeYU0n/A6SAmPOLX3+aPIjpAx2O+SYzqKdfkCAwEAAaOCAcYwggHC
MAsGA1UdDwQEAwIFoDArBgNVHRAEJDAigA8yMDAwMDYyNjExMzM0MVqBDzIwMDEwMzA4MjMz
MzQxWjARBglghkgBhvhCAQEEBAMCBaAwgakGCWCGSAGG+EIBDQSBmxaBmENlcnRpZmljYWRv
IFBJTE9UTyBNVUxUSWNlcnQuIEVzdGVzIGNlcnRpZmljYWRvcyBzYW8gZW1pdGlkb3MgYW8g
YWJyaWdvIGRvIENQUyBxdWUgc2UgZW5jb250cmEgbm8gc2VndWludGUgVVJMIC0gaHR0cHM6
Ly93d3cuc2licy5tdWx0aWNlcnQuY29tL2Nwcy5odG1sMBUGA1UdEQQOMAyBCmJzQHNpYnMu
cHQwSgYDVR0fBEMwQTA/oD2gO6Q5MDcxCzAJBgNVBAYTAlBUMRkwFwYDVQQKExBQSUxPVE8g
TVVMVEljZXJ0MQ0wCwYDVQQDEwRDUkwxMB8GA1UdIwQYMBaAFLiWIG3WTfGiSQxdd4FPSyQI
oi/lMB0GA1UdDgQWBBSNxWQEKMGcvdwOWLszw/uocQ+4NjAJBgNVHRMEAjAAMBkGCSqGSIb2
fQdBAAQMMAobBFY0LjADAgOoMA0GCSqGSIb3DQEBBQUAA4GBAGicAO4sFZ2fO7bR5ANwp9zQ
6EiIcmU+AbNCKGuK5tHQE3HPDRpoUPtjLRmVMhnxKtfBUVClZ6lxYdONh3TpHiEYex1bKOlg
h7fVHXprtEz1vKpl//afvGCHaocfDrNEtmLfarSKCx3vETSLiEiDOMjL+3QCx82kSiJeG+3f
wjQ7MYIBijCCAYYCAQEwMDAoMQswCQYDVQQGEwJQVDEZMBcGA1UEChMQUElMT1RPIE1VTFRJ
Y2VydAIEN07geTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTAwMDkxNDEwMTE0OFowIwYJKoZIhvcNAQkEMRYEFDtlhmBrcHMQ/f8i
Fazrlg0EwsaMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA
BIGADm4Ri0eD+eusWtW9UlR5xAm+z7OIVvr1KTi5FJou8utF7Friwh0QTWeF0ELXzY61wCCs
eW+Juv0s5mSnevZZVnJ3xoH8XHB4EVDCNQZcnCdftRZBNqI75rH16HHYcqWBaNTX0LShVzsl
GAdlx4VHrY8LuTg+Y0UypOLCJBRkdDk=
--------------ms8E5C1FF41AA0D5B6E6B1B173--



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04437 for <[e-mail]>; Thu, 14 Sep 2000 00:21:36 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA15174; Thu, 14 Sep 2000 09:28:39 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA14694; Thu, 14 Sep 2000 09:23:16 +0200
Message-ID: <[e-mail]>
Date: Thu, 14 Sep 2000 09:23:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Eric Norman <[e-mail]>
CC: [e-mail]
Subject: Re: CRLs and expired certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

> > If so is there any way to check if a certificate was valid when it was used
> > to sign something a long time ago and that certificate has now expired, and
> > does this make any sense or would this not prove anything?
> 
> Makes sense to me.  Suppose that I go to my life insurance company's
> web page and change the beneficiary of my policy.  My digital
> signature is required.  20 or 30 years later I die.  How will someone
> verify that my private key wasn't compromised 20 or 30 years ago?

Take a look at : 

Electronic Signature Formats for long term electronic signature:
http://www.imc.org/draft-ietf-smime-esformats

and 

Electronic Signature Policies:
http://www.imc.org/draft-ietf-smime-espolicies

Denis

> Eric Norman
> 
>         "Congress shall make no law restricting the size of integers
>         that may be multiplied together, or the number of times that
>         an integer may be multiplied by itself, or the modulus by
>         which an integer may be reduced".


Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25064 for <[e-mail]>; Wed, 13 Sep 2000 16:39:51 -0700 (PDT)
Received: by MAIL with Internet Mail Service (5.5.2650.21) id <SFPZPNK3>; Wed, 13 Sep 2000 16:36:51 -0700
Message-ID: <69A40A314934D41190C70050DAD7F99063B5F4@MAIL>
From: Mathew  Butler <[e-mail]>
To: "'todd glassey'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: The need for two grades of time data.
Date: Wed, 13 Sep 2000 16:36:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Oooh, this is a 'pet project' thing.

I agree that the time needs to be authenticated, and perhaps more
importantly, the source of the time needs to be authenticated.  Network Time
Protocol et al notwithstanding, it's far too easy for a single machine's
clock to be adjusted for whatever reason.  (And, with NTP, for the entire
network's time to be adjusted.)

So, we cannot trust anything that comes out of a single network.  Now, if
there's a device that provides an accurate source of time data (such as by
listening to the US Naval Observatory time radio frequency, or the GPS
date/time), is there anything to say that the manufacturer of such
data-providing device should not have a CA key that could then be used to
sign embedded timestamping certificates in the devices themselves?  Perhaps
either by passing the data in to be timestamped, or by generating a
self-contained "timestamp token" that would be embedded in the data before
signing?

(I can see a market for a network-based service, as well... get a signed
timetoken for $0.33, as much as it costs to get something postmarked at the
USPS? :>)

The time data must be authenticated.  Otherwise, I could set my machine's
clock in the past and sign something with an expired certificate that will
-appear- to be valid.  There are two things that I can see that could stop
this:

1) A 'secure notary log' form of software, that logs everything that I sign,
or
2) A 'trusted timestamp'.

With a 'trusted timestamp', we have a problem, though... what if I want to
generate something later, but make it appear to be earlier?  I could request
a timestamp of, say, 3 years ago, and not embed that into the data I want to
sign until now.  So, we have to have a kind of dual-process system, where
the embedded timestamp is the 'was-not-signed-before' date, and the wrapping
timestamp is the 'was-not-signed-after' date.  And if the timesource is
someone or something that is "trusted", then it's the window inside that
makes the difference.

(Incidentally, I'm a techie who just got burned on not being able to prove
when a physical document was signed, so I have my own agenda here, that is
perhaps useful to more than just myself.)

-Mat Butler

-----Original Message-----
From: todd glassey [mailto:[e-mail]]
Sent: Wednesday, September 13, 2000 3:17 PM
To: Denis Pinkas
Cc: [e-mail]
Subject: Re: The need for two grades of time data.


Denis,
I apologize for the length of this response but you hit some hot spots for
me - and I really dislike the provincial tone this has taken on, including
my own. It is clear to me that there is emotional content for all concerned
here and we need to rise above that as Time Stamping is way to
important to the bigger picture of eBusiness and Audit/.Risk management.

Before you goon and read the response below and get ticked off  - let me say
I myself  would support advancing the TSP Draft to Standard if it allowed
for
multiple use models, and updating to address emerging and audit driven
needs. As it sits now it is too closed and restricted.

What we have in the TSP now  is a TTP based service model that does not
authenticate the time data it claims is evidence - so the total reliance on
the marque is based in proving some nebulous time data instance without a
proofing model. Might as well be human testimony.

Your included text starts here
--------------
It seems that you are trying to re-open a discussion that took place
in May 1999 (along BERT). So let me provide you with a copy of some
E-mails from May 1999 so that we can *definitively* close this
discussion.

Denis
--------------

Since you have thrown the "this is a closed issue" down, let me say I
disagree - it is my opinion that this was not decided by the group, or even
debated openly.

I understand what the TSP is and does, I think from a commercial standpoint
this is really not what time stamping systems want to be. Lets answer the
following questions and see where that leads the group.

1)    If the purpose of the time stamping protocol is to enable decision
support processes by "validating signatures in time", then how is that the
time data authentication process was overlooked? It seems to me that the
credibility of the time data is directly tied to the believability resource
produced by the Signature Validation Process, isn't it?  If so, then why
would we leave that to an external CPS that was tied to the Host's operating
environment or OS operation practices???

2)    If the purpose of  the timestamp is evidentiary, then the quality of
the time data, how it is authenticated, where it came from, and who it was
certified by is critical to the trust process.

The need for a grade of time data that is nonrepudiated and is traceable to
the BIPM or UTC /GeT is very important to the big picture and every trust
process we build. To put our heads in the sand and claim that this is the
OS's problem or that of the people that operate the system is also
ludicrous.

The point is whether you are building an evidentiary system that can stand
on its own, or one that requires the TSA to validate/use the marques of.
You use PKI and other technologies to authenticate the source of the
non-parametric data points, but not the time data. Why? and why cant the
token stand on its own two feet?

3)    Why constrain the system to a TTP architecture only? many of the legal
processes we do today are based in Ceremony. Notorial, filing a legal
document, etc. these are all based in ceremony. So the creation of the
timestamp is essentially that ceremony. that means that the time stamp
itself is the evidentiary token representing the completion of the
ceremonial process and so the timestamps by themselves have value and worth
in token exchange and processing models.

This is why BERT was so important - and as long as we are talking about the
BERT...



BERT
------
I agree with your commentary about how fast BERT was shot down - the BERT
Token structure is clearly a threat to the TSP in that it does exactly what
is defined in the three requirements above. Now I do have to admit that the
initial BERT-1 Token Structure has some interesting problems with its
granularity representation and a possible potential for the dual-events
within the same granularity window, but that was fixed in the 2nd generation
BERT-II  Structure, which I suppose I should file.

FYI - BERT-II turns the best of the XML and IOTP token processes into a TSP
Evidentiary Token and not only addresses the content certification, but the
type of the event as well. BERT-II supports virtually all key or crypto
techniques and has plugin capabilities for building an event representation
specific to the end-use needs. Its small  and expandable to also contain the
content it watermarks as well and with this model, you don't need the Time
Stamp
Server just the BERT tool Set to extract or validate any of the components.

Just follow the use rules and there you are.

If anyone is interested in the BERT-II token structure prior to the Draft
being filed in the next 2 weeks, send me a email and I will send the
preliminary draft to you.

Todd


---- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 13, 2000 3:57 AM
Subject: Re: The need for two grades of time data.


Todd,

> Thanks for responding Steve, but again the real issue with
> this concept of evidentiary time is in treating the parametric
> time data as content rather than control process elements.
> Once you do that it gets to be obvious that you need a
> auth/certification stream and chain-of-custody model for that
> time data to meet these evidentiary needs.

> So I have to ask - "What is the problem with treating time and
> perhaps other parametric data like location data, as through
> it had the same risks with it that the Human or Entity Identity
> issues that spawned PKIX in the first place? because it does?"

> We seem to as a group have restricted our relating to time and
> other parametric evidentiary processes as though they were only
> part of the plumbing and it just aint so.

> Any of the data points that are use inside the decision support
> process protocols that we are building (OCSP, TSP, etc etc etc)
> are all tied to the requirement of some evidentiary anchor -
> Someone or something has to sign that top level cert, some key
> generator has to pump out that key pairing, and that data has been
> sanctified by PKIX to date as it rightly should, but the use of
> traditional Control Data points a parts of the larger evidentiary
> or decision support process warrants that that data have the same
> integrity as any other.

> Just my two cents.


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

Object:  Re: Comments on time-stamp-01: Identification of TSA
Date:    Thu, 27 May 1999 13:55:18 -0400
From:    Stephen Kent <[e-mail]>
To:     "Todd S. Glassey - ELN" <[e-mail]>
Copies:  <[e-mail]>

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

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

Object: Re: Comments on time-stamp-01: Identification of TSA
Date:   Fri, 28 May 1999 11:43:40 +0200
From:   Denis Pinkas <[e-mail]>
To:     "Todd S. Glassey - ELN" <[e-mail]>
Copies: [e-mail]

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

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

... and finally an E-mail sent by Todd to me, not to the PKIX
mailing list that is worth to mention:

Object:  Re: Long-term validation of signatures
Date:    Mon, 26 Apr 1999 14:37:55 -0700
From:    "Todd S. Glassey" <[e-mail]>
To:      "Denis Pinkas" <[e-mail]>, "Hans Nilsson"
<[e-mail]>


Denis, don't take my commentary wrong.
The Draft(s) that you Pat, Carlisle, Robert produced are
FANTASTIC!!!. They represent the first credible mechanism for a
subsumable timebase service model and thats top-notch.

(snip)



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23905 for <[e-mail]>; Wed, 13 Sep 2000 15:15:59 -0700 (PDT)
Received: from tsg1 ([12.72.64.64]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913221739.ZATT6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 22:17:39 +0000
Message-ID: <03a101c01dd0$52afa620$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <006d01c01d1e$a8403b20$020aff0c@tsg1> <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Wed, 13 Sep 2000 15:16:50 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Denis,
I apologize for the length of this response but you hit some hot spots for
me - and I really dislike the provincial tone this has taken on, including
my own. It is clear to me that there is emotional content for all concerned
here and we need to rise above that as Time Stamping is way to
important to the bigger picture of eBusiness and Audit/.Risk management.

Before you goon and read the response below and get ticked off  - let me say
I myself  would support advancing the TSP Draft to Standard if it allowed
for
multiple use models, and updating to address emerging and audit driven
needs. As it sits now it is too closed and restricted.

What we have in the TSP now  is a TTP based service model that does not
authenticate the time data it claims is evidence - so the total reliance on
the marque is based in proving some nebulous time data instance without a
proofing model. Might as well be human testimony.

Your included text starts here
--------------
It seems that you are trying to re-open a discussion that took place
in May 1999 (along BERT). So let me provide you with a copy of some
E-mails from May 1999 so that we can *definitively* close this
discussion.

Denis
--------------

Since you have thrown the "this is a closed issue" down, let me say I
disagree - it is my opinion that this was not decided by the group, or even
debated openly.

I understand what the TSP is and does, I think from a commercial standpoint
this is really not what time stamping systems want to be. Lets answer the
following questions and see where that leads the group.

1)    If the purpose of the time stamping protocol is to enable decision
support processes by "validating signatures in time", then how is that the
time data authentication process was overlooked? It seems to me that the
credibility of the time data is directly tied to the believability resource
produced by the Signature Validation Process, isn't it?  If so, then why
would we leave that to an external CPS that was tied to the Host's operating
environment or OS operation practices???

2)    If the purpose of  the timestamp is evidentiary, then the quality of
the time data, how it is authenticated, where it came from, and who it was
certified by is critical to the trust process.

The need for a grade of time data that is nonrepudiated and is traceable to
the BIPM or UTC /GeT is very important to the big picture and every trust
process we build. To put our heads in the sand and claim that this is the
OS's problem or that of the people that operate the system is also
ludicrous.

The point is whether you are building an evidentiary system that can stand
on its own, or one that requires the TSA to validate/use the marques of.
You use PKI and other technologies to authenticate the source of the
non-parametric data points, but not the time data. Why? and why cant the
token stand on its own two feet?

3)    Why constrain the system to a TTP architecture only? many of the legal
processes we do today are based in Ceremony. Notorial, filing a legal
document, etc. these are all based in ceremony. So the creation of the
timestamp is essentially that ceremony. that means that the time stamp
itself is the evidentiary token representing the completion of the
ceremonial process and so the timestamps by themselves have value and worth
in token exchange and processing models.

This is why BERT was so important - and as long as we are talking about the
BERT...



BERT
------
I agree with your commentary about how fast BERT was shot down - the BERT
Token structure is clearly a threat to the TSP in that it does exactly what
is defined in the three requirements above. Now I do have to admit that the
initial BERT-1 Token Structure has some interesting problems with its
granularity representation and a possible potential for the dual-events
within the same granularity window, but that was fixed in the 2nd generation
BERT-II  Structure, which I suppose I should file.

FYI - BERT-II turns the best of the XML and IOTP token processes into a TSP
Evidentiary Token and not only addresses the content certification, but the
type of the event as well. BERT-II supports virtually all key or crypto
techniques and has plugin capabilities for building an event representation
specific to the end-use needs. Its small  and expandable to also contain the
content it watermarks as well and with this model, you don't need the Time
Stamp
Server just the BERT tool Set to extract or validate any of the components.

Just follow the use rules and there you are.

If anyone is interested in the BERT-II token structure prior to the Draft
being filed in the next 2 weeks, send me a email and I will send the
preliminary draft to you.

Todd


---- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 13, 2000 3:57 AM
Subject: Re: The need for two grades of time data.


Todd,

> Thanks for responding Steve, but again the real issue with
> this concept of evidentiary time is in treating the parametric
> time data as content rather than control process elements.
> Once you do that it gets to be obvious that you need a
> auth/certification stream and chain-of-custody model for that
> time data to meet these evidentiary needs.

> So I have to ask - "What is the problem with treating time and
> perhaps other parametric data like location data, as through
> it had the same risks with it that the Human or Entity Identity
> issues that spawned PKIX in the first place? because it does?"

> We seem to as a group have restricted our relating to time and
> other parametric evidentiary processes as though they were only
> part of the plumbing and it just aint so.

> Any of the data points that are use inside the decision support
> process protocols that we are building (OCSP, TSP, etc etc etc)
> are all tied to the requirement of some evidentiary anchor -
> Someone or something has to sign that top level cert, some key
> generator has to pump out that key pairing, and that data has been
> sanctified by PKIX to date as it rightly should, but the use of
> traditional Control Data points a parts of the larger evidentiary
> or decision support process warrants that that data have the same
> integrity as any other.

> Just my two cents.


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

Object:  Re: Comments on time-stamp-01: Identification of TSA
Date:    Thu, 27 May 1999 13:55:18 -0400
From:    Stephen Kent <[e-mail]>
To:     "Todd S. Glassey - ELN" <[e-mail]>
Copies:  <[e-mail]>

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

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

Object: Re: Comments on time-stamp-01: Identification of TSA
Date:   Fri, 28 May 1999 11:43:40 +0200
From:   Denis Pinkas <[e-mail]>
To:     "Todd S. Glassey - ELN" <[e-mail]>
Copies: [e-mail]

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

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

... and finally an E-mail sent by Todd to me, not to the PKIX
mailing list that is worth to mention:

Object:  Re: Long-term validation of signatures
Date:    Mon, 26 Apr 1999 14:37:55 -0700
From:    "Todd S. Glassey" <[e-mail]>
To:      "Denis Pinkas" <[e-mail]>, "Hans Nilsson"
<[e-mail]>


Denis, don't take my commentary wrong.
The Draft(s) that you Pat, Carlisle, Robert produced are
FANTASTIC!!!. They represent the first credible mechanism for a
subsumable timebase service model and thats top-notch.

(snip)




Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21858 for <[e-mail]>; Wed, 13 Sep 2000 13:33:40 -0700 (PDT)
Received: from jeffdavis (man-a151.dialup.zetnet.co.uk [194.247.44.151]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id VAA32473; Wed, 13 Sep 2000 21:35:51 +0100
X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a151.dialup.zetnet.co.uk [194.247.44.151] claimed to be jeffdavis
Message-ID: <002901c01dc2$109e3ac0$[e-mail]>
From: "Jeff Davis" <[e-mail]>
To: <[e-mail]>, "Bob Jueneman" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: New hash algorithms
Date: Wed, 13 Sep 2000 21:25:52 +0100
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.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Bob/Byron

Many thanks for your explanations, I now understand much better.

Jeff

<Original messages cut> 



Received: from crack.x509.com ([e-mail] [199.175.150.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20938 for <[e-mail]>; Wed, 13 Sep 2000 12:45:42 -0700 (PDT)
Received: from xcert.com (mscherling-2k.x509.com [199.175.148.209]) by crack.x509.com (8.10.0/XCERT) with ESMTP id e8DJlrS13233; Wed, 13 Sep 2000 12:47:53 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 12:47:08 -0700
From: Mark Scherling <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Norman <[e-mail]>
CC: [e-mail]
Subject: Re: CRLs and expired certificates
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

That revolves around your archive process and how you manage your documents.  The
verification of the private key (public signing key) would be a function of CRL
archive and being able to extract that information.

The fact that the policy may have changed and that type of transaction was
allowed at that time but not now may need to be preserved.  If we use common law
as an example in some states you are now allowed to go through a stop sign being
the second or third car and turning right.  This is needed to speed up the
traffic flow and prevent traffic jams.  Years before you would have received a
ticket.

If you perform a transaction today and the law/process changes you need to have
all the pieces of the transaction to enact that transaction including policy,
process, business and legal aspects.   There are sections in most policies that
deal with archive but a lot do not extend past 10 years.  One of the other
problems is the preservation of the technology and applications that the
transaction was completed on (remember AES, TRS80, PDP, etc). Electronic
information preservation is still not stable and even the use of CDROM or WORM is
still evolving (DVD).

I hope that I've added fuel for thought and given people something more to
consider.

Eric Norman wrote:

> On Wed, 13 Sep 2000, Tim Fowle wrote:
>
> > If so is there any way to check if a certificate was valid when it was used
> > to sign something a long time ago and that certificate has now expired, and
> > does this make any sense or would this not prove anything?
>
> Makes sense to me.  Suppose that I go to my life insurance company's
> web page and change the beneficiary of my policy.  My digital
> signature is required.  20 or 30 years later I die.  How will someone
> verify that my private key wasn't compromised 20 or 30 years ago?
>
> Eric Norman
>
>         "Congress shall make no law restricting the size of integers
>         that may be multiplied together, or the number of times that
>         an integer may be multiplied by itself, or the modulus by
>         which an integer may be reduced".



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20702 for <[e-mail]>; Wed, 13 Sep 2000 12:43:09 -0700 (PDT)
Received: from tsg1 ([12.72.64.64]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913194448.WMMM6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 19:44:48 +0000
Message-ID: <02b301c01dba$f870f9d0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <025e01c01daf$b7627820$020aff0c@tsg1> <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Wed, 13 Sep 2000 12:44:01 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Thanks Ben,
and yes you're right - Let me clarify - I am not saying anything as to how
to qualify the trust anchor players, that is really something that the Risk
Managers, Auditors, and Legal Professionals should do. What I am trying to
accomplish is to get the TSP to be capable of being a self contained
evidentiary service model.

Its bad enough in an evidentiary model that the TSP requires the TSA to use
the TST's. The TST structures could actually take on digital receipt status
if they were formalized and that would be a real win.

Todd

----- Original Message -----
From: "Ben Laurie" <[e-mail]>
To: "todd glassey" <[e-mail]>
Sent: Wednesday, September 13, 2000 11:33 AM
Subject: Re: The need for two grades of time data.


> todd glassey wrote:
> >
> > Theoretically, at least it was what it was supposed to do. The question
here
> > is "is this really what the protocol does" - My take is not.
>
> People seem to think that you are asking the IETF to mandate who should
> be allowed to sign times. If you aren't, you need to make that clear.
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> Coming to ApacheCon Europe 2000? http://apachecon.com/
>



Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA20426 for <[e-mail]>; Wed, 13 Sep 2000 12:36:53 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA99794; Wed, 13 Sep 2000 15:38:42 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id PAA55534; Wed, 13 Sep 2000 15:38:55 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256959.006BE747 ; Wed, 13 Sep 2000 15:38:35 -0400
X-Lotus-FromDomain: IBMUS
To: Eric Norman <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 15:38:37 -0400
Subject: Re: CRLs and expired certificates
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     If the RP wishes to be sure that some evidence of this sort is
preserved, he (or an agent he has agreed on) can preserve it himself.  In
draft-ietf-pkix-technr-01.txt, some rules are given for which revocation or
non-revocation indications need to be preserved.  See sections 3.7, 4.6,
and 5.5 of that draft.

          Tom Gindin

Eric Norman <[e-mail]> on 09/13/2000 03:18:07 PM

To:   [e-mail]
cc:
Subject:  Re: CRLs and expired certificates



On Wed, 13 Sep 2000, Tim Fowle wrote:

> If so is there any way to check if a certificate was valid when it was
used
> to sign something a long time ago and that certificate has now expired,
and
> does this make any sense or would this not prove anything?

Makes sense to me.  Suppose that I go to my life insurance company's
web page and change the beneficiary of my policy.  My digital
signature is required.  20 or 30 years later I die.  How will someone
verify that my private key wasn't compromised 20 or 30 years ago?


Eric Norman

     "Congress shall make no law restricting the size of integers
     that may be multiplied together, or the number of times that
     an integer may be multiplied by itself, or the modulus by
     which an integer may be reduced".




Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19884 for <[e-mail]>; Wed, 13 Sep 2000 12:15:56 -0700 (PDT)
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.3) with ESMTP id 3362498 for [e-mail]; Wed, 13 Sep 2000 14:18:07 -0500
Date: Wed, 13 Sep 2000 14:18:07 -0500 (CDT)
From: Eric Norman <[e-mail]>
To: [e-mail]
Subject: Re: CRLs and expired certificates
In-Reply-To: <4.3.2.7.2.20000913173651.00b54c00@192.168.0.1>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 13 Sep 2000, Tim Fowle wrote:

> If so is there any way to check if a certificate was valid when it was used 
> to sign something a long time ago and that certificate has now expired, and 
> does this make any sense or would this not prove anything?

Makes sense to me.  Suppose that I go to my life insurance company's
web page and change the beneficiary of my policy.  My digital
signature is required.  20 or 30 years later I die.  How will someone
verify that my private key wasn't compromised 20 or 30 years ago?


Eric Norman

	"Congress shall make no law restricting the size of integers
	that may be multiplied together, or the number of times that
	an integer may be multiplied by itself, or the modulus by
	which an integer may be reduced".



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19017 for <[e-mail]>; Wed, 13 Sep 2000 11:36:29 -0700 (PDT)
Received: from tsg1 ([12.72.64.64]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913183823.VLMI6605.mtiwmhc25.worldnet.att.net@tsg1> for <[e-mail]>; Wed, 13 Sep 2000 18:38:23 +0000
Message-ID: <028301c01db1$b1b10840$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Subject: Fw: The need for two grades of time data.
Date: Wed, 13 Sep 2000 11:37:37 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

----- Original Message -----
From: "todd glassey" <[e-mail]>
To: "Rich Salz" <[e-mail]>
Sent: Wednesday, September 13, 2000 11:37 AM
Subject: Re: The need for two grades of time data.


> SNIP
>
> > As for Bob's point about "who says it's that time" -- isn't this the
> > same as "who signed the cert binding the name to the key"?  Again, not
> > in our purview.
>
> Sure it is Rich - We are not answering the question itself, just creating
> the mechanism through which it may be answered. thats the difference here.
>
> No one said that you have to use the extra overhead of certifiable and
> audited timebase services, but if ou need that level of trust you should
be
> able to get it in the general use model we are proposing here.
>
> If not what I bethappens is that some other standard that addresses
exactly
> this eventially absorbs the lower-security TSP model and thus the TSP
Draft
> is made part of a larger Evidentiary grade transaction framework as an
> optional LOW TRUST variant.
>
> The issue of the uniform Binary Token is still looming to deal with
though.
>
> Todd
>
> > /r$
>



Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17379 for <[e-mail]>; Wed, 13 Sep 2000 10:57:19 -0700 (PDT)
Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA02212 for <[e-mail]>; Wed, 13 Sep 2000 18:59:21 +0100 (BST)
Received: from jap.ecs.soton.ac.uk (jap.ecs.soton.ac.uk [152.78.69.201]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id SAA23072 for <[e-mail]>; Wed, 13 Sep 2000 18:59:20 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 13 Sep 2000 18:54:01 +0100
To: [e-mail]
From: J Adrian Pickering <[e-mail]>
Subject: Re: The need for two grades of time data.
In-Reply-To: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]> <01d901c01d9e$7d678b30$020aff0c@tsg1> <[e-mail]> <01f101c01da4$1b7c58f0$020aff0c@tsg1> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 18:38 13/09/00 +0100, Ben Laurie wrote:
>Rich Salz wrote:
> > As for Bob's point about "who says it's that time" -- isn't this the
> > same as "who signed the cert binding the name to the key"?  Again, not
> > in our purview.
>
>Now I'm confused. We provide a mechanism by which that can be
>ascertained. Of course, we don't care who, in particular, it is, but we
>do care that that can be determined, don't we?

We should. We should ensure that the technical support for this is as best 
as it possibly can be. Take care with that word 'who'. TSA's are automatons 
and will probably grow to stamping millions of transactions per hour, all 
potentially of legal significance.

To repeat Bob's statement:

'I believe that what Todd is trying to say is that the question isn't,
"What time is it?" but rather "What time is it, and who says so, and
why should anyone believe them?"'

1. What time is it? - there are technical fixes for this (but be aware of 
Bob's chronometer story!)

2. Who says so? - we have to trust the TSA's signing. However, who 'is' the 
TSA and who (i.e. what human) is going to vouch for its proper operation? 
Who manages the TSA's certificate? Probably some system that also features 
a PKIX time stamper...

3. Why should anyone believe them? - beats me. My reading of the US Rules 
of Evidence leads me to believe this is going to be very tricky. It'll also 
be so in the UK, especially in criminal cases.


Adrian Pickering/
ECS, University of Southampton, UK




Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA16616 for <[e-mail]>; Wed, 13 Sep 2000 10:36:54 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id SAA16333; Wed, 13 Sep 2000 18:44:27 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 18:38:48 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
MIME-Version: 1.0
To: Rich Salz <[e-mail]>
CC: todd glassey <[e-mail]>, [e-mail]
Subject: Re: The need for two grades of time data.
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]> <01d901c01d9e$7d678b30$020aff0c@tsg1> <[e-mail]> <01f101c01da4$1b7c58f0$020aff0c@tsg1> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rich Salz wrote:
> As for Bob's point about "who says it's that time" -- isn't this the
> same as "who signed the cert binding the name to the key"?  Again, not
> in our purview.

Now I'm confused. We provide a mechanism by which that can be
ascertained. Of course, we don't care who, in particular, it is, but we
do care that that can be determined, don't we?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA16157 for <[e-mail]>; Wed, 13 Sep 2000 10:26:21 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 02213622; Wed, 13 Sep 2000 13:28:25 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 13:31:17 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: The need for two grades of time data.
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]> <01d901c01d9e$7d678b30$020aff0c@tsg1> <[e-mail]> <01f101c01da4$1b7c58f0$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> Rich I still disagree with you and pretty strongly too -

Apparently so. :)   I'm hoping this will be my last note on this topic
-- it's probably time for the rough consensus to take over.

> Anything I sign with my Digital Cert is represented as my wet
> signature under the law

Anything?  No.  There can be a whole bunch of important exceptions (Sec.
103), and as I read the "consent" sections -- it's only equivalent to a
wet signature if I agree to accept it, or be bound by it when signing to
you.
Again, I only make these points to show out out-of-scope these
conversations are, here.  Feel free to rebut away; I'll remain silent.
:)

As for Bob's point about "who says it's that time" -- isn't this the
same as "who signed the cert binding the name to the key"?  Again, not
in our purview.
	/r$


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA15591 for <[e-mail]>; Wed, 13 Sep 2000 10:12:52 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id SAA16199; Wed, 13 Sep 2000 18:19:58 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 18:14:19 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: The need for two grades of time data.
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> 
> I believe that what Todd is trying to say is that the question isn't,
> "What time is it?" but rather "What time is it, and who says so, and
> why should anyone believe them?"
> 
> If I have correctly understood his position, I think he has an
> excellent point.

Err ... isn't that what TSP is for?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15070 for <[e-mail]>; Wed, 13 Sep 2000 09:59:25 -0700 (PDT)
Received: from tsg1 ([12.72.64.64]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913170107.TZVS6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 17:01:07 +0000
Message-ID: <01f101c01da4$1b7c58f0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Rich Salz" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]> <01d901c01d9e$7d678b30$020aff0c@tsg1> <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Wed, 13 Sep 2000 10:00:22 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Rich I still disagree with you and pretty strongly too -
----- Original Message -----
From: "Rich Salz" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 13, 2000 9:41 AM
Subject: Re: The need for two grades of time data.


> > we ignore the need to provide proofing as to what the time data is and
> > where it came from
>
> This makes sense.  It also reinforces my belief that it doesn't belong
> in the IETF any more than proof that IBM.COM really is, IBM. :)

Except that what you are now talking about is operating the trust process
rather than architecting it, and of course the IETF is not a commercial
trust provider. That goes without saying. the issue here is in architecing
systems that do not support the needs of current and obviously emerging
laws, standards, and BCP models, and since we set so few of those in the
Techno Puratory of the PKIX WG we ned to be aware of them above us. Heck,
even the forges of the underworld took input from Zeus.

>
> > In fact that the X509 Digitally Signed Documents now automatically have
> > legal consequence here in the States, in my mind opens a whole new realm
> > of requirements for us to have to take into account. Does this explain
> > what I mean?
>
> They don't automatically have legal consequence; they lost the automatic
> non-legal status.

Sure they do. Anything I sign with my Digital Cert is represented as my wet
signature under the law . Making it essentially  a legal instrument of my
agency. That's just the way it is.

>That's a big, but apparently subtle, distinction,
> that yet again shows why evidentiary issues are beyond our ken.

No not true. It shows why its so important for our second-tier processes,
protocol models, and BCP's to be so closely tied to what is applicable. As
to the core tier one standards they rely on, that is another issue.

Todd

> /r$
>



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14719 for <[e-mail]>; Wed, 13 Sep 2000 09:51:17 -0700 (PDT)
Received: from tsg1 ([12.72.64.64]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913165258.TWRN6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 16:52:58 +0000
Message-ID: <01ea01c01da2$f83cde60$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "Ruven Schwartz" <[e-mail]>
References: <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Wed, 13 Sep 2000 09:52:13 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Absolutely - This is right on the money!

Thanks Bob

----- Original Message -----
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 13, 2000 9:02 AM
Subject: Re: The need for two grades of time data.


I believe that what Todd is trying to say is that the question isn't,
"What time is it?" but rather "What time is it, and who says so, and
why should anyone believe them?"

If I have correctly understood his position, I think he has an
excellent point.

I think I have told this story before, but when I was a kid in
Cheyenne, there was a jewelry store that had a very fancy
nautical chronometer displayed in their window, and many
people in town used it to set their watches.

One day, the jeweler observed an executive of the Union Pacific
Railroad setting his watch, and they got to talking about time.  The
executive said rather proudly that he set his watch according to the
jeweler's chronometer every day, and then adjusted their railroad
clock accordingly, including the clock that blew the noon whistle.
The jeweler blanched, and said, "But I set my chronometer according
to your whistle!"

Isn't necessary to get  involved in all of the intricacies of various
legal system, and what constitutes acceptable evidence, to realize that
like all weights and measures, the standards must eventually be
shown to be traceable back to an agreed-upon source.

If absolute time is important, then the traceability of that time back to
an agreed-upon reference is important.  One way to beat a speeding
ticket is to challenge the calibration of the radar gun and/or the
speedometer of the cop car, and the same principle will apply here.

(Whether absolute time ought to be all that important is a different matter,
but if it is, the same chain of custody issues should apply as apply to
a certificate chain.)

Bob



>>> Stephen Kent <[e-mail]> 09/13/00 09:09AM >>>
Todd,

>Thanks for responding Steve, but again the real issue with this
>concept of evidentiary time is in treating the parametric time data
>as content rather than control process elements. Once you do that it
>gets to be obvious that you need a auth/certification stream and
>chain-of-custody model for that time data to meet these evidentiary
>needs.
>
>So I have to ask - "What is the problem with treating time and
>perhaps other parametric data like location data, as through it had
>the same risks with it that the Human or Entity Identity issues that
>spawned PKIX in the first place? because it does?"
>
>We seem to as a group have restricted our relating to time and other
>parametric evidentiary processes as though they were only part of
>the plumbing and it just aint so.
>
>Any of the data points that are use inside the decision support
>process protocols that we are building (OCSP, TSP, etc etc etc) are
>all tied to the requirement of some evidentiary anchor - Someone or
>something has to sign that top level cert, some key generator has to
>pump out that key pairing, and that data has been sanctified by PKIX
>to date as it rightly should, but the use of traditional Control
>Data points a parts of the larger evidentiary or decision support
>process warrants that that data have the same integrity as any other.

I sometimes have trouble parsing your text; this is one of those
times. There must be a clearer way to communicate what you're trying
to state. Please try again.

Steve




Received: from aol.com (host-00-20-78-cd-ca-69-nat.adsl.catt.com [63.105.254.111]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA14088 for <[e-mail]>; Wed, 13 Sep 2000 09:37:06 -0700 (PDT)
Date: Wed, 13 Sep 2000 09:37:06 -0700 (PDT)
Message-Id: <[e-mail]>
To: [e-mail]
From: "Stephen Lee" <[e-mail]>
X-Mailer: 3EBA38B4.70895C89.22ef5cd2c001436f7c0f8b2ed824f32a
Subject: Stephen Lee  - Question
Organization:

Hello my name is Stephen Lee.  :o)
 
I ran accross your E-mail address on http://www.imc.org/ietf-pkix/mail-archive/msg09415.html (under e-mail+marketing+sales in altavista's search engine) and wanted to tell you that I use a software program that filters my email for me and also sends out personal emails to my customers all automatically while I am away from my desk.
 
PS - It even has an unlimited number of built in autoresponders, it can import orders into your database, and it even has a built in newsletter server as well which I use all of the time.  
 
Let me know if you are interested and I will send you the hyperlink to it where you can download it and try it out for yourself.  It has been the most useful tool to me and I hope it can help you out too!!
 
Sincerely,
Stephen Lee  :o)


Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA13853 for <[e-mail]>; Wed, 13 Sep 2000 09:36:17 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 013132321; Wed, 13 Sep 2000 12:38:14 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 12:41:05 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: The need for two grades of time data.
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]> <01d901c01d9e$7d678b30$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

> we ignore the need to provide proofing as to what the time data is and
> where it came from

This makes sense.  It also reinforces my belief that it doesn't belong
in the IETF any more than proof that IBM.COM really is, IBM. :)

> In fact that the X509 Digitally Signed Documents now automatically have
> legal consequence here in the States, in my mind opens a whole new realm
> of requirements for us to have to take into account. Does this explain
> what I mean?

They don't automatically have legal consequence; they lost the automatic
non-legal status.  That's a big, but apparently subtle, distinction,
that yet again shows why evidentiary issues are beyond our ken.
	/r$


Received: from warrior-outbound.servers.plus.net ([212.159.14.227]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA13643 for <[e-mail]>; Wed, 13 Sep 2000 09:35:18 -0700 (PDT)
Received: (qmail 20203 invoked from network); 13 Sep 2000 16:36:45 -0000
Received: from unknown (HELO comodo.net) (212.159.50.31) by warrior with SMTP; 13 Sep 2000 16:36:45 -0000
Received: from VIPER.comodo.net ([192.168.0.4]) by comodo.net with SMTP (Mailtraq/1.1.4.1109) id CMD2785644D8 for [e-mail]; Wed, 13 Sep 2000 17:39:30 +0100
Message-Id: <4.3.2.7.2.20000913173651.00b54c00@192.168.0.1>
X-Sender: Tim@192.168.0.1
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Sep 2000 17:39:29 +0100
To: [e-mail]
From: Tim Fowle <[e-mail]>
Subject: CRLs and expired certificates
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Hops: 1

i may be missing the point a little here but am i right in thinking most 
companies only supply CRL's for certificates that are currently within 
their validity period.
If so is there any way to check if a certificate was valid when it was used 
to sign something a long time ago and that certificate has now expired, and 
does this make any sense or would this not prove anything?

thanks for the help

ttfn
Tim Fowle



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12992 for <[e-mail]>; Wed, 13 Sep 2000 09:19:13 -0700 (PDT)
Received: from tsg1 ([12.72.64.64]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913162054.TLAD6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 16:20:54 +0000
Message-ID: <01d901c01d9e$7d678b30$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1><v04220811b5e4216f0a23@[171.78.30.107]><006d01c01d1e$a8403b20$020aff0c@tsg1> <v04220803b5e548bbeeb9@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Wed, 13 Sep 2000 09:20:09 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D6_01C01D63.D004FED0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

This is a multi-part message in MIME format.

------=_NextPart_000_01D6_01C01D63.D004FED0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steven - group ----> Let me try again.

    1)    The issue is that many of our systems address time as though =
it were part of the control infrastructure and we ignore the need to =
provide proofing as to what the time data is and where it came from - =
Does that answer this comment?

    2)    We are building many protocols that provide a layered =
framework for building transaction services and processing. In fact that =
the X509 Digitally Signed Documents now automatically have legal =
consequence here in the States, in my mind opens a whole new realm of =
requirements for us to have to take into account.

Does this explain what I mean?

Todd
  ----- Original Message -----=20
  From: Stephen Kent=20
  To: todd glassey=20
  Cc: [e-mail]=20
  Sent: Wednesday, September 13, 2000 8:09 AM
  Subject: Re: The need for two grades of time data.


  Todd,


    Thanks for responding Steve, but again the real issue with this =
concept of evidentiary time is in treating the parametric time data as =
content rather than control process elements. Once you do that it gets =
to be obvious that you need a auth/certification stream and =
chain-of-custody model for that time data to meet these evidentiary =
needs.


    So I have to ask - "What is the problem with treating time and =
perhaps other parametric data like location data, as through it had the =
same risks with it that the Human or Entity Identity issues that spawned =
PKIX in the first place? because it does?"

    We seem to as a group have restricted our relating to time and other =
parametric evidentiary processes as though they were only part of the =
plumbing and it just aint so.

    Any of the data points that are use inside the decision support =
process protocols that we are building (OCSP, TSP, etc etc etc) are all =
tied to the requirement of some evidentiary anchor - Someone or =
something has to sign that top level cert, some key generator has to =
pump out that key pairing, and that data has been sanctified by PKIX to =
date as it rightly should, but the use of traditional Control Data =
points a parts of the larger evidentiary or decision support process =
warrants that that data have the same integrity as any other.


  I sometimes have trouble parsing your text; this is one of those =
times. There must be a clearer way to communicate what you're trying to =
state. Please try again.

  Steve=20

------=_NextPart_000_01D6_01C01D63.D004FED0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c8e0d8>
<DIV>Steven - group ----&gt; Let me try again.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; 1)&nbsp;&nbsp;&nbsp; The issue is that many of =
our=20
systems address time as though it were part of the control =
infrastructure and we=20
ignore the need to provide proofing as to what the time data is and =
where it=20
came from - Does that answer this comment?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; 2)&nbsp;&nbsp;&nbsp; We are building many =
protocols that=20
provide a layered framework for building transaction services and =
processing. In=20
fact that the X509 Digitally Signed Documents now automatically have =
legal=20
consequence here in the States, in my mind opens a whole new realm of=20
requirements for us to have to take into account.<BR></DIV>
<DIV><FONT face=3DArial size=3D2>Does this explain what I =
mean?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]" title=[e-mail]>Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[e-mail]"=20
  title=[e-mail]>todd glassey</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, September 13, =
2000 8:09=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: The need for two =
grades of=20
  time data.</DIV>
  <DIV><BR></DIV>Todd,<BR><BR>
  <BLOCKQUOTE>
    <DIV><?fontfamily><?param Arial>Thanks for responding Steve, but =
again the=20
    real issue with this concept of evidentiary time is in treating the=20
    parametric time data as content rather than control process =
elements. Once=20
    you do that it gets to be obvious that you need a auth/certification =
stream=20
    and chain-of-custody model for that time data to meet these =
evidentiary=20
    needs.</DIV>
    <DIV><BR><BR>So I have to ask - "What is the problem with treating =
time and=20
    perhaps other parametric data like location data, as through it had =
the same=20
    risks with it that the Human or Entity Identity issues that spawned =
PKIX in=20
    the first place? because it does?"<BR><BR>We seem to as a group have =

    restricted our relating to time and other parametric evidentiary =
processes=20
    as though they were only part of the plumbing and it just aint=20
    so.<BR><BR>Any of the data points that are use inside the decision =
support=20
    process protocols that we are building (OCSP, TSP, etc etc etc) are =
all tied=20
    to the requirement of some evidentiary anchor - Someone or something =
has to=20
    sign that top level cert, some key generator has to pump out that =
key=20
    pairing, and that data has been sanctified by PKIX to date as it =
rightly=20
    should, but the use of traditional Control Data points a parts of =
the larger=20
    evidentiary or decision support process warrants that that data have =
the=20
    same integrity as any =
other.<BR></DIV><?/fontfamily></BLOCKQUOTE><?fontfamily><?param =
Arial><BR><?/fontfamily>I=20
  sometimes have trouble parsing your text; this is one of those times. =
There=20
  must be a clearer way to communicate what you're trying to state. =
Please try=20
  again.<BR><BR>Steve </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01D6_01C01D63.D004FED0--



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11639 for <[e-mail]>; Wed, 13 Sep 2000 09:01:32 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 13 Sep 2000 10:02:54 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Wed, 13 Sep 2000 10:02:45 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: The need for two grades of time data.
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 ns.secondary.com id JAA11640

I believe that what Todd is trying to say is that the question isn't,
"What time is it?" but rather "What time is it, and who says so, and
why should anyone believe them?"

If I have correctly understood his position, I think he has an 
excellent point.

I think I have told this story before, but when I was a kid in 
Cheyenne, there was a jewelry store that had a very fancy 
nautical chronometer displayed in their window, and many 
people in town used it to set their watches.

One day, the jeweler observed an executive of the Union Pacific 
Railroad setting his watch, and they got to talking about time.  The 
executive said rather proudly that he set his watch according to the 
jeweler's chronometer every day, and then adjusted their railroad 
clock accordingly, including the clock that blew the noon whistle.
The jeweler blanched, and said, "But I set my chronometer according 
to your whistle!"

Isn't necessary to get  involved in all of the intricacies of various
legal system, and what constitutes acceptable evidence, to realize that
like all weights and measures, the standards must eventually be
shown to be traceable back to an agreed-upon source.

If absolute time is important, then the traceability of that time back to 
an agreed-upon reference is important.  One way to beat a speeding
ticket is to challenge the calibration of the radar gun and/or the 
speedometer of the cop car, and the same principle will apply here.

(Whether absolute time ought to be all that important is a different matter,
but if it is, the same chain of custody issues should apply as apply to
a certificate chain.)

Bob



>>> Stephen Kent <[e-mail]> 09/13/00 09:09AM >>>
Todd,

>Thanks for responding Steve, but again the real issue with this 
>concept of evidentiary time is in treating the parametric time data 
>as content rather than control process elements. Once you do that it 
>gets to be obvious that you need a auth/certification stream and 
>chain-of-custody model for that time data to meet these evidentiary 
>needs.
>
>So I have to ask - "What is the problem with treating time and 
>perhaps other parametric data like location data, as through it had 
>the same risks with it that the Human or Entity Identity issues that 
>spawned PKIX in the first place? because it does?"
>
>We seem to as a group have restricted our relating to time and other 
>parametric evidentiary processes as though they were only part of 
>the plumbing and it just aint so.
>
>Any of the data points that are use inside the decision support 
>process protocols that we are building (OCSP, TSP, etc etc etc) are 
>all tied to the requirement of some evidentiary anchor - Someone or 
>something has to sign that top level cert, some key generator has to 
>pump out that key pairing, and that data has been sanctified by PKIX 
>to date as it rightly should, but the use of traditional Control 
>Data points a parts of the larger evidentiary or decision support 
>process warrants that that data have the same integrity as any other.

I sometimes have trouble parsing your text; this is one of those 
times. There must be a clearer way to communicate what you're trying 
to state. Please try again.

Steve



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11183 for <[e-mail]>; Wed, 13 Sep 2000 08:59:43 -0700 (PDT)
Received: from tsg1 ([12.72.64.64]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913160124.TDVD6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 16:01:24 +0000
Message-ID: <01c501c01d9b$c3eefe10$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "Rich Salz" <[e-mail]>, <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <[e-mail]> <009301c01d21$be4d5800$020aff0c@tsg1> <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Wed, 13 Sep 2000 09:00:27 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Ben, I have to respond on two subjects here -
Nobody is asking the IETF to be a COP or to do squat about actually
enforcing laws; but for PKIX in particular to continue to develop protocols
that do not take into account that there may be some legal precedent or
issue with the use of its Protocols, then PKIX is negligent, IMHO and
unfortunately so would its members and management be in my opinion if they
did nothing about this.

Bluntly - If you knowingly say "that is not important to me as I only design
the process model", then when that process model gets blown out  of the
water by an auditor, we collectively look pretty stupid.

What is PKIX's problem with realizing that it has a responsibility to the
community it serves, and that has nothing to do with its members? The
reality is that the pace in the PKI world is now starting to pick up to the
point where things are going to get mooshed, and bluntly we can save
ourselves a lot of effort and worry about end use applicability and
requirements by just adding the Applicability Documents to our efforts. This
is part of enabling the people that use our work to make determinations on
its applicability - unless that is not what the IETF or PKIX as a collective
wants...

As to the need for two grades of time. One is simply plumbing and the other
is the water that flows through the pipes. Much care is already given to
authenticate digital entities and any auditor will tell you that if that
much care is placed on authenticating abstract data like "Who" then the
"When" deserves the same or better.

---- Original Message -----
From: "Ben Laurie" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Rich Salz" <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 13, 2000 3:22 AM
Subject: Re: The need for two grades of time data.


> todd glassey wrote:
> >
> > Rich - I'm sorry but the IETF is exactly the place for it.
> >
> > ----- Original Message -----
> > From: "Rich Salz" <[e-mail]>
> > To: "todd glassey" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Tuesday, September 12, 2000 11:35 AM
> > Subject: Re: The need for two grades of time data.
> >
> > > >      What I want to do is to start a process of formally defining
what
> > an
> > > > evidentiary grade time source is and what it must conform to.
> > >
> > > The IETF is not the place for this.  Start with ABA, or a similar
> > > legal-focused entity.
> > >
> >
> > SNIP
> >
> > > >
> > > > The term "evidence" does pertain to proof, but "proof" has different
> > > > meanings in different contexts. Civil trial evidence rules vary from
> > > > one jurisdiction to another. PKIX is NOT going to wait for these
> > > > rules to become uniform, or cater to different sets of rules. This
is
> > > > new legal territory and until there are ample case law precedents
> > > > nobody will really know what will be required.  We can get lots of
> > > > opinions from lawyers, and technologists who think they are lawyers,
> > > > but, none of these opinions are authoritative. So, PKIX will
continue
> > > > to focus on the technical aspects of PKI and do the best we can to
> > > > provide a solid technical basis for whatever the legal community may
> > > > choose to adopt.
> >
> > Actually here in the states this problem has already been answered by
the
> > enactment of the Digital Signature Act and the Federal Rules of Evidence
and
> > its a done deal already. Not something that Americans have a choice in
> > anymore, that is  without repealing or amending the currently in-force
Law.
> > So there is law defining what X.509 Digital Signatures  and our PKIX
systems
> > do here in the US... and the rest of the world is not far behind.
> >
> > What I personally think this means to PKIX is that it whether "it like
it or
> > not, it needs to look at legal things or it will eventuaually get its
hand
> > whacked so bad that someone like congress will step in an nationalize
it.",
> > and I think this neither funny or to far off in the inconceivable future
> > either. The systems and processes that PKIX architects will carry our
money
> > and commerce and that means regulation like you never saw before. The
last
> > 50 years have just been getting ready for it. Just wait and see.
> >
> > The reality is that now that there is legal basis in the technologies we
> > designed, they answer to a higher authority than us or the IESG and that
is
> > that. If PKIX doesn't like this unique twist of fate, then maybe
shutting it
> > down is appropriate.
> >
> > In closing the point is that we as PKIX have an opportunity to embrace a
set
> > of operations and audit guidelines that will enable more of what we
produce
> > to see the end-market.
> >
> > How grand is our collective ego to not want this?
>
> The IETF has already decided that enforcing various local laws is not
> within its remit (see the Raven WG) - that's not to say that PKIX should
> not attempt to make itself useful within likely international legal
> frameworks, but only in the sense of being capable of supporting them,
> insofar as is possible and in keeping with the open and international
> nature of the protocols, not by enforcing them as protocol requirements.
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> Coming to ApacheCon Europe 2000? http://apachecon.com/



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA08869 for <[e-mail]>; Wed, 13 Sep 2000 08:39:29 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 13 Sep 2000 09:40:41 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Wed, 13 Sep 2000 09:40:41 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: New hash algorithms
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 ns.secondary.com id IAA08870

 "Jeff Davis" <[e-mail]> 09/13/00 05:06AM >>>
>Bob,

>I am new to this but my understanding of Hash values were that they
would be dramatically different if a single bit was to change inside the
data that was being hashed.  Therefore, finding a duplicate hash value
would not be of any use as the data that produced it would be
significantly different in content and context to the original.  Thus,
if an attacker wanted to change a little data within a very sensitive
"transaction" then to create a hash value of that changed data, it would
be impossible to come up with the same hash value as the original.  The
digital signature would then expose the change.

>Can you explain to me, in brief if possible, what an attacker would gain
from finding a duplicate hash inside 2^64 or 80?.  Help understanding
this would be appreciated as I feel I am missing something.

>Cheers

>Jeff Davis


Hi, Jeff,

You are correct -- any decent secure hash function or message 
digest will have the property that if so much as a single bit changes, 
moves, or is added or deleted to the original message, the entire hash 
result changes, so that the probability of any particular bit of the result
is the same is 50%.  Moreover, it is computationally infeasible to 
_derive_ (from the hash value), either the original 
message, or another message that would be different from the 
original but would have the same hash value.

And of course, if you are trying to find or create a new message which
produces the same hash result as a given (fixed) message, you are
going to have to do an exhaustive search over the entire message 
space. With a 160-bit hash such as SHA-1, you would be facing 
a 2^159 exhaustive search -- certainly infeasible.

However, there is another attack that is subtle but dangerous,
and newcomers to the field may not have encountered it.

Early on in the development of public key technology, Rabin 
suggested the use of a message digest or hash function 
to simplify the calculation of a digital signature.

But in a famous article entitled "How to Swindle Rabin,"
which appeared in Cryptologia (v.3, n.3, Jul 1979, p 187-190),
Gideon Yuval proposed the following attack:

1.  Alice prepares two versions of a contract: one is favorable to 
Bob, and the other to Alice.

2.  Alice makes a series of subtle changes to both documents --
changes that would not be noticeable by Bob. For example, 
one or more spaces might be inserted at the end of a line, or 
in some systems a space-backspace-space sequence might be 
inserted. (Word processing documents with proportional spacing 
introduce all sorts of opportunities to diddle the spacing between 
characters or words, change font size slightly, etc.) By doing making
these indiscernible modifications on only 64 lines, 2^64 different 
versions of each document can be created, and the hash calculated.

3.  After producing all of the variations of both documents, Alice
sorts or otherwise compares the message number and the hash value, 
looking for two message variants that hash to the same value.
According to the Birthday Problem in statistics, Alice has 
approximately a 50% chance of finding at least one duplicate 
after sqrt(N)/2 tries, where N is the number of possibilities.
For a 128-bit hash value, therefore, the 50% probability point is 
approximately 2^63 samples, and the chance of success rises 
very sharply after that point.

4.  Having found two matching hash values, she sends the 
corresponding variant of the document that is favorable to Bob 
off to him to be signed, which he does to indicate his consent.

5.  At some time in the future, Alice produces the version of the 
document that is favorable to her, along with Bob's digital signature
containing an identical hash, and somehow convinces the judge 
that her version is the legitimate one.  

(A moral to this story is that Bob should make some kind of a 
cosmetic change to any document he signs, and he should always 
keep a copy of that document.)

This same attack would conceivable apply to ANY kind of a digital 
signature which is computed over a message digest or hash, including
of course X.509 certificates.

At present, it appears that a 1024-bit RSA signature would be about 
as hard to factor as an 80-bit symmetric key would be to break via a 
exhaustive search attack.  

Therefore, neglecting the cost and difficulty of storing and searching
the required amount of data, this suggests that a hash algorithm that is 
used in combination with a 1024-bit RSA key (or other algorithm of 
equivalent strength) should be DOUBLE the size of the equivalent
symmetric key strength, or about 160 bits.

This suggests that SHA-1 is about right for a 1024-bit RSA signature,
but would be too short for a 2048 bit key, much less anything longer.
it also suggests that a 128-bit MD5 hash is already too short for safety.

So it is probably time to start thinking about longer hashes, just as it it time
to start thinking about longer than 1024-bit signatures.

Bob


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06495 for <[e-mail]>; Wed, 13 Sep 2000 08:08:52 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA12784; Wed, 13 Sep 2000 11:10:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b5e548bbeeb9@[171.78.30.107]>
In-Reply-To: <006d01c01d1e$a8403b20$020aff0c@tsg1>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <006d01c01d1e$a8403b20$020aff0c@tsg1>
Date: Wed, 13 Sep 2000 11:09:07 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1243264531==_ma============"

--============_-1243264531==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Thanks for responding Steve, but again the real issue with this 
>concept of evidentiary time is in treating the parametric time data 
>as content rather than control process elements. Once you do that it 
>gets to be obvious that you need a auth/certification stream and 
>chain-of-custody model for that time data to meet these evidentiary 
>needs.
>
>So I have to ask - "What is the problem with treating time and 
>perhaps other parametric data like location data, as through it had 
>the same risks with it that the Human or Entity Identity issues that 
>spawned PKIX in the first place? because it does?"
>
>We seem to as a group have restricted our relating to time and other 
>parametric evidentiary processes as though they were only part of 
>the plumbing and it just aint so.
>
>Any of the data points that are use inside the decision support 
>process protocols that we are building (OCSP, TSP, etc etc etc) are 
>all tied to the requirement of some evidentiary anchor - Someone or 
>something has to sign that top level cert, some key generator has to 
>pump out that key pairing, and that data has been sanctified by PKIX 
>to date as it rightly should, but the use of traditional Control 
>Data points a parts of the larger evidentiary or decision support 
>process warrants that that data have the same integrity as any other.

I sometimes have trouble parsing your text; this is one of those 
times. There must be a clearer way to communicate what you're trying 
to state. Please try again.

Steve

--============_-1243264531==_ma============
Content-Type: text/enriched; charset="us-ascii"

Todd,


<excerpt><fontfamily><param>Arial</param>Thanks for responding Steve,
but again the real issue with this concept of evidentiary time is in
treating the parametric time data as content rather than control
process elements. Once you do that it gets to be obvious that you need
a auth/certification stream and chain-of-custody model for that time
data to meet these evidentiary needs.

 

So I have to ask - "What is the problem with treating time and perhaps
other parametric data like location data, as through it had the same
risks with it that the Human or Entity Identity issues that spawned
PKIX in the first place? because it does?"

 

We seem to as a group have restricted our relating to time and other
parametric evidentiary processes as though they were only part of the
plumbing and it just aint so.

 

Any of the data points that are use inside the decision support process
protocols that we are building (OCSP, TSP, etc etc etc) are all tied to
the requirement of some evidentiary anchor - Someone or something has
to sign that top level cert, some key generator has to pump out that
key pairing, and that data has been sanctified by PKIX to date as it
rightly should, but the use of traditional Control Data points a parts
of the larger evidentiary or decision support process warrants that
that data have the same integrity as any other.

</fontfamily></excerpt><fontfamily><param>Arial</param>

</fontfamily>I sometimes have trouble parsing your text; this is one of
those times. There must be a clearer way to communicate what you're
trying to state. Please try again.


Steve

--============_-1243264531==_ma============--


Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA05171 for <[e-mail]>; Wed, 13 Sep 2000 07:36:25 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 13 Sep 2000 08:37:58 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Wed, 13 Sep 2000 08:37:54 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: New hash algorithms
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_2971A256.0D6C01A7"

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_2971A256.0D6C01A7
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> "Rob B Branch" <[e-mail]> 09/12/00 02:35PM >>>
>In reference to the below what does this new algorithm consist of?
Could you forward me the message that you ref. from Bill Burr?
Thanks in Advance...RobBranch

My apologies to the list.  I thought Bill had posted his comments to the
PKIX list -- actually, it took me a while to find it, as it was posted on =
a
list for the American Bar Association's Information Security committee. I
hope he won't mind me reposting it here.

His comment was made in the context of answering an attorney's question=20
about the feasibility of breaking asymmetric keys vs. symmetric keys.

I believe that his intent was to strive towards a balanced approach to
cryptography, so that the strength of symmetric keys, asymmetric keys, and =
the=20
message digest used within signature algorithms would all be approximately
equal.

Bob



--=_2971A256.0D6C01A7
Content-Type: message/rfc822

Received: from prv1-mx.provo.novell.com
	by prv-mail25.provo.novell.com; Wed, 30 Aug 2000 15:18:25 -0600
Received: from mail.abanet.org
	([209.97.182.23])
	by prv1-mx.provo.novell.com; Wed, 30 Aug 2000 15:14:03 -0600
Received: from mail (209.97.182.23:2868) by mail.abanet.org (LSMTP for Windows NT v1.1b) with SMTP id <[e-mail]>; Wed, 30 Aug 2000 16:09:10 -0500
Received: from MAIL.ABANET.ORG by MAIL.ABANET.ORG (LISTSERV-TCP/IP release
          1.8d) with spool id 690143 for [e-mail]; Wed, 30 Aug
          2000 16:09:07 -0500
Received: from email.nist.gov by mail.abanet.org (LSMTP for Windows NT v1.1b)
          with SMTP id <[e-mail]>; Wed, 30 Aug 2000 16:09:06
          -0500
Received: from thunderbolt (thunderbolt.ncsl.nist.gov [129.6.54.130]) by
          email.nist.gov (8.9.3/8.9.3) with SMTP id RAA17916 for
          <[e-mail]>; Wed, 30 Aug 2000 17:16:39 -0400 (EDT)
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
References: <8D394232A687D211A0DD0008C7A4DF5807893487@JUS00AEX0310>
            <001701c0129c$10518530$6b0ec5a9@lawonline>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Approved-By:  Bill Burr <[e-mail]>
Message-ID:  <[e-mail]>
Date:         Wed, 30 Aug 2000 17:13:39 -0400
Reply-To:     Bill Burr <[e-mail]>
Sender:       Information Security Committee <[e-mail]>
From:         Bill Burr <[e-mail]>
Subject:      Re: breaking PKI keys
To:           [e-mail]
In-Reply-To:  <[e-mail]>

At 03:10 PM 8/30/00 -0400, Charles Merrill wrote:

>To analyze John Gregory's question, what does the cryptanalyst have to
>work with in order to derive the recipient's private decryption key from
>the corresponding public key, or the sender's private signing key from
>the corresponding public key?
>
>In the encryption case, the cryptanalyst has the symmetric ciphertext of
>the message, and the asymmetric ciphertext of the secret key.  If he can
>crack the asymmetric ciphertext to discover the plaintext of the secret
>key, then he can obtain the plaintext of that message. That will not
>reveal the asymmetric private key, but will provide both ciphertext and
>plaintext of one entire message for a known-plaintext attack.

Usually the analyst is going to attack the weak link.  If the symmetric key
algorithm is 3DES, with a 112-bit key, and the asymmetric key algorithm is
1024-bit RSA, every indication is that it's easier to factor a 1024-bit
number than crack a 112-bit 3DES key.  Moreover cracking the 112-bit 3DES
key gives you one message, while the RSA key gives you lots of message.  Of
course, as far as is publicly known, neither 1024-bit RSA nor 112-bit 3DES
has ever been successfully attacked, to date.

If the symmetric key algorithm were 56-bit DES, or old 40-bit "exportable"
symmetric key encryption, then the symmetric key encryption would probably
be the weak link.

There are chosen plaintext attacks against DES with nominal workfactors
less than key exhaustion, but, as a practical matter it's probably easier
in almost every case to attack DES by key exhaustion.


>
>In the signature case, the cryptanalysis has: the plaintext of the
>message, the plaintext of its hash result (by himself running the
>plaintext of the message through the publicly-known hash algorithm), and
>the asymmetric ciphertext of the hash result of the message.  The hash
>result is typically the (almost unique) representation of a much longer
>message.  He will have both plaintext and ciphertext of the hash result
>without difficulty, but no asymmetric ciphertext of the longer message.

Factoring attacks on RSA public keys are basically the same whether they
are encryption keys or signature keys.

There is another attack on a signature, by finding two message texts that
hash to the same value.  It's not necessarily easy to figure out how to
conduct such an attack in a practical way, but the average workfactor to
find two messages with the same 128-bit MD5 hash, is only 2^63, which is
verging on a practical thing now, and for a 160-bit SHA-1 hash it's 2^79,
which is considerably harder.  Still, if we're talking about using 112-bit
3DES and 128, 192 and 256-bit AES encryption, the 160-bit hash now becomes
something of a weak point.  If we're encrypting a 160-bit hash in a with
2048 bit RSA for a signature, it's probably not very much stronger than
that same 160-bit hash encrypted with a 1024 bit RSA key.

At NIST we're planning to propose new, stronger hashes of 256, 384 and 512
bits (to be called SHA-256, SHA-384 and SHA-512) that will be roughly as
strong as 128, 192 and 256 bit AES respectively.  These would be used with
RSA key sizes of 2048 bits or more to make stronger signatures.

>On balance, a known-plaintext attack to discover an asymmetric private
>key used EITHER for signing or for decryption strikes me as not as
>fruitful than working with the public key alone.  That leaves brute
>force factoring of the product of two huge prime numbers (possibly
>through vastly faster computation methods many years in the future),
>possible mathematic shortcuts still to be discovered, chip anomalies or
>chip peeling, exploitation of known or guessed mathematical bias or
>other defects in the key generation process, and the like.
>
>Chas (a determined studier of Schneier's "Applied Cryptogrpher", but
>otherwise far beyond my depth)
>Attachment Converted: "c:\eudora\attach\cmerrill1.vcf"
>
Regards,

Bill Burr

To unsubscribe send the following in the body of a message to
[e-mail]  - unsubscribe st-isc

--=_2971A256.0D6C01A7--


Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04426 for <[e-mail]>; Wed, 13 Sep 2000 07:15:50 -0700 (PDT)
Received: from 216-164-132-105.s359.tnt2.lnhva.md.dialup.rcn.com ([216.164.132.105] helo=rankney) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13ZDMN-00057R-00; Wed, 13 Sep 2000 10:18:00 -0400
Message-ID: <003f01c01d8d$97c46a40$6984a4d8@rankney>
From: "Rich Ankney" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: The "race" towards SHA-256, SHA-512
Date: Wed, 13 Sep 2000 10:19:07 -0400
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.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

It's my understanding these will be used with the AES, i.e. SHA-256
is the "same" strength as a 128-bit AES key, SHA-512 is the same
strength as a 256-bit key, etc.  (And SHA-1 was the same strength as an
80-bit Skipjack key.)

Regards,
Rich

-----Original Message-----
From: Denis Pinkas <[e-mail]>
To: Rich Ankney <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Wednesday, September 13, 2000 7:49 AM
Subject: The "race" towards SHA-256, SHA-512


>Rich,
>
>> Bob,
>>
>> The current idea is to have OIDs for SHA-256, SHA-512, and SHA-384
>> (truncated SHA-512).
>
>A naive question here. I am a little bit puzzled. The reason for
>having 128 bits for a minimum hash comes from the Birthday Paradox.
>160 bits is already overkilling. Are there any new discoveries along
>the Birthday Paradox which indicate that 128 bits hashes are going
>to be insecure and thus that we *need* 256 bits hashes and even more
>?
>
>For fitting the size of a signature value, various padding functions
>exist.
>
>So could you (or someone else) explain the rational for the "race"
>towards SHA-256 and even SHA-512 ?
>
>Denis
>
>
>> At least in X9; your comments (and anone else's)
>> are appreciated.  I know nothing else about these algorithms except the
>> following: SHA-x (with x >= 256) is not backward with SHA-1, i.e. you
>> can't truncate a SHA-256 or whatever to SHA-160-bits.  So they are
>> not doing the obvious (SHA-Y with Y > X in SHA-X being some sort of
>> iteration of the same function with different IVs).  Of course that's
>> obviously
>> only 160 bits strong, so never mind.
>>
>> This is an area where you have lots of expertsise; I'd be interested in
your
>> ideas (remembering the real version will be distributed to X9 in the next
>> few weeks, and I'll do my best to leak it to PKIX ASAP).
>>
>> Best,
>> Rich
>>
>> -----Original Message-----
>> From: Bob Jueneman <[e-mail]>
>> To: [e-mail] <[e-mail]>; [e-mail]
>> <[e-mail]>; [e-mail]
>> <[e-mail]>
>> Date: Monday, September 11, 2000 6:31 PM
>> Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
>>
>> >In this regard, I was interested to hear on the Federal PKI TWG list
that
>> NIST
>> >is considering releasing a SHA-256 and SHA-512 hash algorithm.
>> >
>> >No new algorithms will be forthcoming -- the only question is whether to
>> >bundle them with the conventional signature OID, or to separate them
out.
>> >
>> >Bundling them makes them somewhat harder to change, but on the other
hand,
>> >allowing complete freedom to choose the signing algorithm independently
>> tends to
>> >raise issue of N-squared combinations that have to be tested.
>> >
>> >Some combinations might not even make technical sense -- for example
>> 200-bit
>> >elliptic curve DSA with SHA-512, since the hash function wouldn't fit
>> within the
>> >signature result.
>> >
>> >On balance, and noting the generally poor track record we have in
limiting
>> >combinations of things to stable profiles, I am inclined to continue the
>> practice of
>> >specifying the signature algorithm and the hash algorithm as one joint
>> specification.
>> >
>> >Bob
>> >
>> >>>> "todd glassey" <[e-mail]> 09/11/00 01:06PM >>>
>> >Hi all -
>> >
>> >----- Original Message -----
>> >From: "J Adrian Pickering" <[e-mail]>
>> >To: <[e-mail]>
>> >Sent: Wednesday, September 06, 2000 7:57 AM
>> >Subject: Re: CMC issues, TSP hashes
>> >
>> >
>> >> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>> >>
>> >> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
>> >> >standard open for other hash algorithms. Are there any plans to
change
>> >> >this?
>> >>
>> >> This is a problem shared with the TSP Draft also.
>> >>
>> >> (see posting -
>> >> Date: Sat, 02 Sep 2000 17:37:43 +0100
>> >> From: J Adrian Pickering <[e-mail]>
>> >> Subject: TSP Draft - hash enforcement &c
>> >> which is rather lost amongst the OCSP debate!)
>> >>
>> >> Please can something be done about this for everyone's benefit? My
>> >> suggestion is to introduce a PKIX globally available OID
>> >> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier.
This
>> >> will enable other hashes to be used where required/wanted. The
>> overloading
>> >> of the AlgorithmIdentifier allows for a parameter which I'm not sure
is
>> >any
>> >> use in the hash arena?
>> >
>> >Actually Adrian  your right - but I think we need a little more than
this.
>> >We need an official PKIX OID Tree and it needs to be available.
>> >
>> >For each complex data structure or process that can be uniquely
identified
>> >and that would want to be identified, PKIX needs an OID entry in some
PKIX
>> >master OID Table. Hash's, techniques, and maybe even the IOTP
Transaction
>> >types or something like that as well.
>> >
>> >>
>> >> Russ Housley appears to agree: "The selected one-way hash function
must
>> be
>> >> uniquely identified by an OID."
>> >>
>> >> I'd still rather have the TSA autonomously stamp an octet string and
>> leave
>> >> the client to decide what it all means.
>> >
>> >We are confusing the term "Client" here for the term "USER OF"... and
this
>> >is an important concept in understanding what we are really talking
about.
>> >
>> >The key issue is whether the time stamp is used to control some other
>> >external process, almost analogous to dropping a coin into a vending
>> >machine,
>> >or whether it is standing as evidentiary testimony to some event. As it
>> >happens the Coin does both, but generally the mindset about how the TSP
has
>> >been thought about is form using time as a control parameter rather than
an
>> >evidentiary one. By the way - We generally as a group seem to assume
>> >automatically between 'using data elements for control' rather than
'for
>> >content'.
>> >
>> >In one case they are used to control the infrastructure or policy
>> >like a signal, and on the other they are used to stand audit. The uses
of
>> >the same parametric data elements here are very different and have
>> different
>> >needs to support their respective end use models.
>> >
>> >> What business is it of the TSA to
>> >> know what it is stamping (semantically or syntactically)?
>> >
>> >Depends on what the purpose of the TSA is. If there is a conveyance in a
>> >legal sense of Agency, then the TSA may have legally binding reasons for
>> >being able to identify the type of content it is stamping. Maybe to the
>> >granularity of needing to parse the file first to determine its data
type.
>> >
>> >.. and this leads us to the fact that a HASH in and of itself as a
>> >timestamping record is very difficult to use from an end user model.
What
>> >the TST should be is a framework or harness itself and internally it
should
>> >represent a number of events interchangeably. There would need to be
>> >different grades of Tokens with varying levels of overhead for their
>> >management, and the approriate BCP to match.
>> >
>> >But realize that in no uncertain terms what we are sitting on is  the
>> >designing of the Global Mint here.
>> >
>> >"The real end user goal is a simple bolt-on system that allows end users
>> to,
>> >with the transaction infrastructure they have today,  add
non-repudiation
>> >at a commercial level to their process, and  at a scaleable and
reasonable
>> >overhead."
>> >
>> >Simple to say, not so simple to do as there are so many different
>> >transaction
>> >processing systems in the world today, but the common elements in all of
>> >them is that they have some DB system that they are layered on and an OS
>> >under that of some sort.
>> >
>> >With that being the key the DB that is, doesn't the idea of a common
binary
>> >data structure that is a timestamp token appeal to you (represented in
the
>> >cyber world as ASN.1 if you want) . We can build an TST Binary to XML
>> >presentation system and absorb or bridge the IOTP/XML Receipt efforts at
>> >some level into the PKIX Timestamping systems  and deliver evidentiary
>> grade
>> >standards for representing events in time and space. YOW - look at the
>> >potential
>> >there!!!.
>> >
>> >These tokens and their respective API's will be able to specify its
level
>> of
>> >trust, the event it marks and the data components that make up that
event,
>> >and the rules of processing the token. If a lighter token is necessary
>> >portions of the system can be replaced by OIDS on as "as many as
possible"
>> >basis based in the OID tree idea (see above). More risk mitigated
>> >transactions may require self authenticating tokens as well and we
should
>> >provide for these at the high end of the API.
>> >
>> >Poof - Instant transaction systems. I think that this is what DigiCash
and
>> >most all of the other token based transactor companies tried to do but
they
>> >were too far ahead of the curve to get real traction - and as scary as
it
>> >sounds, PKIX is in the perfect position to make this fly now.
>> >
>> >BTW, in and of itself is reason for not advancing the TPS Draft.
>> >
>> >>
>> >> Adrian Pickering/
>> >> Electronics and Computer Science
>> >> University of Southampton
>> >> UK
>> >>
>> >>
>> >
>> >



Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA03455 for <[e-mail]>; Wed, 13 Sep 2000 06:38:43 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id OAA14783; Wed, 13 Sep 2000 14:45:03 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 14:39:28 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Rich Ankney <[e-mail]>, [e-mail]
Subject: Re: The "race" towards SHA-256, SHA-512
References: <002301c01c4f$cd0317e0$a2c43ad0@rankney> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
> Rich,
> 
> > Bob,
> >
> > The current idea is to have OIDs for SHA-256, SHA-512, and SHA-384
> > (truncated SHA-512).
> 
> A naive question here. I am a little bit puzzled. The reason for
> having 128 bits for a minimum hash comes from the Birthday Paradox.
> 160 bits is already overkilling. Are there any new discoveries along
> the Birthday Paradox which indicate that 128 bits hashes are going
> to be insecure and thus that we *need* 256 bits hashes and even more
> ?
> 
> For fitting the size of a signature value, various padding functions
> exist.
> 
> So could you (or someone else) explain the rational for the "race"
> towards SHA-256 and even SHA-512 ?

The obvious need for SHA-256 is to key AES from (for example)
passphrases.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01200 for <[e-mail]>; Wed, 13 Sep 2000 04:46:58 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA32808; Wed, 13 Sep 2000 13:53:55 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA14762; Wed, 13 Sep 2000 13:48:34 +0200
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 13:48:35 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Rich Ankney <[e-mail]>
CC: [e-mail]
Subject: The "race" towards SHA-256, SHA-512
References: <002301c01c4f$cd0317e0$a2c43ad0@rankney>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rich,

> Bob,
> 
> The current idea is to have OIDs for SHA-256, SHA-512, and SHA-384
> (truncated SHA-512).  

A naive question here. I am a little bit puzzled. The reason for
having 128 bits for a minimum hash comes from the Birthday Paradox.
160 bits is already overkilling. Are there any new discoveries along
the Birthday Paradox which indicate that 128 bits hashes are going
to be insecure and thus that we *need* 256 bits hashes and even more
?

For fitting the size of a signature value, various padding functions
exist.

So could you (or someone else) explain the rational for the "race"
towards SHA-256 and even SHA-512 ?

Denis 


> At least in X9; your comments (and anone else's)
> are appreciated.  I know nothing else about these algorithms except the
> following: SHA-x (with x >= 256) is not backward with SHA-1, i.e. you
> can't truncate a SHA-256 or whatever to SHA-160-bits.  So they are
> not doing the obvious (SHA-Y with Y > X in SHA-X being some sort of
> iteration of the same function with different IVs).  Of course that's
> obviously
> only 160 bits strong, so never mind.
> 
> This is an area where you have lots of expertsise; I'd be interested in your
> ideas (remembering the real version will be distributed to X9 in the next
> few weeks, and I'll do my best to leak it to PKIX ASAP).
> 
> Best,
> Rich
> 
> -----Original Message-----
> From: Bob Jueneman <[e-mail]>
> To: [e-mail] <[e-mail]>; [e-mail]
> <[e-mail]>; [e-mail]
> <[e-mail]>
> Date: Monday, September 11, 2000 6:31 PM
> Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
> 
> >In this regard, I was interested to hear on the Federal PKI TWG list that
> NIST
> >is considering releasing a SHA-256 and SHA-512 hash algorithm.
> >
> >No new algorithms will be forthcoming -- the only question is whether to
> >bundle them with the conventional signature OID, or to separate them out.
> >
> >Bundling them makes them somewhat harder to change, but on the other hand,
> >allowing complete freedom to choose the signing algorithm independently
> tends to
> >raise issue of N-squared combinations that have to be tested.
> >
> >Some combinations might not even make technical sense -- for example
> 200-bit
> >elliptic curve DSA with SHA-512, since the hash function wouldn't fit
> within the
> >signature result.
> >
> >On balance, and noting the generally poor track record we have in limiting
> >combinations of things to stable profiles, I am inclined to continue the
> practice of
> >specifying the signature algorithm and the hash algorithm as one joint
> specification.
> >
> >Bob
> >
> >>>> "todd glassey" <[e-mail]> 09/11/00 01:06PM >>>
> >Hi all -
> >
> >----- Original Message -----
> >From: "J Adrian Pickering" <[e-mail]>
> >To: <[e-mail]>
> >Sent: Wednesday, September 06, 2000 7:57 AM
> >Subject: Re: CMC issues, TSP hashes
> >
> >
> >> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
> >>
> >> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
> >> >standard open for other hash algorithms. Are there any plans to change
> >> >this?
> >>
> >> This is a problem shared with the TSP Draft also.
> >>
> >> (see posting -
> >> Date: Sat, 02 Sep 2000 17:37:43 +0100
> >> From: J Adrian Pickering <[e-mail]>
> >> Subject: TSP Draft - hash enforcement &c
> >> which is rather lost amongst the OCSP debate!)
> >>
> >> Please can something be done about this for everyone's benefit? My
> >> suggestion is to introduce a PKIX globally available OID
> >> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
> >> will enable other hashes to be used where required/wanted. The
> overloading
> >> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
> >any
> >> use in the hash arena?
> >
> >Actually Adrian  your right - but I think we need a little more than this.
> >We need an official PKIX OID Tree and it needs to be available.
> >
> >For each complex data structure or process that can be uniquely identified
> >and that would want to be identified, PKIX needs an OID entry in some PKIX
> >master OID Table. Hash's, techniques, and maybe even the IOTP Transaction
> >types or something like that as well.
> >
> >>
> >> Russ Housley appears to agree: "The selected one-way hash function must
> be
> >> uniquely identified by an OID."
> >>
> >> I'd still rather have the TSA autonomously stamp an octet string and
> leave
> >> the client to decide what it all means.
> >
> >We are confusing the term "Client" here for the term "USER OF"... and this
> >is an important concept in understanding what we are really talking about.
> >
> >The key issue is whether the time stamp is used to control some other
> >external process, almost analogous to dropping a coin into a vending
> >machine,
> >or whether it is standing as evidentiary testimony to some event. As it
> >happens the Coin does both, but generally the mindset about how the TSP has
> >been thought about is form using time as a control parameter rather than an
> >evidentiary one. By the way - We generally as a group seem to assume
> >automatically between 'using data elements for control' rather than  'for
> >content'.
> >
> >In one case they are used to control the infrastructure or policy
> >like a signal, and on the other they are used to stand audit. The uses of
> >the same parametric data elements here are very different and have
> different
> >needs to support their respective end use models.
> >
> >> What business is it of the TSA to
> >> know what it is stamping (semantically or syntactically)?
> >
> >Depends on what the purpose of the TSA is. If there is a conveyance in a
> >legal sense of Agency, then the TSA may have legally binding reasons for
> >being able to identify the type of content it is stamping. Maybe to the
> >granularity of needing to parse the file first to determine its data type.
> >
> >.. and this leads us to the fact that a HASH in and of itself as a
> >timestamping record is very difficult to use from an end user model. What
> >the TST should be is a framework or harness itself and internally it should
> >represent a number of events interchangeably. There would need to be
> >different grades of Tokens with varying levels of overhead for their
> >management, and the approriate BCP to match.
> >
> >But realize that in no uncertain terms what we are sitting on is  the
> >designing of the Global Mint here.
> >
> >"The real end user goal is a simple bolt-on system that allows end users
> to,
> >with the transaction infrastructure they have today,  add non-repudiation
> >at a commercial level to their process, and  at a scaleable and reasonable
> >overhead."
> >
> >Simple to say, not so simple to do as there are so many different
> >transaction
> >processing systems in the world today, but the common elements in all of
> >them is that they have some DB system that they are layered on and an OS
> >under that of some sort.
> >
> >With that being the key the DB that is, doesn't the idea of a common binary
> >data structure that is a timestamp token appeal to you (represented in the
> >cyber world as ASN.1 if you want) . We can build an TST Binary to XML
> >presentation system and absorb or bridge the IOTP/XML Receipt efforts at
> >some level into the PKIX Timestamping systems  and deliver evidentiary
> grade
> >standards for representing events in time and space. YOW - look at the
> >potential
> >there!!!.
> >
> >These tokens and their respective API's will be able to specify its level
> of
> >trust, the event it marks and the data components that make up that event,
> >and the rules of processing the token. If a lighter token is necessary
> >portions of the system can be replaced by OIDS on as "as many as possible"
> >basis based in the OID tree idea (see above). More risk mitigated
> >transactions may require self authenticating tokens as well and we should
> >provide for these at the high end of the API.
> >
> >Poof - Instant transaction systems. I think that this is what DigiCash and
> >most all of the other token based transactor companies tried to do but they
> >were too far ahead of the curve to get real traction - and as scary as it
> >sounds, PKIX is in the perfect position to make this fly now.
> >
> >BTW, in and of itself is reason for not advancing the TPS Draft.
> >
> >>
> >> Adrian Pickering/
> >> Electronics and Computer Science
> >> University of Southampton
> >> UK
> >>
> >>
> >
> >


Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA00404 for <[e-mail]>; Wed, 13 Sep 2000 04:13:09 -0700 (PDT)
Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA29349 for <[e-mail]>; Wed, 13 Sep 2000 12:15:20 +0100 (BST)
Received: from jap.ecs.soton.ac.uk (jap.ecs.soton.ac.uk [152.78.69.201]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id MAA02750 for <[e-mail]>; Wed, 13 Sep 2000 12:15:19 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 13 Sep 2000 12:09:59 +0100
To: [e-mail]
From: J Adrian Pickering <[e-mail]>
Subject: Re: The need for two grades of time data.
In-Reply-To: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <[e-mail]> <009301c01d21$be4d5800$020aff0c@tsg1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:22 13/09/00 +0100, Ben Laurie wrote:

>The IETF has already decided that enforcing various local laws is not
>within its remit (see the Raven WG) - that's not to say that PKIX should
>not attempt to make itself useful within likely international legal
>frameworks, but only in the sense of being capable of supporting them,
>insofar as is possible and in keeping with the open and international
>nature of the protocols, not by enforcing them as protocol requirements.

I concur. The focus is technical. However, technical decisions need to be 
made in the light of the real-world environment as far as we are able. This 
is tricky, but we MUST show that we have tried. That will ensure that IETF 
is exonerated from any legal flak later. We are in moving towards 
shark-infested waters with no cages at present.

Adrian Pickering/



Received: from irwell.zetnet.co.uk ([e-mail] [194.247.47.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA29853 for <[e-mail]>; Wed, 13 Sep 2000 04:06:08 -0700 (PDT)
Received: from jeffdavis (man-a129.dialup.zetnet.co.uk [194.247.44.129]) by irwell.zetnet.co.uk (8.9.3/8.9.3/Debian/GNU) with SMTP id MAA19648; Wed, 13 Sep 2000 12:08:01 +0100
X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a129.dialup.zetnet.co.uk [194.247.44.129] claimed to be jeffdavis
Message-ID: <00ee01c01d72$bc733d00$[e-mail]>
From: "Jeff Davis" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: New hash algorithms
Date: Wed, 13 Sep 2000 12:06:02 +0100
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.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Bob,

I am new to this but my understanding of Hash values were that they
would be dramatically different if a single bit was to change inside the
data that was being hashed.  Therefore, finding a duplicate hash value
would not be of any use as the data that produced it would be
significantly different in content and context to the original.  Thus,
if an attacker wanted to change a little data within a very sensitive
"transaction" then to create a hash value of that changed data, it would
be impossible to come up with the same hash value as the original.  The
digital signature would then expose the change.

Can you explain to me, in brief if possible, what an attacker would gain
from finding a duplicate hash inside 2^64 or 80?.  Help understanding
this would be appreciated as I feel I am missing something.

Cheers

Jeff Davis


----- Original Message -----
From: Bob Jueneman <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Tuesday, September 12, 2000 9:20 PM
Subject: New hash algorithms


> Rich,
>
> So far, I don't know anything at all about the new hash algorithms
> other than what Bill Burr posted.  It does seem like a good idea to
> have a selection of longer hashes available for high value
transactions,
> though.
>
> According to the Birthday Problem in statistics. two duplicate hash
values
> could conceivably be found (50% probability of one pair of duplicate)s
by
> comparing 2^64 trial values.
>
> Now computing hashes 2^64 is getting close to being feasible --
obviously
> 2^56 is feasible since DES has been broken by exhaustive search, and
> a hash algorithm is not as computationally intensive as DES.
>
> Based solely on the computational intensive argument, it would appear
that
> even SHA-1, which would require 2^80 trials to have a 50% chance of
> success, might not be strong enough, at least in the relatively near
future.
>
> But there is some good news, and some bad news.
>
> The bad news is that some attackers might be willing to settle for a
lot less
> than a 50% probability of success -- maybe 1%, or even .01% would be
> considered economically viable.  So that would argue that we should
> be conservative with respect to the length of a hash.
>
> The good news, however, is that although the use of massively parallel
> computers with millions of dedicated chips may make the computation of
all
> of those hashes feasible, there is still the problem of finding a
match --
> a needle in a million haystacks.
>
> At least with relatively conventional approaches to the problem, the
> sorting and searching problem is probably going to be the upper limit
of
> feasibility, and not the computational complexity.
>
> Simply storing the 20 byte result of 2^64 SHA-1 hashes would require
> 368,934 terabytes of storage -- a very impressive amount.  And SORTING
> such a database would be daunting, to say the least.
>
> I'll let the mathematicians who have looked at the problem much more
> recently than I have comment about the best way to find two duplicate
> values somewhere in such a massive amount of data, but when I examined
> that problem several decades ago, I concluded that sorting/searching
more
> than about 2^40 values was not likely to be feasible.
>
> Since then, however, various techniques ranging from molecular biology
> to quantum computers have been proposed, so looking at longer hash
> sizes is probably prudent.
>
> Ideally, the point we would like to get to is where the number of
possible
> values to be examined exceeds the estimated number of atoms in the
universe,
> and/or that the amount of energy needed to cycle through all of those
> states exceeds the amount of energy in the universe. Then we can
> probably quit!
>
> But the original question had to do with whether the hash algorithm
> should be specified independently of the signature algorithm.  For
maximum
> flexibility, that would be the desired approach.
>
> I guess what I am saying is that maximum flexibility is NOT what is
needed,
> because the interoperability and testing complexity (already quite
difficult enough)
> would rapidly go completely out of sight.
>
> What we need are a SMALL number of judicious choices as to various
> combinations, which each new combination, per se, having to be
justified
> on the merits.
>
> Picking winners isn't politically correct, and isn't very popular when
every
> contributor has the freedom to push his own pet rock.  But if we don't
start
> exercising the necessary engineering judgement and make the hard
choices,
> the products are going to be come more and more bloated and difficult
to
> test, to the detriment of everyone.
>
> Regards,
>
> Bob
>
>
>
>
> But
>
>
> >>> "Rich Ankney" <[e-mail]> 09/11/00 06:24PM >>>
> Bob,
>
> The current idea is to have OIDs for SHA-256, SHA-512, and SHA-384
> (truncated SHA-512).  At least in X9; your comments (and anone else's)
> are appreciated.  I know nothing else about these algorithms except
the
> following: SHA-x (with x >= 256) is not backward with SHA-1, i.e. you
> can't truncate a SHA-256 or whatever to SHA-160-bits.  So they are
> not doing the obvious (SHA-Y with Y > X in SHA-X being some sort of
> iteration of the same function with different IVs).  Of course that's
> obviously
> only 160 bits strong, so never mind.
>
> This is an area where you have lots of expertsise; I'd be interested
in your
> ideas (remembering the real version will be distributed to X9 in the
next
> few weeks, and I'll do my best to leak it to PKIX ASAP).
>
> Best,
> Rich
>
> -----Original Message-----
> From: Bob Jueneman <[e-mail]>
> To: [e-mail] <[e-mail]>; [e-mail]
> <[e-mail]>; [e-mail]
> <[e-mail]>
> Date: Monday, September 11, 2000 6:31 PM
> Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
>
>
> >In this regard, I was interested to hear on the Federal PKI TWG list
that
> NIST
> >is considering releasing a SHA-256 and SHA-512 hash algorithm.
> >
> >No new algorithms will be forthcoming -- the only question is whether
to
> >bundle them with the conventional signature OID, or to separate them
out.
> >
> >Bundling them makes them somewhat harder to change, but on the other
hand,
> >allowing complete freedom to choose the signing algorithm
independently
> tends to
> >raise issue of N-squared combinations that have to be tested.
> >
> >Some combinations might not even make technical sense -- for example
> 200-bit
> >elliptic curve DSA with SHA-512, since the hash function wouldn't fit
> within the
> >signature result.
> >
> >On balance, and noting the generally poor track record we have in
limiting
> >combinations of things to stable profiles, I am inclined to continue
the
> practice of
> >specifying the signature algorithm and the hash algorithm as one
joint
> specification.
> >
> >Bob
> >
> >>>> "todd glassey" <[e-mail]> 09/11/00 01:06PM
>>>
> >Hi all -
> >
> >----- Original Message -----
> >From: "J Adrian Pickering" <[e-mail]>
> >To: <[e-mail]>
> >Sent: Wednesday, September 06, 2000 7:57 AM
> >Subject: Re: CMC issues, TSP hashes
> >
> >
> >> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
> >>
> >> >- Use of SHA1 is hard coded in section 5.2. This does not leave
the
> >> >standard open for other hash algorithms. Are there any plans to
change
> >> >this?
> >>
> >> This is a problem shared with the TSP Draft also.
> >>
> >> (see posting -
> >> Date: Sat, 02 Sep 2000 17:37:43 +0100
> >> From: J Adrian Pickering <[e-mail]>
> >> Subject: TSP Draft - hash enforcement &c
> >> which is rather lost amongst the OCSP debate!)
> >>
> >> Please can something be done about this for everyone's benefit? My
> >> suggestion is to introduce a PKIX globally available OID
> >> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier.
This
> >> will enable other hashes to be used where required/wanted. The
> overloading
> >> of the AlgorithmIdentifier allows for a parameter which I'm not
sure is
> >any
> >> use in the hash arena?
> >
> >Actually Adrian  your right - but I think we need a little more than
this.
> >We need an official PKIX OID Tree and it needs to be available.
> >
> >For each complex data structure or process that can be uniquely
identified
> >and that would want to be identified, PKIX needs an OID entry in some
PKIX
> >master OID Table. Hash's, techniques, and maybe even the IOTP
Transaction
> >types or something like that as well.
> >
> >>
> >> Russ Housley appears to agree: "The selected one-way hash function
must
> be
> >> uniquely identified by an OID."
> >>
> >> I'd still rather have the TSA autonomously stamp an octet string
and
> leave
> >> the client to decide what it all means.
> >
> >We are confusing the term "Client" here for the term "USER OF"... and
this
> >is an important concept in understanding what we are really talking
about.
> >
> >The key issue is whether the time stamp is used to control some other
> >external process, almost analogous to dropping a coin into a vending
> >machine,
> >or whether it is standing as evidentiary testimony to some event. As
it
> >happens the Coin does both, but generally the mindset about how the
TSP has
> >been thought about is form using time as a control parameter rather
than an
> >evidentiary one. By the way - We generally as a group seem to assume
> >automatically between 'using data elements for control' rather than
'for
> >content'.
> >
> >In one case they are used to control the infrastructure or policy
> >like a signal, and on the other they are used to stand audit. The
uses of
> >the same parametric data elements here are very different and have
> different
> >needs to support their respective end use models.
> >
> >> What business is it of the TSA to
> >> know what it is stamping (semantically or syntactically)?
> >
> >Depends on what the purpose of the TSA is. If there is a conveyance
in a
> >legal sense of Agency, then the TSA may have legally binding reasons
for
> >being able to identify the type of content it is stamping. Maybe to
the
> >granularity of needing to parse the file first to determine its data
type.
> >
> >.. and this leads us to the fact that a HASH in and of itself as a
> >timestamping record is very difficult to use from an end user model.
What
> >the TST should be is a framework or harness itself and internally it
should
> >represent a number of events interchangeably. There would need to be
> >different grades of Tokens with varying levels of overhead for their
> >management, and the approriate BCP to match.
> >
> >But realize that in no uncertain terms what we are sitting on is  the
> >designing of the Global Mint here.
> >
> >"The real end user goal is a simple bolt-on system that allows end
users
> to,
> >with the transaction infrastructure they have today,  add
non-repudiation
> >at a commercial level to their process, and  at a scaleable and
reasonable
> >overhead."
> >
> >Simple to say, not so simple to do as there are so many different
> >transaction
> >processing systems in the world today, but the common elements in all
of
> >them is that they have some DB system that they are layered on and an
OS
> >under that of some sort.
> >
> >With that being the key the DB that is, doesn't the idea of a common
binary
> >data structure that is a timestamp token appeal to you (represented
in the
> >cyber world as ASN.1 if you want) . We can build an TST Binary to XML
> >presentation system and absorb or bridge the IOTP/XML Receipt efforts
at
> >some level into the PKIX Timestamping systems  and deliver
evidentiary
> grade
> >standards for representing events in time and space. YOW - look at
the
> >potential
> >there!!!.
> >
> >These tokens and their respective API's will be able to specify its
level
> of
> >trust, the event it marks and the data components that make up that
event,
> >and the rules of processing the token. If a lighter token is
necessary
> >portions of the system can be replaced by OIDS on as "as many as
possible"
> >basis based in the OID tree idea (see above). More risk mitigated
> >transactions may require self authenticating tokens as well and we
should
> >provide for these at the high end of the API.
> >
> >Poof - Instant transaction systems. I think that this is what
DigiCash and
> >most all of the other token based transactor companies tried to do
but they
> >were too far ahead of the curve to get real traction - and as scary
as it
> >sounds, PKIX is in the perfect position to make this fly now.
> >
> >BTW, in and of itself is reason for not advancing the TPS Draft.
> >
> >>
> >> Adrian Pickering/
> >> Electronics and Computer Science
> >> University of Southampton
> >> UK
> >>
> >>
> >
> >
>
>



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29307 for <[e-mail]>; Wed, 13 Sep 2000 03:55:37 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA16390; Wed, 13 Sep 2000 13:02:34 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA41634; Wed, 13 Sep 2000 12:57:14 +0200
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 12:57:15 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: The need for two grades of time data.
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <006d01c01d1e$a8403b20$020aff0c@tsg1>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Todd,

> Thanks for responding Steve, but again the real issue with 
> this concept of evidentiary time is in treating the parametric 
> time data as content rather than control process elements. 
> Once you do that it gets to be obvious that you need a 
> auth/certification stream and chain-of-custody model for that 
> time data to meet these evidentiary needs.
 
> So I have to ask - "What is the problem with treating time and 
> perhaps other parametric data like location data, as through 
> it had the same risks with it that the Human or Entity Identity 
> issues that spawned PKIX in the first place? because it does?"
 
> We seem to as a group have restricted our relating to time and 
> other parametric evidentiary processes as though they were only 
> part of the plumbing and it just aint so.
 
> Any of the data points that are use inside the decision support 
> process protocols that we are building (OCSP, TSP, etc etc etc) 
> are all tied to the requirement of some evidentiary anchor - 
> Someone or something has to sign that top level cert, some key 
> generator has to pump out that key pairing, and that data has been 
> sanctified by PKIX to date as it rightly should, but the use of 
> traditional Control Data points a parts of the larger evidentiary 
> or decision support process warrants that that data have the same
> integrity as any other. 
 
> Just my two cents.

It seems that you are trying to re-open a discussion that took place
in May 1999 (along BERT). So let me provide you with a copy of some
E-mails from May 1999 so that we can *definitively* close this
discussion. 

Denis

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

Object:  Re: Comments on time-stamp-01: Identification of TSA
Date:    Thu, 27 May 1999 13:55:18 -0400
From:    Stephen Kent <[e-mail]>
To:     "Todd S. Glassey - ELN" <[e-mail]>
Copies:  <[e-mail]>

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

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

Object: Re: Comments on time-stamp-01: Identification of TSA
Date:   Fri, 28 May 1999 11:43:40 +0200
From:   Denis Pinkas <[e-mail]>
To:     "Todd S. Glassey - ELN" <[e-mail]>
Copies: [e-mail]

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

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

... and finally an E-mail sent by Todd to me, not to the PKIX
mailing list that is worth to mention:

Object:  Re: Long-term validation of signatures
Date:    Mon, 26 Apr 1999 14:37:55 -0700
From:    "Todd S. Glassey" <[e-mail]>
To:      "Denis Pinkas" <[e-mail]>, "Hans Nilsson"
<[e-mail]>


Denis, don't take my commentary wrong.
The Draft(s) that you Pat, Carlisle, Robert produced are
FANTASTIC!!!. They represent the first credible mechanism for a
subsumable timebase service model and thats top-notch.

(snip)


Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA27982 for <[e-mail]>; Wed, 13 Sep 2000 03:20:49 -0700 (PDT)
Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id LAA13305; Wed, 13 Sep 2000 11:27:59 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Sep 2000 11:22:28 +0100
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: Rich Salz <[e-mail]>, [e-mail]
Subject: Re: The need for two grades of time data.
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <[e-mail]> <009301c01d21$be4d5800$020aff0c@tsg1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

todd glassey wrote:
> 
> Rich - I'm sorry but the IETF is exactly the place for it.
> 
> ----- Original Message -----
> From: "Rich Salz" <[e-mail]>
> To: "todd glassey" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, September 12, 2000 11:35 AM
> Subject: Re: The need for two grades of time data.
> 
> > >      What I want to do is to start a process of formally defining what
> an
> > > evidentiary grade time source is and what it must conform to.
> >
> > The IETF is not the place for this.  Start with ABA, or a similar
> > legal-focused entity.
> >
> 
> SNIP
> 
> > >
> > > The term "evidence" does pertain to proof, but "proof" has different
> > > meanings in different contexts. Civil trial evidence rules vary from
> > > one jurisdiction to another. PKIX is NOT going to wait for these
> > > rules to become uniform, or cater to different sets of rules. This is
> > > new legal territory and until there are ample case law precedents
> > > nobody will really know what will be required.  We can get lots of
> > > opinions from lawyers, and technologists who think they are lawyers,
> > > but, none of these opinions are authoritative. So, PKIX will continue
> > > to focus on the technical aspects of PKI and do the best we can to
> > > provide a solid technical basis for whatever the legal community may
> > > choose to adopt.
> 
> Actually here in the states this problem has already been answered by the
> enactment of the Digital Signature Act and the Federal Rules of Evidence and
> its a done deal already. Not something that Americans have a choice in
> anymore, that is  without repealing or amending the currently in-force Law.
> So there is law defining what X.509 Digital Signatures  and our PKIX systems
> do here in the US... and the rest of the world is not far behind.
> 
> What I personally think this means to PKIX is that it whether "it like it or
> not, it needs to look at legal things or it will eventuaually get its hand
> whacked so bad that someone like congress will step in an nationalize it.",
> and I think this neither funny or to far off in the inconceivable future
> either. The systems and processes that PKIX architects will carry our money
> and commerce and that means regulation like you never saw before. The last
> 50 years have just been getting ready for it. Just wait and see.
> 
> The reality is that now that there is legal basis in the technologies we
> designed, they answer to a higher authority than us or the IESG and that is
> that. If PKIX doesn't like this unique twist of fate, then maybe shutting it
> down is appropriate.
> 
> In closing the point is that we as PKIX have an opportunity to embrace a set
> of operations and audit guidelines that will enable more of what we produce
> to see the end-market.
> 
> How grand is our collective ego to not want this?

The IETF has already decided that enforcing various local laws is not
within its remit (see the Raven WG) - that's not to say that PKIX should
not attempt to make itself useful within likely international legal
frameworks, but only in the sense of being capable of supporting them,
insofar as is possible and in keeping with the open and international
nature of the protocols, not by enforcing them as protocol requirements.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/


Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06716 for <[e-mail]>; Tue, 12 Sep 2000 18:31:00 -0700 (PDT)
Received: from tsg1 ([12.72.1.157]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913013238.JRWD6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 01:32:38 +0000
Message-ID: <00b501c01d22$68f1e230$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><006f01c019ac$2f9b7380$020aff0c@tsg1> <v04220810b5e2fd870ec2@[171.78.30.107]><001d01c01c49$3bf3fd10$020aff0c@tsg1> <v04220805b5e3f262fc32@[171.78.30.107]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Date: Tue, 12 Sep 2000 18:31:57 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Stephen I replied privately.

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, September 12, 2000 8:40 AM
Subject: Re: draft-ietf-pkix-time-stamp-09 comments


> Todd,
>
> ><snip>
> >
> >The problem is that the term Evidence pertains to PROOF and that these
> >proofing models are what we are up to is becoming really clear here.
>
> The term "evidence" does pertain to proof, but "proof" has different
> meanings in different contexts. Civil trial evidence rules vary from
> one jurisdiction to another. PKIX is NOT going to wait for these
> rules to become uniform, or cater to different sets of rules. This is
> new legal territory and until there are ample case law precedents
> nobody will really know what will be required.  We can get lots of
> opinions from lawyers, and technologists who think they are lawyers,
> but, none of these opinions are authoritative. So, PKIX will continue
> to focus on the technical aspects of PKI and do the best we can to
> provide a solid technical basis for whatever the legal community may
> choose to adopt.
>
> We've seen dramatically different views of various aspects of NR
> arising in different contexts already, e.g., the German digital
> signature model, vs. the EU directive, etc. We're not changing PKIX
> standards to match any of these models.
>
> ><snip>
> >  > Note that PKIX has avoided developing standards that are influenced
> >  > by the various emerging legal criteria for digital signatures in
> >  > different countries, states, etc.
> >
> >This is becuase PKIX was focusing on the CORE Technologies not the use of
> >them. Now that the Core Technologies are done the next step is to put
> >together a set of recommended uses for them.
>
> TSP is still a core technology supportive of many uses.
>
> ><snip>
> >  > >
> >  > >Poof! The whole world changes.
> >  >
> >  > Not really. Many other aspects of the PKIX work address NR, not just
> >  > TSP.
> >
> >Steve I disagree. What they do is to use the term NR to refer to a wrath
of
> >services that they may offer. But in the context of this group the TERM
NR
> >went through months of hammering out and still does not mean the same
thing
> >to everyone here.
> >
> >what we maybe might look at is definign the NR process a  suite of
methods
> >to create comparable levels of non-repudiation at the process component
> >level, but this is another issue all together.
>
> "Wrath of services?" What dictionary are you using :-)?
>
> You are right that not everyone in the WG agrees on NR definitions
> and mechanisms. But, this is the IETF and we don't require complete
> consensus. However, you could propose a new work item which would try
> to do what you suggest here, i.e., document suites of mechanisms
> that, in concert, provide NR.
>
> >  > We have adopted a consistent approach to this work, as noted
> >  > above, which is independent of the vagaries of the legal systems that
> >  > are now trying to address these complex issues.
> >  >
> >  > >
> >  > >Now what is important is:
> >  > >--------------------------
> >  > >             o-    What Evidentiary Standards the model conforms to
(US,
> >UK,
> >  > >who's else?)
> >  >
> >  > See comments above on technical focus vs. legal focus.  The notion of
> >  > tailoring this work to the legal system of any of the above is not
> >  > going to happen.
> >
> >Are you saying this as the group's chair or as a member? I am assuming I
> >just annoyed you by bringing this up again. So I am not offended.
>
> I'm speaking as chair in this discussion, but I think the rationale
> for my position on this matter is obvious and consistent.
>
> >
> >My feeling is that this take dooms  PKIX in that this is what the inustry
> >and the world needs now.
>
> Reasonable men may disagree about what the world needs now, and
> whether a given IETF WG must address that need. (BTW, I thought the
> answer to that question was "love, true love, that's the only thing
> that there's too little of.")
>
> >  > >             o-    How is the quality of the data inside the stamp
token
> >  > >assured and how its is obtained. (I.e. the chain of custody and
audit
> >trail,
> >  > >and certification process for the data. BTW - This goes back to my
> >concept
> >  > >of TRUST ANCHORS)
> >  >
> >  > In developing standards, the IETF often chooses to address parts of a
> >  > problem,  rather than all aspects of a problem.
> >
> >This attitude may only work for low level core components, when you step
> >ooutside these domains the requirements change and PKIX is clearly
stepping
> >into areas that need use models and BCP recommendations.
>
> I agree that it may be appropriate to develop BCPs to complement our
> base standards, once there is enough experience to be able to claim
> that something really is a BEST COMMON PRACTICE. But we are not there
> yet for time stamping, and a BCP follows, usually by some significant
> delay, the publication and adoption of a standard that is employed in
> a BCP. So, the order is first, we adopt a standard such as TSP, then
> we gain experience, then we publish a BCP.
>
> ><snip>
> >  >
> >  > This issue has been addressed on the list, but the document could do
> >  > a better job of clarifying the position it takes. Time stamps from a
> >  > given TSA are ordered, but there is no guarantee that time stamps
> >  > issued by different TSAs are ordered, since different TSAs may employ
> >  > different time bases, offer different accuracy guarantees, etc. On
> >  > can image various scenarios in which two time stamps, issued by two
> >  > TSAs are not comparable. I agree that the document could do a better
> >  > job of discussing this issue.
> >
> >Thanks. But what do you think about the idea of reorientating that
document
> >so that it has two major sections before it gets advanced.  The TST's and
> >their Use Models would be one and the API"s to support them - this would
> >involve the addition of the AD section on the use and a number of TST
> >models. All in all it could be easily done and then we could all put the
> >standard to bed. I
>
> APIs are very separate from protocol standards.  For many years the
> IETF did not consider APIs as subjects for standardization, as they
> are not relevant to external interoperability. We have softened that
> view a bit, but an API is still secondary to the protocol for which
> it is an interface. If there is a demand for development of an API,
> then we can do so as a separate work item, but it in no way is a
> requirement for this document.
>
> >I and the others that are concerned get the evidentiary grades of content
we
> >want in the timestamps and the rest of the world gets what's alreadyin
the
> >draft - This is a workable solution I think
>
> I predict that if we were to delay the document to accommodate these
> additional sections, that there would be a long debate over whose use
> models were included, and what API was adopted. The IESG will decide
> whether we need to hold up this document to address the use models
> you want, but my recommendation will be to defer this, and the APIs.
>
> Steve
>



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06394 for <[e-mail]>; Tue, 12 Sep 2000 18:26:13 -0700 (PDT)
Received: from tsg1 ([12.72.1.157]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913012752.JPOY6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 01:27:52 +0000
Message-ID: <009301c01d21$be4d5800$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Rich Salz" <[e-mail]>
Cc: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]> <[e-mail]>
Subject: Re: The need for two grades of time data.
Date: Tue, 12 Sep 2000 18:27:11 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Rich - I'm sorry but the IETF is exactly the place for it.

----- Original Message -----
From: "Rich Salz" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, September 12, 2000 11:35 AM
Subject: Re: The need for two grades of time data.


> >      What I want to do is to start a process of formally defining what
an
> > evidentiary grade time source is and what it must conform to.
>
> The IETF is not the place for this.  Start with ABA, or a similar
> legal-focused entity.
>

SNIP

> >
> > The term "evidence" does pertain to proof, but "proof" has different
> > meanings in different contexts. Civil trial evidence rules vary from
> > one jurisdiction to another. PKIX is NOT going to wait for these
> > rules to become uniform, or cater to different sets of rules. This is
> > new legal territory and until there are ample case law precedents
> > nobody will really know what will be required.  We can get lots of
> > opinions from lawyers, and technologists who think they are lawyers,
> > but, none of these opinions are authoritative. So, PKIX will continue
> > to focus on the technical aspects of PKI and do the best we can to
> > provide a solid technical basis for whatever the legal community may
> > choose to adopt.

Actually here in the states this problem has already been answered by the
enactment of the Digital Signature Act and the Federal Rules of Evidence and
its a done deal already. Not something that Americans have a choice in
anymore, that is  without repealing or amending the currently in-force Law.
So there is law defining what X.509 Digital Signatures  and our PKIX systems
do here in the US... and the rest of the world is not far behind.

What I personally think this means to PKIX is that it whether "it like it or
not, it needs to look at legal things or it will eventuaually get its hand
whacked so bad that someone like congress will step in an nationalize it.",
and I think this neither funny or to far off in the inconceivable future
either. The systems and processes that PKIX architects will carry our money
and commerce and that means regulation like you never saw before. The last
50 years have just been getting ready for it. Just wait and see.

The reality is that now that there is legal basis in the technologies we
designed, they answer to a higher authority than us or the IESG and that is
that. If PKIX doesn't like this unique twist of fate, then maybe shutting it
down is appropriate.

In closing the point is that we as PKIX have an opportunity to embrace a set
of operations and audit guidelines that will enable more of what we produce
to see the end-market.

How grand is our collective ego to not want this?

Todd



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05539 for <[e-mail]>; Tue, 12 Sep 2000 18:04:10 -0700 (PDT)
Received: from tsg1 ([12.72.1.157]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000913010546.JEYG6605.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 13 Sep 2000 01:05:46 +0000
Message-ID: <006d01c01d1e$a8403b20$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]>
Subject: Re: The need for two grades of time data.
Date: Tue, 12 Sep 2000 18:05:06 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01C01CE3.FB03D460"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

This is a multi-part message in MIME format.

------=_NextPart_000_006A_01C01CE3.FB03D460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for responding Steve, but again the real issue with this concept =
of evidentiary time is in treating the parametric time data as content =
rather than control process elements. Once you do that it gets to be =
obvious that you need a auth/certification stream and chain-of-custody =
model for that time data to meet these evidentiary needs.

So I have to ask - "What is the problem with treating time and perhaps =
other parametric data like location data, as through it had the same =
risks with it that the Human or Entity Identity issues that spawned PKIX =
in the first place? because it does?"

We seem to as a group have restricted our relating to time and other =
parametric evidentiary processes as though they were only part of the =
plumbing and it just aint so.

Any of the data points that are use inside the decision support process =
protocols that we are building (OCSP, TSP, etc etc etc) are all tied to =
the requirement of some evidentiary anchor - Someone or something has to =
sign that top level cert, some key generator has to pump out that key =
pairing, and that data has been sanctified by PKIX to date as it rightly =
should, but the use of traditional Control Data points a parts of the =
larger evidentiary or decision support process warrants that that data =
have the same integrity as any other.=20

Just my two cents.
  ----- Original Message -----=20
  From: Stephen Kent=20
  To: todd glassey=20
  Cc: [e-mail]=20
  Sent: Tuesday, September 12, 2000 11:12 AM
  Subject: Re: The need for two grades of time data.


  Todd,


    All - I have some concerns with the TSP Draft and one of them that I =
will break out here is the merging of the concepts that Evidentiary and =
Policy Grade time sources are identical. They simply are not. There are =
a number of problems with the concept that instantaneously accurate time =
data is also provable by itself in the future. Without the proofing =
model, the value of the time data is that of the weakest link in the =
system.

    The issue is that we use time as content and as a control parameter =
and it has very different uses and requirements in each. The use of time =
as evidentiary content, i.e. as in time stamping, is one where the =
source and viability of the time data is critical and with the current =
TSP we have chooses for some reason to specifically overlook this.

    What I want to do is to start a process of formally defining what an =
evidentiary grade time source is and what it must conform to.

    This in PKIX and will allow us to understand time use models and =
more adequately define the needs and roles of trusted timing authorities =
in our larger trust processes.

    Does this seem like a win for the group?


  As noted in my response to your earlier message, the IETF is an =
international standards organization. The IAB and IESG have promulgated =
position statements on this topic several times. It has been most =
obvious in adopting security standards that conflicted with export =
control rules in several countries.=20

  Looking at this in an international context, and absent a uniform, =
authoritative basis for the sort of time stamp related criteria you =
allude to above, it would seem that this sort of work is not consistent =
with what the IETF does as a standards body.

  Steve=20

------=_NextPart_000_006A_01C01CE3.FB03D460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c8e0d8>
<DIV><FONT face=3DArial size=3D2>Thanks for responding Steve, but again =
the real=20
issue with this concept of evidentiary time is in treating the =
parametric time=20
data as content rather than control process elements. Once you do that =
it gets=20
to be obvious that you need a auth/certification stream and =
chain-of-custody=20
model for that time data to meet these evidentiary needs.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>So I have to ask - "What is the problem =
with=20
treating time and perhaps other parametric data like location data, as =
through=20
it had the same risks with it that the Human or Entity Identity issues =
that=20
spawned PKIX in the first place? because it does?"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>We seem to as a group have restricted =
our relating=20
to time and other parametric evidentiary processes as though they were =
only part=20
of the plumbing and it just aint so.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any of the data points that are use =
inside the=20
decision support process protocols that we are building (OCSP, TSP, etc =
etc etc)=20
are all tied to the requirement of some evidentiary anchor</FONT><FONT=20
face=3DArial size=3D2> - Someone or something has to sign that top level =
cert, some=20
key generator has to pump out that key pairing, and that data has been=20
sanctified by PKIX to date as it rightly should, but the use of =
traditional=20
Control Data points a parts of the larger evidentiary or decision =
support=20
process warrants that that data have the same integrity as any other.=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Just my two cents.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]" title=[e-mail]>Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:[e-mail]"=20
  title=[e-mail]>todd glassey</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>[e-mail]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, September 12, =
2000 11:12=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: The need for two =
grades of=20
  time data.</DIV>
  <DIV><BR></DIV>Todd,<BR><BR>
  <BLOCKQUOTE><?fontfamily><?param Arial>All - I have some concerns with =
the=20
    TSP Draft and one of them that I will break out here is the merging =
of the=20
    concepts that Evidentiary and Policy Grade time sources are =
identical. They=20
    simply are not. There are a number of problems with the concept that =

    instantaneously accurate time data is also provable by itself in the =
future.=20
    Without the proofing model, the value of the time data is that of =
the=20
    weakest link in the system.<BR><BR>The issue is that we use time as =
content=20
    and as a control parameter and it has very different uses and =
requirements=20
    in each. The use of time as evidentiary content, i.e. as in time =
stamping,=20
    is one where the source and viability of the time data is critical =
and with=20
    the current TSP we have chooses for some reason to specifically =
overlook=20
    this.<BR><BR>What I want to do is to start a process of formally =
defining=20
    what an evidentiary grade time source is and what it must conform=20
    to.<BR><BR>This in PKIX and will allow us to understand time use =
models and=20
    more adequately define the needs and roles of trusted timing =
authorities in=20
    our larger trust processes.<BR><BR>Does this seem like a win for the =

    group?<BR><?/fontfamily></BLOCKQUOTE><?fontfamily><?param =
Arial><BR><?/fontfamily>As=20
  noted in my response to your earlier message, the IETF is an =
international=20
  standards organization. The IAB and IESG have promulgated position =
statements=20
  on this topic several times. It has been most obvious in adopting =
security=20
  standards that conflicted with export control rules in several =
countries.=20
  <BR><BR>Looking at this in an international context, and absent a =
uniform,=20
  authoritative basis for the sort of time stamp related criteria you =
allude to=20
  above, it would seem that this sort of work is not consistent with =
what the=20
  IETF does as a standards body.<BR><BR>Steve =
</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_006A_01C01CE3.FB03D460--



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA00677 for <[e-mail]>; Tue, 12 Sep 2000 13:18:35 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 12 Sep 2000 14:20:06 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Tue, 12 Sep 2000 14:20:00 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: New hash algorithms
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 ns.secondary.com id NAA00678

Rich,

So far, I don't know anything at all about the new hash algorithms
other than what Bill Burr posted.  It does seem like a good idea to 
have a selection of longer hashes available for high value transactions,
though.

According to the Birthday Problem in statistics. two duplicate hash values
could conceivably be found (50% probability of one pair of duplicate)s by 
comparing 2^64 trial values.

Now computing hashes 2^64 is getting close to being feasible -- obviously 
2^56 is feasible since DES has been broken by exhaustive search, and 
a hash algorithm is not as computationally intensive as DES.

Based solely on the computational intensive argument, it would appear that
even SHA-1, which would require 2^80 trials to have a 50% chance of 
success, might not be strong enough, at least in the relatively near future.

But there is some good news, and some bad news.

The bad news is that some attackers might be willing to settle for a lot less 
than a 50% probability of success -- maybe 1%, or even .01% would be 
considered economically viable.  So that would argue that we should 
be conservative with respect to the length of a hash.

The good news, however, is that although the use of massively parallel 
computers with millions of dedicated chips may make the computation of all
of those hashes feasible, there is still the problem of finding a match --
a needle in a million haystacks.

At least with relatively conventional approaches to the problem, the 
sorting and searching problem is probably going to be the upper limit of
feasibility, and not the computational complexity.  

Simply storing the 20 byte result of 2^64 SHA-1 hashes would require
368,934 terabytes of storage -- a very impressive amount.  And SORTING
such a database would be daunting, to say the least.

I'll let the mathematicians who have looked at the problem much more 
recently than I have comment about the best way to find two duplicate 
values somewhere in such a massive amount of data, but when I examined 
that problem several decades ago, I concluded that sorting/searching more
than about 2^40 values was not likely to be feasible.

Since then, however, various techniques ranging from molecular biology
to quantum computers have been proposed, so looking at longer hash 
sizes is probably prudent.

Ideally, the point we would like to get to is where the number of possible 
values to be examined exceeds the estimated number of atoms in the universe,
and/or that the amount of energy needed to cycle through all of those 
states exceeds the amount of energy in the universe. Then we can 
probably quit!

But the original question had to do with whether the hash algorithm 
should be specified independently of the signature algorithm.  For maximum 
flexibility, that would be the desired approach.

I guess what I am saying is that maximum flexibility is NOT what is needed,
because the interoperability and testing complexity (already quite difficult enough)
would rapidly go completely out of sight.

What we need are a SMALL number of judicious choices as to various 
combinations, which each new combination, per se, having to be justified 
on the merits.

Picking winners isn't politically correct, and isn't very popular when every 
contributor has the freedom to push his own pet rock.  But if we don't start 
exercising the necessary engineering judgement and make the hard choices,
the products are going to be come more and more bloated and difficult to 
test, to the detriment of everyone.

Regards,

Bob




But 


>>> "Rich Ankney" <[e-mail]> 09/11/00 06:24PM >>>
Bob,

The current idea is to have OIDs for SHA-256, SHA-512, and SHA-384
(truncated SHA-512).  At least in X9; your comments (and anone else's)
are appreciated.  I know nothing else about these algorithms except the
following: SHA-x (with x >= 256) is not backward with SHA-1, i.e. you
can't truncate a SHA-256 or whatever to SHA-160-bits.  So they are
not doing the obvious (SHA-Y with Y > X in SHA-X being some sort of
iteration of the same function with different IVs).  Of course that's
obviously
only 160 bits strong, so never mind.

This is an area where you have lots of expertsise; I'd be interested in your
ideas (remembering the real version will be distributed to X9 in the next
few weeks, and I'll do my best to leak it to PKIX ASAP).

Best,
Rich

-----Original Message-----
From: Bob Jueneman <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail] 
<[e-mail]>; [e-mail] 
<[e-mail]>
Date: Monday, September 11, 2000 6:31 PM
Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -


>In this regard, I was interested to hear on the Federal PKI TWG list that
NIST
>is considering releasing a SHA-256 and SHA-512 hash algorithm.
>
>No new algorithms will be forthcoming -- the only question is whether to
>bundle them with the conventional signature OID, or to separate them out.
>
>Bundling them makes them somewhat harder to change, but on the other hand,
>allowing complete freedom to choose the signing algorithm independently
tends to
>raise issue of N-squared combinations that have to be tested.
>
>Some combinations might not even make technical sense -- for example
200-bit
>elliptic curve DSA with SHA-512, since the hash function wouldn't fit
within the
>signature result.
>
>On balance, and noting the generally poor track record we have in limiting
>combinations of things to stable profiles, I am inclined to continue the
practice of
>specifying the signature algorithm and the hash algorithm as one joint
specification.
>
>Bob
>
>>>> "todd glassey" <[e-mail]> 09/11/00 01:06PM >>>
>Hi all -
>
>----- Original Message -----
>From: "J Adrian Pickering" <[e-mail]>
>To: <[e-mail]>
>Sent: Wednesday, September 06, 2000 7:57 AM
>Subject: Re: CMC issues, TSP hashes
>
>
>> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>>
>> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
>> >standard open for other hash algorithms. Are there any plans to change
>> >this?
>>
>> This is a problem shared with the TSP Draft also.
>>
>> (see posting -
>> Date: Sat, 02 Sep 2000 17:37:43 +0100
>> From: J Adrian Pickering <[e-mail]>
>> Subject: TSP Draft - hash enforcement &c
>> which is rather lost amongst the OCSP debate!)
>>
>> Please can something be done about this for everyone's benefit? My
>> suggestion is to introduce a PKIX globally available OID
>> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
>> will enable other hashes to be used where required/wanted. The
overloading
>> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
>any
>> use in the hash arena?
>
>Actually Adrian  your right - but I think we need a little more than this.
>We need an official PKIX OID Tree and it needs to be available.
>
>For each complex data structure or process that can be uniquely identified
>and that would want to be identified, PKIX needs an OID entry in some PKIX
>master OID Table. Hash's, techniques, and maybe even the IOTP Transaction
>types or something like that as well.
>
>>
>> Russ Housley appears to agree: "The selected one-way hash function must
be
>> uniquely identified by an OID."
>>
>> I'd still rather have the TSA autonomously stamp an octet string and
leave
>> the client to decide what it all means.
>
>We are confusing the term "Client" here for the term "USER OF"... and this
>is an important concept in understanding what we are really talking about.
>
>The key issue is whether the time stamp is used to control some other
>external process, almost analogous to dropping a coin into a vending
>machine,
>or whether it is standing as evidentiary testimony to some event. As it
>happens the Coin does both, but generally the mindset about how the TSP has
>been thought about is form using time as a control parameter rather than an
>evidentiary one. By the way - We generally as a group seem to assume
>automatically between 'using data elements for control' rather than  'for
>content'.
>
>In one case they are used to control the infrastructure or policy
>like a signal, and on the other they are used to stand audit. The uses of
>the same parametric data elements here are very different and have
different
>needs to support their respective end use models.
>
>> What business is it of the TSA to
>> know what it is stamping (semantically or syntactically)?
>
>Depends on what the purpose of the TSA is. If there is a conveyance in a
>legal sense of Agency, then the TSA may have legally binding reasons for
>being able to identify the type of content it is stamping. Maybe to the
>granularity of needing to parse the file first to determine its data type.
>
>.. and this leads us to the fact that a HASH in and of itself as a
>timestamping record is very difficult to use from an end user model. What
>the TST should be is a framework or harness itself and internally it should
>represent a number of events interchangeably. There would need to be
>different grades of Tokens with varying levels of overhead for their
>management, and the approriate BCP to match.
>
>But realize that in no uncertain terms what we are sitting on is  the
>designing of the Global Mint here.
>
>"The real end user goal is a simple bolt-on system that allows end users
to,
>with the transaction infrastructure they have today,  add non-repudiation
>at a commercial level to their process, and  at a scaleable and reasonable
>overhead."
>
>Simple to say, not so simple to do as there are so many different
>transaction
>processing systems in the world today, but the common elements in all of
>them is that they have some DB system that they are layered on and an OS
>under that of some sort.
>
>With that being the key the DB that is, doesn't the idea of a common binary
>data structure that is a timestamp token appeal to you (represented in the
>cyber world as ASN.1 if you want) . We can build an TST Binary to XML
>presentation system and absorb or bridge the IOTP/XML Receipt efforts at
>some level into the PKIX Timestamping systems  and deliver evidentiary
grade
>standards for representing events in time and space. YOW - look at the
>potential
>there!!!.
>
>These tokens and their respective API's will be able to specify its level
of
>trust, the event it marks and the data components that make up that event,
>and the rules of processing the token. If a lighter token is necessary
>portions of the system can be replaced by OIDS on as "as many as possible"
>basis based in the OID tree idea (see above). More risk mitigated
>transactions may require self authenticating tokens as well and we should
>provide for these at the high end of the API.
>
>Poof - Instant transaction systems. I think that this is what DigiCash and
>most all of the other token based transactor companies tried to do but they
>were too far ahead of the curve to get real traction - and as scary as it
>sounds, PKIX is in the perfect position to make this fly now.
>
>BTW, in and of itself is reason for not advancing the TPS Draft.
>
>>
>> Adrian Pickering/
>> Electronics and Computer Science
>> University of Southampton
>> UK
>>
>>
>
>



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA00438 for <[e-mail]>; Tue, 12 Sep 2000 13:15:08 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 12 Sep 2000 14:10:51 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Tue, 12 Sep 2000 14:10:52 -0600
From: "Baber Amin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Certificate request from P10 to PEM
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 ns.secondary.com id NAA00439

Depends on if Steve is asking for openSSL usage of the word PEM or the original PEM format.  In case of openSSL PEM is I am told just a b64 encoding of the keys and certificates.

Baber
:)

>>> Jean-Marc Desperrier <[e-mail]> 09/12/00 09:39AM >>>
"Hewitt, Jim" wrote:

> CertCo has a "Swiss Army knife" tool that does this and many related
> operations.  Contact me privately to get a copy.
>
> -----Original Message-----
> From: Steve Wang [mailto:[e-mail]] 
> Sent: Monday, September 11, 2000 9:45 AM
> To: [e-mail] 
> Subject: Certificate request from P10 to PEM
>
> Are there any tools available to convert a certificate request from P10
> format to PEM format?

OpenSSL does it very well too.

http://www.openssl.org 




Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29126; Tue, 12 Sep 2000 12:10:50 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05001909b5e430600adb@[165.227.249.17]>
In-Reply-To: <002101c01cde$5a73f480$020aff0c@tsg1>
References: <002101c01cde$5a73f480$020aff0c@tsg1>
Date: Tue, 12 Sep 2000 12:12:55 -0700
To: "todd glassey" <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: The need for two grades of time data.
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 10:24 AM -0700 9/12/00, todd glassey wrote:
>Does this seem like a win for the group?

No. In fact, it seems like a lose. It would be better to discuss this 
among experts in the field (that is, lawyers) with some technical 
assistance from the security industry.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from mail.storm.ca (storm.ca [209.87.239.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28334 for <[e-mail]>; Tue, 12 Sep 2000 11:34:12 -0700 (PDT)
From: [e-mail]
Received: from mailman.endymion.com (mail.storm.ca [209.87.239.69]) by mail.storm.ca (8.9.3+Sun/8.9.3) with SMTP id OAA19068; Tue, 12 Sep 2000 14:35:43 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: <[e-mail]>
Subject: Fwd: Re: draft-ietf-pkix-time-stamp-09 comments
Date: Tue, 12 Sep 2000 14:35:43 +0000
X-Mailer: Endymion MailMan Standard Edition v3.0.2

Forwarded Message:
> To: "todd glassey" <[e-mail]>
> From: Stephen Kent <[e-mail]>
> Subject: Re: draft-ietf-pkix-time-stamp-09 comments
> Date: Tue, 12 Sep 2000 11:40:45 -0400
> -----
> Todd,
> 
> ><snip>
> >
> >The problem is that the term Evidence pertains to PROOF and that these
> >proofing models are what we are up to is becoming really clear here.
> 
> The term "evidence" does pertain to proof, but "proof" has different 
> meanings in different contexts. Civil trial evidence rules vary from 
> one jurisdiction to another. PKIX is NOT going to wait for these 
> rules to become uniform, or cater to different sets of rules. This is 
> new legal territory and until there are ample case law precedents 
> nobody will really know what will be required.  We can get lots of 
> opinions from lawyers, and technologists who think they are lawyers, 
> but, none of these opinions are authoritative. So, PKIX will continue 
> to focus on the technical aspects of PKI and do the best we can to 
> provide a solid technical basis for whatever the legal community may 
> choose to adopt.
> 
> We've seen dramatically different views of various aspects of NR 
> arising in different contexts already, e.g., the German digital 
> signature model, vs. the EU directive, etc. We're not changing PKIX 
> standards to match any of these models.
> 
> ><snip>
> >  > Note that PKIX has avoided developing standards that are influenced
> >  > by the various emerging legal criteria for digital signatures in
> >  > different countries, states, etc.
> >
> >This is becuase PKIX was focusing on the CORE Technologies not the use of
> >them. Now that the Core Technologies are done the next step is to put
> >together a set of recommended uses for them.
> 
> TSP is still a core technology supportive of many uses.
> 
> ><snip>
> >  > >
> >  > >Poof! The whole world changes.
> >  >
> >  > Not really. Many other aspects of the PKIX work address NR, not just
> >  > TSP.
> >
> >Steve I disagree. What they do is to use the term NR to refer to a wrath of
> >services that they may offer. But in the context of this group the TERM NR
> >went through months of hammering out and still does not mean the same thing
> >to everyone here.
> >
> >what we maybe might look at is definign the NR process a  suite of methods
> >to create comparable levels of non-repudiation at the process component
> >level, but this is another issue all together.
> 
> "Wrath of services?" What dictionary are you using :-)?
> 
> You are right that not everyone in the WG agrees on NR definitions 
> and mechanisms. But, this is the IETF and we don't require complete 
> consensus. However, you could propose a new work item which would try 
> to do what you suggest here, i.e., document suites of mechanisms 
> that, in concert, provide NR.
> 
> >  > We have adopted a consistent approach to this work, as noted
> >  > above, which is independent of the vagaries of the legal systems that
> >  > are now trying to address these complex issues.
> >  >
> >  > >
> >  > >Now what is important is:
> >  > >--------------------------
> >  > >             o-    What Evidentiary Standards the model conforms to (US,
> >UK,
> >  > >who's else?)
> >  >
> >  > See comments above on technical focus vs. legal focus.  The notion of
> >  > tailoring this work to the legal system of any of the above is not
> >  > going to happen.
> >
> >Are you saying this as the group's chair or as a member? I am assuming I
> >just annoyed you by bringing this up again. So I am not offended.
> 
> I'm speaking as chair in this discussion, but I think the rationale 
> for my position on this matter is obvious and consistent.
> 
> >
> >My feeling is that this take dooms  PKIX in that this is what the inustry
> >and the world needs now.
> 
> Reasonable men may disagree about what the world needs now, and 
> whether a given IETF WG must address that need. (BTW, I thought the 
> answer to that question was "love, true love, that's the only thing 
> that there's too little of.")
> 
> >  > >             o-    How is the quality of the data inside the stamp token
> >  > >assured and how its is obtained. (I.e. the chain of custody and audit
> >trail,
> >  > >and certification process for the data. BTW - This goes back to my
> >concept
> >  > >of TRUST ANCHORS)
> >  >
> >  > In developing standards, the IETF often chooses to address parts of a
> >  > problem,  rather than all aspects of a problem.
> >
> >This attitude may only work for low level core components, when you step
> >ooutside these domains the requirements change and PKIX is clearly stepping
> >into areas that need use models and BCP recommendations.
> 
> I agree that it may be appropriate to develop BCPs to complement our 
> base standards, once there is enough experience to be able to claim 
> that something really is a BEST COMMON PRACTICE. But we are not there 
> yet for time stamping, and a BCP follows, usually by some significant 
> delay, the publication and adoption of a standard that is employed in 
> a BCP. So, the order is first, we adopt a standard such as TSP, then 
> we gain experience, then we publish a BCP.
> 
> ><snip>
> >  >
> >  > This issue has been addressed on the list, but the document could do
> >  > a better job of clarifying the position it takes. Time stamps from a
> >  > given TSA are ordered, but there is no guarantee that time stamps
> >  > issued by different TSAs are ordered, since different TSAs may employ
> >  > different time bases, offer different accuracy guarantees, etc. On
> >  > can image various scenarios in which two time stamps, issued by two
> >  > TSAs are not comparable. I agree that the document could do a better
> >  > job of discussing this issue.
> >
> >Thanks. But what do you think about the idea of reorientating that document
> >so that it has two major sections before it gets advanced.  The TST's and
> >their Use Models would be one and the API"s to support them - this would
> >involve the addition of the AD section on the use and a number of TST
> >models. All in all it could be easily done and then we could all put the
> >standard to bed. I
> 
> APIs are very separate from protocol standards.  For many years the 
> IETF did not consider APIs as subjects for standardization, as they 
> are not relevant to external interoperability. We have softened that 
> view a bit, but an API is still secondary to the protocol for which 
> it is an interface. If there is a demand for development of an API, 
> then we can do so as a separate work item, but it in no way is a 
> requirement for this document.
> 
> >I and the others that are concerned get the evidentiary grades of content we
> >want in the timestamps and the rest of the world gets what's alreadyin the
> >draft - This is a workable solution I think
> 
> I predict that if we were to delay the document to accommodate these 
> additional sections, that there would be a long debate over whose use 
> models were included, and what API was adopted. The IESG will decide 
> whether we need to hold up this document to address the use models 
> you want, but my recommendation will be to defer this, and the APIs.
> 
> Steve
> 
> 




Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA28086 for <[e-mail]>; Tue, 12 Sep 2000 11:30:54 -0700 (PDT)
Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 02015428; Tue, 12 Sep 2000 14:32:46 -0400 (EDT)
Sender: rsalz
Message-ID: <[e-mail]>
Date: Tue, 12 Sep 2000 14:35:35 -0400
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail]
Subject: Re: The need for two grades of time data.
References: <002101c01cde$5a73f480$020aff0c@tsg1> <v04220811b5e4216f0a23@[171.78.30.107]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1

>      What I want to do is to start a process of formally defining what an
> evidentiary grade time source is and what it must conform to.

The IETF is not the place for this.  Start with ABA, or a similar
legal-focused entity.


Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27585 for <[e-mail]>; Tue, 12 Sep 2000 11:18:10 -0700 (PDT)
From: [e-mail]
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA86448; Tue, 12 Sep 2000 14:19:51 -0400
Received: from D51MTA04.pok.ibm.com (d51mta04.pok.ibm.com [9.117.200.32]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.93) with SMTP id OAA70902; Tue, 12 Sep 2000 14:20:05 -0400
Received: by D51MTA04.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256958.0064B296 ; Tue, 12 Sep 2000 14:19:53 -0400
X-Lotus-FromDomain: IBMUS
To: Stephen Kent <[e-mail]>
cc: "todd glassey" <[e-mail]>, [e-mail], "J Adrian Pickering" <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 12 Sep 2000 14:19:47 -0400
Subject: Re: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     While I do not see any real point to assigning a PKIX-specific OID for
existing crypto algorithms, IMO a relatively severe difficulty in
interpreting some of our formats for newbies is the absence of a real
repository for existing OID's, especially those with cryptographic uses.
The best repository I am aware of is
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg.  Should PKIX publish
something like this (with more documentation) on its own, or simply link to
Peter's?

          Tom Gindin

Stephen Kent <[e-mail]> on 09/11/2000 07:12:17 PM

To:   "todd glassey" <[e-mail]>
cc:   <[e-mail]>, "J Adrian Pickering" <[e-mail]>
Subject:  Re: TS TOKEN TYPES - Re: CMC issues, TSP hashes -



Todd,

>Hi all -
>
>----- Original Message -----
>From: "J Adrian Pickering" <[e-mail]>
>To: <[e-mail]>
>Sent: Wednesday, September 06, 2000 7:57 AM
>Subject: Re: CMC issues, TSP hashes
>
>
>  > At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>  >
>  > >- Use of SHA1 is hard coded in section 5.2. This does not leave the
>  > >standard open for other hash algorithms. Are there any plans to
change
>  > >this?
>  >
>  > This is a problem shared with the TSP Draft also.
>  >
>  > (see posting -
>  > Date: Sat, 02 Sep 2000 17:37:43 +0100
>  > From: J Adrian Pickering <[e-mail]>
>  > Subject: TSP Draft - hash enforcement &c
>  > which is rather lost amongst the OCSP debate!)
>  >
>  > Please can something be done about this for everyone's benefit? My
>  > suggestion is to introduce a PKIX globally available OID
>  > HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier.
This
>  > will enable other hashes to be used where required/wanted. The
overloading
>  > of the AlgorithmIdentifier allows for a parameter which I'm not sure
is
>any
>  > use in the hash arena?
>
>Actually Adrian  your right - but I think we need a little more than this.
>We need an official PKIX OID Tree and it needs to be available.
>
>For each complex data structure or process that can be uniquely identified
>and that would want to be identified, PKIX needs an OID entry in some PKIX
>master OID Table. Hashs, techniques, and maybe even the IOTP Transaction
>types or something like that as well.

I've sent mail to Adrian separately re his concerns over the use of
AlgorithmIdentifier, since I don't appreciate the basis for his
concern. But, as for your suggestion above, I am very much puzzled.
We have access to an OID arc from which various PKIX-specific values
are selected, when needed. Algorithms are NOT PKIX-specific and thus
would not be appropriate for this arc. In generating ASN.1 structures
one makes decisions about when an OID is needed, and when locally
interpreted values suffice. I'm not sure we have a lot of examples
where a knowledgeable ASN.1 author would disagree with the choices we
have made.  Could you be more specific in your suggestions? Cite
examples where we have chosen to not use an OID, and then note
comparable situations in other ASN.1 defined protocols where they
have chosen to use an OID.


<snip>

Steve




Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27526 for <[e-mail]>; Tue, 12 Sep 2000 11:17:55 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id OAA10008; Tue, 12 Sep 2000 14:19:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220811b5e4216f0a23@[171.78.30.107]>
In-Reply-To: <002101c01cde$5a73f480$020aff0c@tsg1>
References: <002101c01cde$5a73f480$020aff0c@tsg1>
Date: Tue, 12 Sep 2000 14:12:50 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The need for two grades of time data.
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1243339590==_ma============"

--============_-1243339590==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>All - I have some concerns with the TSP Draft and one of them that I 
>will break out here is the merging of the concepts that Evidentiary 
>and Policy Grade time sources are identical. They simply are not. 
>There are a number of problems with the concept that instantaneously 
>accurate time data is also provable by itself in the future. Without 
>the proofing model, the value of the time data is that of the 
>weakest link in the system.
>
>The issue is that we use time as content and as a control parameter 
>and it has very different uses and requirements in each. The use of 
>time as evidentiary content, i.e. as in time stamping, is one where 
>the source and viability of the time data is critical and with the 
>current TSP we have chooses for some reason to specifically overlook 
>this.
>
>What I want to do is to start a process of formally defining what an 
>evidentiary grade time source is and what it must conform to.
>
>This in PKIX and will allow us to understand time use models and 
>more adequately define the needs and roles of trusted timing 
>authorities in our larger trust processes.
>
>Does this seem like a win for the group?

As noted in my response to your earlier message, the IETF is an 
international standards organization. The IAB and IESG have 
promulgated position statements on this topic several times. It has 
been most obvious in adopting security standards that conflicted with 
export control rules in several countries.

Looking at this in an international context, and absent a uniform, 
authoritative basis for the sort of time stamp related criteria you 
allude to above, it would seem that this sort of work is not 
consistent with what the IETF does as a standards body.

Steve

--============_-1243339590==_ma============
Content-Type: text/enriched; charset="us-ascii"

Todd,


<excerpt><fontfamily><param>Arial</param>All - I have some concerns
with the TSP Draft and one of them that I will break out here is the
merging of the concepts that Evidentiary and Policy Grade time sources
are identical. They simply are not. There are a number of problems with
the concept that instantaneously accurate time data is also provable by
itself in the future. Without the proofing model, the value of the time
data is that of the weakest link in the system.

 

The issue is that we use time as content and as a control parameter and
it has very different uses and requirements in each. The use of time as
evidentiary content, i.e. as in time stamping, is one where the source
and viability of the time data is critical and with the current TSP we
have chooses for some reason to specifically overlook this.

 

What I want to do is to start a process of formally defining what an
evidentiary grade time source is and what it must conform to.

 

This in PKIX and will allow us to understand time use models and more
adequately define the needs and roles of trusted timing authorities in
our larger trust processes.

 

Does this seem like a win for the group?

</fontfamily></excerpt><fontfamily><param>Arial</param>

</fontfamily>As noted in my response to your earlier message, the IETF
is an international standards organization. The IAB and IESG have
promulgated position statements on this topic several times. It has
been most obvious in adopting security standards that conflicted with
export control rules in several countries. 


Looking at this in an international context, and absent a uniform,
authoritative basis for the sort of time stamp related criteria you
allude to above, it would seem that this sort of work is not consistent
with what the IETF does as a standards body.


Steve

--============_-1243339590==_ma============--


Received: from mail.storm.ca (storm.ca [209.87.239.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27307 for <[e-mail]>; Tue, 12 Sep 2000 11:15:39 -0700 (PDT)
From: [e-mail]
Received: from mailman.endymion.com (mail.storm.ca [209.87.239.69]) by mail.storm.ca (8.9.3+Sun/8.9.3) with SMTP id OAA15580; Tue, 12 Sep 2000 14:17:11 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Fwd: Re: draft-ietf-pkix-time-stamp-09 comments
Date: Tue, 12 Sep 2000 14:17:11 +0000
X-Mailer: Endymion MailMan Standard Edition v3.0.2

Forwarded Message:
> To: Russ Housley <[e-mail]>
> From: Denis Pinkas <[e-mail]>
> Subject: Re: draft-ietf-pkix-time-stamp-09 comments
> Date: Mon, 11 Sep 2000 15:48:13 +0200
> -----
> Russ,
> 
> I have been away from some time and I picked up your message. I fear
> that your message, whatever its content is, has been addressed to
> the wrong mailing list.
> 
> On Monday August 28, the IETF last call was launched by the IESG
> with the following E-mail sent to the PKIX mailing list:
> 
> "The IESG has received a request from the Public-Key Infrastructure
> (X.509) Working Group to consider Internet X.509 Public Key
> Infrastructure Time Stamp Protocols (TSP)
> <draft-ietf-pkix-time-stamp-09.txt> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.  Please send any comments to
> the [e-mail] or [e-mail] mailing lists by September 8,
> 2000."
> 
> So your mail should have been addressed to the [e-mail] or
> [e-mail] mailing lists by September 8, 2000. I hope you did so.
> 
> Denis
> 
>  
> > Here are my comments on draft-ietf-pkix-time-stamp-09.  I have divided them
> > into two categories: technical and editorial.  In my view, the technical
> > changes are needed.  On the other hand, the editorial changes improve
> > readability.
> > 
> > TECHNICAL
> > 
> > Section 2.1, 6th requirement.  I do not understand "hash-function
> > OID."  OIDs, when managed correctly, are collision free.  I think we need
> > to be discussing the one-way hash function, not its OID.  The selected
> > one-way hash function must be uniquely identified by an OID.
> > 
> > Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says
> > that the client SHOULD make the check, but that the client MAY elect to
> > skip the check.  The checking requirement is either a SHOULD or a MAY, it
> > cannot be both.
> > 
> > Section 2.4.1, reqPolicy Discussion.  I do not think that a reference to
> > RFC 2459 is adequate.  First, I do not believe that a certification policy
> > and a TSA policy are equivalent.  At a minimum, the TSA Policy and TSA
> > Practice Statement will have significantly different content.  These
> > differences need to be discussed.  Second, I would prefer syntax without
> > qualifiers.  What value do they add in the TSA context?
> > 
> > Section 2.4.1, nonce Discussion.  Please replace "shall" with "MUST."
> > 
> > Section 2.4.2, 3rd paragraph.  The text does not match the comments in the
> > ASN.1 structure.  I assume that the comments are correct.  Please
> > rewrite.  I suggest:
> >         "When status contains the value zero or one, a Time Stamp Token
> >         MUST be present.  When status contains a value other than zero or
> >         one, a Time Stamp Token MUST NOT be present.  One of the following
> >         values MUST be contained in status:"
> > 
> > Section 2.4.2, 11th paragraph (counting paragraphs is difficult since the
> > ASN.1 fragments are not indented).   Please replace "shall" with "MUST."
> > 
> > Section 2.4.2, serialNumber Discussion.  Please reword the last sentence to
> > include a MUST.  I suggest: "This property MUST be preserved even after an
> > interruption in service (e.g. crash)."
> > 
> > Section 2.4.2, genTime Discussion.  Please replace "shall" with
> > "MUST."  There are at least five occurances.
> > 
> > Section 3.1.  How does the MIME type distinguish a time stamp request from
> > a time stamp token?  The recipient must either decode a TimeStampReq or a
> > ContentInfo, and this does not provide enough information to determine
> > which operation to perform.
> > 
> > Section 3.2.  It would be helpful to specify file extensions for a time
> > stamp request and a time stamp token.  Such extensions would permit the
> > recipient to determine which decode to perform.
> > 
> > Section 3.3.  It would be useful to implementors to include the state
> > machine for the TCP-based protocol.
> > 
> > Section 3.4.  How does the MIME type distinguish a time stamp request from
> > a time stamp token?  The recipient must either decode a TimeStampReq or a
> > ContentInfo, and this does not provide enough information to determine
> > which operation to perform.
> > 
> > Section 4, item 4.  Each of the transports specified has different delay
> > characteristics.  This should be pointed out.
> > 
> > EDITORIAL
> > 
> > Whole document.  Either add "SHALL" to the list of words that you say are
> > defined in RFC 2119, or change "SHALL" to "MUST."
> > 
> > Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the second to
> > last sentence.  It should say: "For more details about replay attack
> > detection, see the security considerations section (item 6)."
> > 
> > Section 2.4.1, MessageImprint Definition.  I suggest the replacement of
> > "hashedMessage" with "MessageHash."  To me, the current name implies the
> > full message text rather than a hash of the message text.
> > 
> > Section 2.4.1, certReq Disscussion.  Typo.  Please move the comma.  The
> > sentence should read: "If the certReq field is missing or if the certReq
> > field is present and set to false, then ..."
> > 
> > Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the registry calls
> > this OID id-ct-TSTInfo. Second, I think that it would be more readable to
> > define it as follows:
> >         id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
> >                  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
> > 
> > Section 2.4.2, genTime Discussion.  Some require course granularity, others
> > require fine granularity.  I suggest that a TSA MUST offer at least 1
> > second granularity.  Filling in the genTime structure with "00" as the
> > seconds does not meet this requirement.
> > 
> > Section 2.4.2, accuracy Discussion.  I think that a bit more discussion is
> > needed.  the syntax permits the seconds and micros fields to be present and
> > the millis to be absent.  I am not sure how to add and subtract such a
> > structure.
> > 
> > Section 2.4.2, ordering Discussion.  Please replace the last sentence with:
> > "... TSA can always be ordered based on the genTime field, regardless of
> > the genTime accuracy.
> > 
> > Section 2.4.2, tsa Discussion.  Please change "an hint" to "a hint."
> > 
> > Section 4, item 6.  Please change "(algorithm and)" to "algorithm and."
> > 
> > Appendix A.  First, the registry calls this OID id-aa-timeStampToken.
> > Second, I think that it would be more readable to define it as follows:
> >         id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> >                 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 
14 }
> 




Received: from mail.storm.ca (storm.ca [209.87.239.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26717 for <[e-mail]>; Tue, 12 Sep 2000 10:47:45 -0700 (PDT)
From: [e-mail]
Received: from mailman.endymion.com (mail.storm.ca [209.87.239.69]) by mail.storm.ca (8.9.3+Sun/8.9.3) with SMTP id NAA11299; Tue, 12 Sep 2000 13:49:13 -0400 (EDT)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Fwd: Re: draft-ietf-pkix-time-stamp-09 comments
Date: Tue, 12 Sep 2000 13:49:13 +0000
X-Mailer: Endymion MailMan Standard Edition v3.0.2

Forwarded Message:
> To: Peter Sylvester <[e-mail]>
> From: Russ Housley <[e-mail]>
> Subject: Re: draft-ietf-pkix-time-stamp-09 comments
> Date: Fri, 08 Sep 2000 14:46:21 -0400
> -----
> Peter:
> 
> >- The draft references a non-existing or not-yet-existing feature
> >   in 'son of 2459'. Is this allowed in a proposed standard?
> >   I have asked that question a week ago to the iesg (no answer so far).
> 
> My understanding is that the time stamp document could not be published as 
> an RFC until the son-of-RFC 2459 was also published.  They would come out 
> together.
> 
> >- Should the security section mention the case of an active
> >   attacker intercepts a response and provokes a network error
> >   to the client, thus the attacker may later have
> >   'earlier evidence' (whatever that would mean). Or, there
> >   is no discussion at all about whether it is necessary to
> >   authenticate the TSA, or about confidentiality.
> 
> This is a reasonable thing to include.
> 
> Russ
> 
> 




Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26108 for <[e-mail]>; Tue, 12 Sep 2000 10:23:49 -0700 (PDT)
Received: from tsg1 ([12.72.1.157]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000912172526.BZOB6605.mtiwmhc25.worldnet.att.net@tsg1> for <[e-mail]>; Tue, 12 Sep 2000 17:25:26 +0000
Message-ID: <002101c01cde$5a73f480$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Subject: The need for two grades of time data.
Date: Tue, 12 Sep 2000 10:24:47 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C01CA3.AD57BFF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C01CA3.AD57BFF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All - I have some concerns with the TSP Draft and one of them that I =
will break out here is the merging of the concepts that Evidentiary and =
Policy Grade time sources are identical. They simply are not. There are =
a number of problems with the concept that instantaneously accurate time =
data is also provable by itself in the future. Without the proofing =
model, the value of the time data is that of the weakest link in the =
system.

The issue is that we use time as content and as a control parameter and =
it has very different uses and requirements in each. The use of time as =
evidentiary content, i.e. as in time stamping, is one where the source =
and viability of the time data is critical and with the current TSP we =
have chooses for some reason to specifically overlook this.

What I want to do is to start a process of formally defining what an =
evidentiary grade time source is and what it must conform to.=20

This in PKIX and will allow us to understand time use models and more =
adequately define the needs and roles of trusted timing authorities in =
our larger trust processes.

Does this seem like a win for the group?

Todd Glassey=20

------=_NextPart_000_001E_01C01CA3.AD57BFF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c8e0d8>
<DIV><FONT face=3DArial size=3D2>All - I have some concerns with the TSP =
Draft and=20
one of them that I will break out here is the merging of the concepts =
that=20
Evidentiary and Policy Grade time sources are identical. They simply are =
not.=20
There are a number of problems with the concept that instantaneously =
accurate=20
time data is also provable by itself in the future. Without the proofing =
model,=20
the value of the time data is that of the weakest link in the=20
system.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The issue is that we use time as =
content and as a=20
control parameter and it has very different uses and requirements in =
each. The=20
use of time as evidentiary content, i.e. as in time stamping, is one =
where the=20
source and viability of the time data is critical and with the current =
TSP we=20
have chooses for some reason to specifically overlook this.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>What I want to do is to start a process =
of formally=20
defining what an evidentiary grade time source is and what it must =
conform to.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This in PKIX and will allow us to =
understand time=20
use models and more adequately define the needs and roles of trusted =
timing=20
authorities in our larger trust processes.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Does this seem like a win for the=20
group?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Todd Glassey =
</FONT></DIV></BODY></HTML>

------=_NextPart_000_001E_01C01CA3.AD57BFF0--



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21015 for <[e-mail]>; Tue, 12 Sep 2000 08:38:20 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA14754; Tue, 12 Sep 2000 11:40:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220805b5e3f262fc32@[171.78.30.107]>
In-Reply-To: <001d01c01c49$3bf3fd10$020aff0c@tsg1>
References:  <[e-mail]><006f01c019ac$2f9b7380$ 020aff0c@tsg1> <v04220810b5e2fd870ec2@[171.78.30.107]> <001d01c01c49$3bf3fd10$020aff0c@tsg1>
Date: Tue, 12 Sep 2000 11:40:45 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

><snip>
>
>The problem is that the term Evidence pertains to PROOF and that these
>proofing models are what we are up to is becoming really clear here.

The term "evidence" does pertain to proof, but "proof" has different 
meanings in different contexts. Civil trial evidence rules vary from 
one jurisdiction to another. PKIX is NOT going to wait for these 
rules to become uniform, or cater to different sets of rules. This is 
new legal territory and until there are ample case law precedents 
nobody will really know what will be required.  We can get lots of 
opinions from lawyers, and technologists who think they are lawyers, 
but, none of these opinions are authoritative. So, PKIX will continue 
to focus on the technical aspects of PKI and do the best we can to 
provide a solid technical basis for whatever the legal community may 
choose to adopt.

We've seen dramatically different views of various aspects of NR 
arising in different contexts already, e.g., the German digital 
signature model, vs. the EU directive, etc. We're not changing PKIX 
standards to match any of these models.

><snip>
>  > Note that PKIX has avoided developing standards that are influenced
>  > by the various emerging legal criteria for digital signatures in
>  > different countries, states, etc.
>
>This is becuase PKIX was focusing on the CORE Technologies not the use of
>them. Now that the Core Technologies are done the next step is to put
>together a set of recommended uses for them.

TSP is still a core technology supportive of many uses.

><snip>
>  > >
>  > >Poof! The whole world changes.
>  >
>  > Not really. Many other aspects of the PKIX work address NR, not just
>  > TSP.
>
>Steve I disagree. What they do is to use the term NR to refer to a wrath of
>services that they may offer. But in the context of this group the TERM NR
>went through months of hammering out and still does not mean the same thing
>to everyone here.
>
>what we maybe might look at is definign the NR process a  suite of methods
>to create comparable levels of non-repudiation at the process component
>level, but this is another issue all together.

"Wrath of services?" What dictionary are you using :-)?

You are right that not everyone in the WG agrees on NR definitions 
and mechanisms. But, this is the IETF and we don't require complete 
consensus. However, you could propose a new work item which would try 
to do what you suggest here, i.e., document suites of mechanisms 
that, in concert, provide NR.

>  > We have adopted a consistent approach to this work, as noted
>  > above, which is independent of the vagaries of the legal systems that
>  > are now trying to address these complex issues.
>  >
>  > >
>  > >Now what is important is:
>  > >--------------------------
>  > >             o-    What Evidentiary Standards the model conforms to (US,
>UK,
>  > >who's else?)
>  >
>  > See comments above on technical focus vs. legal focus.  The notion of
>  > tailoring this work to the legal system of any of the above is not
>  > going to happen.
>
>Are you saying this as the group's chair or as a member? I am assuming I
>just annoyed you by bringing this up again. So I am not offended.

I'm speaking as chair in this discussion, but I think the rationale 
for my position on this matter is obvious and consistent.

>
>My feeling is that this take dooms  PKIX in that this is what the inustry
>and the world needs now.

Reasonable men may disagree about what the world needs now, and 
whether a given IETF WG must address that need. (BTW, I thought the 
answer to that question was "love, true love, that's the only thing 
that there's too little of.")

>  > >             o-    How is the quality of the data inside the stamp token
>  > >assured and how its is obtained. (I.e. the chain of custody and audit
>trail,
>  > >and certification process for the data. BTW - This goes back to my
>concept
>  > >of TRUST ANCHORS)
>  >
>  > In developing standards, the IETF often chooses to address parts of a
>  > problem,  rather than all aspects of a problem.
>
>This attitude may only work for low level core components, when you step
>ooutside these domains the requirements change and PKIX is clearly stepping
>into areas that need use models and BCP recommendations.

I agree that it may be appropriate to develop BCPs to complement our 
base standards, once there is enough experience to be able to claim 
that something really is a BEST COMMON PRACTICE. But we are not there 
yet for time stamping, and a BCP follows, usually by some significant 
delay, the publication and adoption of a standard that is employed in 
a BCP. So, the order is first, we adopt a standard such as TSP, then 
we gain experience, then we publish a BCP.

><snip>
>  >
>  > This issue has been addressed on the list, but the document could do
>  > a better job of clarifying the position it takes. Time stamps from a
>  > given TSA are ordered, but there is no guarantee that time stamps
>  > issued by different TSAs are ordered, since different TSAs may employ
>  > different time bases, offer different accuracy guarantees, etc. On
>  > can image various scenarios in which two time stamps, issued by two
>  > TSAs are not comparable. I agree that the document could do a better
>  > job of discussing this issue.
>
>Thanks. But what do you think about the idea of reorientating that document
>so that it has two major sections before it gets advanced.  The TST's and
>their Use Models would be one and the API"s to support them - this would
>involve the addition of the AD section on the use and a number of TST
>models. All in all it could be easily done and then we could all put the
>standard to bed. I

APIs are very separate from protocol standards.  For many years the 
IETF did not consider APIs as subjects for standardization, as they 
are not relevant to external interoperability. We have softened that 
view a bit, but an API is still secondary to the protocol for which 
it is an interface. If there is a demand for development of an API, 
then we can do so as a separate work item, but it in no way is a 
requirement for this document.

>I and the others that are concerned get the evidentiary grades of content we
>want in the timestamps and the rest of the world gets what's alreadyin the
>draft - This is a workable solution I think

I predict that if we were to delay the document to accommodate these 
additional sections, that there would be a long debate over whose use 
models were included, and what API was adopted. The IESG will decide 
whether we need to hold up this document to address the use models 
you want, but my recommendation will be to defer this, and the APIs.

Steve



Received: from logatome.francenet.fr (logatome-2.francenet.fr [193.149.96.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20808 for <[e-mail]>; Tue, 12 Sep 2000 08:36:19 -0700 (PDT)
Received: from certplus.com ([193.149.118.138]) by logatome.francenet.fr (8.10.1/8.10.1) with ESMTP id e8CFcJp23189; Tue, 12 Sep 2000 17:38:23 +0200 (CEST)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 12 Sep 2000 17:39:20 +0200
From: Jean-Marc Desperrier <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], "'[e-mail]'" <[e-mail]>
Subject: Re: Certificate request from P10 to PEM
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Hewitt, Jim" wrote:

> CertCo has a "Swiss Army knife" tool that does this and many related
> operations.  Contact me privately to get a copy.
>
> -----Original Message-----
> From: Steve Wang [mailto:[e-mail]]
> Sent: Monday, September 11, 2000 9:45 AM
> To: [e-mail]
> Subject: Certificate request from P10 to PEM
>
> Are there any tools available to convert a certificate request from P10
> format to PEM format?

OpenSSL does it very well too.

http://www.openssl.org



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA18449 for <[e-mail]>; Tue, 12 Sep 2000 07:47:04 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 7A58015531; Tue, 12 Sep 2000 10:48:37 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 20DD47C0E8; Tue, 12 Sep 2000 10:48:37 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <SCK0R8ZR>; Tue, 12 Sep 2000 10:48:36 -0400
Message-ID: <[e-mail]>
From: "Hewitt, Jim" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Certificate request from P10 to PEM
Date: Tue, 12 Sep 2000 10:48:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

CertCo has a "Swiss Army knife" tool that does this and many related
operations.  Contact me privately to get a copy.

Jim Hewitt
CertCo Inc.
[phone]
[e-mail]

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/


Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17500 for <[e-mail]>; Tue, 12 Sep 2000 07:07:48 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 9393815543; Tue, 12 Sep 2000 10:09:24 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id 319457C0ED; Tue, 12 Sep 2000 10:09:24 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <SCK0R8X3>; Tue, 12 Sep 2000 10:08:42 -0400
Message-ID: <[e-mail]>
From: "Hewitt, Jim" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Certificate request from P10 to PEM
Date: Tue, 12 Sep 2000 10:05:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C01CC2.892BE5C4"

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

------_=_NextPart_000_01C01CC2.892BE5C4
Content-Type: text/plain;
	charset="iso-8859-1"

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/


------_=_NextPart_000_01C01CC2.892BE5C4
Content-Type: application/x-pkcs7-mime;
	name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7m"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEDE1JTUUt
VmVyc2lvbgQCOiAEAzEuMAQCDQoEDENvbnRlbnQtVHlwZQQCOiAECnRleHQvcGxhaW4EBDsNCgkE
B2NoYXJzZXQEAT0EASIECmlzby04ODU5LTEEASIEAg0KBBlDb250ZW50LVRyYW5zZmVyLUVuY29k
aW5nBAI6IAQEN2JpdAQCDQoECVgtTWltZU9MRQQCOiAELVByb2R1Y2VkIEJ5IE1pY3Jvc29mdCBN
aW1lT0xFIFY0LjcyLjM2MTIuMTcwMAQCDQoEAg0KBIICEUNlcnRDbyBoYXMgYSAiU3dpc3MgQXJt
eSBrbmlmZSIgdG9vbCB0aGF0IGRvZXMgdGhpcyBhbmQgbWFueSByZWxhdGVkDQpvcGVyYXRpb25z
LiAgQ29udGFjdCBtZSBwcml2YXRlbHkgdG8gZ2V0IGEgY29weS4NCg0KSmltIEhld2l0dA0KQ2Vy
dENvIEluYy4NCisxIDYxNyA0OTIgMTAxNA0KaGV3aXR0akBjZXJ0Y28uY29tDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGV2ZSBXYW5nIFttYWlsdG86c3RldmUud2FuZ0Bl
bnRlZ3JpdHkuY29tXSANClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDExLCAyMDAwIDk6NDUgQU0N
ClRvOiBpZXRmLXBraXhAaW1jLm9yZw0KU3ViamVjdDogQ2VydGlmaWNhdGUgcmVxdWVzdCBmcm9t
IFAxMCB0byBQRU0NCg0KDQpIZWxsbywgdGhlcmUsDQoNCkFyZSB0aGVyZSBhbnkgdG9vbHMgYXZh
aWxhYmxlIHRvIGNvbnZlcnQgYSBjZXJ0aWZpY2F0ZSByZXF1ZXN0IGZyb20gUDEwDQpmb3JtYXQg
dG8gUEVNIGZvcm1hdD8NCg0KVGhhbmsgeW91IGluIGFkdmFuY2UuDQoNClN0ZXZlDQoEAAAAAAAA
AKCCBawwggJwMIIBWKADAgECAgQ5eMKfMA0GCSqGSIb3DQEBBQUAMCsxCzAJBgNVBAYTAlVTMQ0w
CwYDVQQKEwRCaWtlMQ0wCwYDVQQDEwRSb290MB4XDTAwMDcyMTIxMzczNVoXDTAxMDcyMTE2Mzcz
NVowRjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkNlcnRDbzELMAkGA1UECxMCQ1MxGTAXBgNVBAMT
EERhd24ncyBDb29sIE1TQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEA+y5Axsb3lHD9r55HrFRs
XVO1OsOGJmGalj6iY1UMM4bVUjMbNTkrEbIK9Fld191CSMthDY3phXk11WaudQSG9QIDAQABo0kw
RzAOBgNVHQ8BAf8EBAMCAf4wKgYIKwYBBQUHAQEEHjAcMBoGCCsGAQUFBzABhg5odHRwOi8vZmF0
Y2l0eTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUAA4IBAQBTiAO2Hk2a7tCln1okiG+CJNkuyGMy
MFid9QJjFqVJo0GOa0JJdXxBrjq+VN0hUn8miOBYiI12qJICAz7rrfwdbfSYmAeTh957HYUWrcF/
yz4obMh0hMGYXI/FvD/lZ3+zt4qNNrFxgScAY7kalqSurtu1AFJJw+cn3+ZpvCnTby2Slx345Gz3
IE9nxedK0zbEh4n3y4Eb0jt+hTdxAf+0LORO/KCvdR7VC3tveNNHD01OkpJXU0a1tATyO1bJXtTT
ZLRA8YDBRqiZLMKwsHIKY2cYG+drWn4FPUoaPWjYL3Ti0SuIy3EC5TSedi1Vn4V/P0sjoNGEpLks
RA9DDsGOMIIDNDCCAt6gAwIBAgIIICkfRwAAAAQwDQYJKoZIhvcNAQEEBQAwRjELMAkGA1UEBhMC
VVMxDzANBgNVBAoTBkNlcnRDbzELMAkGA1UECxMCQ1MxGTAXBgNVBAMTEERhd24ncyBDb29sIE1T
Q0EwHhcNMDAwODI1MTMzMDQyWhcNMDEwNzIxMTYzNzM1WjCBjDEhMB8GCSqGSIb3DQEJARYSaGV3
aXR0akBjZXJ0Y28uY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUExEjAQBgNVBAcTCUNhbWJy
aWRnZTEPMA0GA1UEChMGQ2VydENvMRMwEQYDVQQLEwpDb25zdWx0aW5nMRMwEQYDVQQDEwpKaW0g
SGV3aXR0MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAN4ibS1zruIXVmIKaeqq3ku2ymixG14oqGaK
Jw8iFknsPGApNnU1RUrrjmjvHdRe14mvEW6AyhJWLN2w4ohBzyMCAwEAAaOCAWcwggFjMAsGA1Ud
DwQEAwIAuDATBgNVHSUEDDAKBggrBgEFBQcDBDBWBgNVHSMETzBNgBQ5XMHoRL11uk9TKuDtm9dw
8FAD2KEvpC0wKzELMAkGA1UEBhMCVVMxDTALBgNVBAoTBEJpa2UxDTALBgNVBAMTBFJvb3SCBDl4
wp8wgYMGA1UdHwR8MHowOqA4oDaGNGh0dHA6Ly9UT0tZTy9DZXJ0U3J2L0NlcnRFbnJvbGwvRGF3
bidzIENvb2wgTVNDQS5jcmwwPKA6oDiGNmZpbGU6Ly9cXFRPS1lPXENlcnRTcnZcQ2VydEVucm9s
bFxEYXduJ3MgQ29vbCBNU0NBLmNybDAJBgNVHRMEAjAAMFYGCCsGAQUFBwEBBEowSDBGBggrBgEF
BQcwAoY6aHR0cDovL1RPS1lPL0NlcnRTcnYvQ2VydEVucm9sbC9UT0tZT19EYXduJ3MgQ29vbCBN
U0NBLmNydDANBgkqhkiG9w0BAQQFAANBAKsTtMgzHjXj1kF+7ABvT2df0rb/ML5pbGqlCRl9LAiU
xsr8AJHoKucy0KSHS6aHBJVgRqjhmzzoquSSDBqj8doxggGvMIIBqwIBATBSMEYxCzAJBgNVBAYT
AlVTMQ8wDQYDVQQKEwZDZXJ0Q28xCzAJBgNVBAsTAkNTMRkwFwYDVQQDExBEYXduJ3MgQ29vbCBN
U0NBAgggKR9HAAAABDAJBgUrDgMCGgUAoIH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTAwMDkxMjAyNTgyN1owIwYJKoZIhvcNAQkEMRYEFKdjalnOzbv8Iy2aX+qn
ul93UtJEMDMGCSqGSIb3DQEJDzEmMCQwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcN
AgUwYQYJKwYBBAGCNxAEMVQwUjBGMQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQ2VydENvMQswCQYD
VQQLEwJDUzEZMBcGA1UEAxMQRGF3bidzIENvb2wgTVNDQQIIICkfRwAAAAQwDQYJKoZIhvcNAQEB
BQAEQE+zAMusxPYVL0MT9ZtkSB8sUenqd3M/GX127PLmvHLTSZHqC3FprwRG4vWmFLsmNtQkktKH
N2axJVrVSsn1TX4AAAAAAAA=

------_=_NextPart_000_01C01CC2.892BE5C4--


Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15859 for <[e-mail]>; Tue, 12 Sep 2000 06:02:25 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id IAA12596 for <[e-mail]>; Tue, 12 Sep 2000 08:48:59 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Tue, 12 Sep 2000 08:58:50 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Client-side revocation checking capability
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: biWl0/4swXA8PtTq6tGYPg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Bob Jueneman" <[e-mail]>
> 
> I do like Bob Moskowitz's solution, and hadn't heard of it -- pass a 
> current CRL along with the TLS certificate chain, and make sure that the 
> CRL is nearly always empty, so that an excessive amount of time
> is not consumed in validating the certificate chain.  Do you know where
> that approach stands in the standards track for TSL?

Bob proposed it here on Sept 1 in conjunction with IPsec.
No specific mechanism has yet been proposed for TLS, but there
is current discussion of defining a protocol extension mechanism.
Once extensions have gelled, it would be appropriate to define a
CRL request extension with the server CRL in the response.

An alternative would be to modify the existing TLS certificate list
to include CRLs, but that is less desirable assuming extensions happen.



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12783 for <[e-mail]>; Tue, 12 Sep 2000 03:48:53 -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 GAA28759; Tue, 12 Sep 2000 06:50:58 -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-ldap-schema-01.txt
Date: Tue, 12 Sep 2000 06:50:58 -0400
Sender: [e-mail]

--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 Additional 
                          LDAP Schema for PKIs and PMIs
	Author(s)	: D. Chadwick, S. Legg
	Filename	: draft-ietf-pkix-ldap-schema-01.txt
	Pages		: 19
	Date		: 11-Sep-00
	
This document describes LDAP schema features in addition to RFC 2587 
that are needed to support a Privilege Management Infrastructure and 
a Public Key Infrastructure.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-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-ldap-schema-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-ldap-schema-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-ldap-schema-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ldap-schema-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 smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27790 for <[e-mail]>; Mon, 11 Sep 2000 17:21:14 -0700 (PDT)
Received: from 208-58-196-162.s416.tnt10.lnhva.md.dialup.rcn.com ([208.58.196.162] helo=rankney) by smtp01.mrf.mail.rcn.net with smtp (Exim 3.15 #2) id 13Ydr1-0007Nv-00; Mon, 11 Sep 2000 20:23:16 -0400
Message-ID: <002301c01c4f$cd0317e0$a2c43ad0@rankney>
From: "Rich Ankney" <[e-mail]>
To: "Bob Jueneman" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
Date: Mon, 11 Sep 2000 20:24:20 -0400
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.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0

Bob,

The current idea is to have OIDs for SHA-256, SHA-512, and SHA-384
(truncated SHA-512).  At least in X9; your comments (and anone else's)
are appreciated.  I know nothing else about these algorithms except the
following: SHA-x (with x >= 256) is not backward with SHA-1, i.e. you
can't truncate a SHA-256 or whatever to SHA-160-bits.  So they are
not doing the obvious (SHA-Y with Y > X in SHA-X being some sort of
iteration of the same function with different IVs).  Of course that's
obviously
only 160 bits strong, so never mind.

This is an area where you have lots of expertsise; I'd be interested in your
ideas (remembering the real version will be distributed to X9 in the next
few weeks, and I'll do my best to leak it to PKIX ASAP).

Best,
Rich

-----Original Message-----
From: Bob Jueneman <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>; [e-mail]
<[e-mail]>
Date: Monday, September 11, 2000 6:31 PM
Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -


>In this regard, I was interested to hear on the Federal PKI TWG list that
NIST
>is considering releasing a SHA-256 and SHA-512 hash algorithm.
>
>No new algorithms will be forthcoming -- the only question is whether to
>bundle them with the conventional signature OID, or to separate them out.
>
>Bundling them makes them somewhat harder to change, but on the other hand,
>allowing complete freedom to choose the signing algorithm independently
tends to
>raise issue of N-squared combinations that have to be tested.
>
>Some combinations might not even make technical sense -- for example
200-bit
>elliptic curve DSA with SHA-512, since the hash function wouldn't fit
within the
>signature result.
>
>On balance, and noting the generally poor track record we have in limiting
>combinations of things to stable profiles, I am inclined to continue the
practice of
>specifying the signature algorithm and the hash algorithm as one joint
specification.
>
>Bob
>
>>>> "todd glassey" <[e-mail]> 09/11/00 01:06PM >>>
>Hi all -
>
>----- Original Message -----
>From: "J Adrian Pickering" <[e-mail]>
>To: <[e-mail]>
>Sent: Wednesday, September 06, 2000 7:57 AM
>Subject: Re: CMC issues, TSP hashes
>
>
>> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>>
>> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
>> >standard open for other hash algorithms. Are there any plans to change
>> >this?
>>
>> This is a problem shared with the TSP Draft also.
>>
>> (see posting -
>> Date: Sat, 02 Sep 2000 17:37:43 +0100
>> From: J Adrian Pickering <[e-mail]>
>> Subject: TSP Draft - hash enforcement &c
>> which is rather lost amongst the OCSP debate!)
>>
>> Please can something be done about this for everyone's benefit? My
>> suggestion is to introduce a PKIX globally available OID
>> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
>> will enable other hashes to be used where required/wanted. The
overloading
>> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
>any
>> use in the hash arena?
>
>Actually Adrian  your right - but I think we need a little more than this.
>We need an official PKIX OID Tree and it needs to be available.
>
>For each complex data structure or process that can be uniquely identified
>and that would want to be identified, PKIX needs an OID entry in some PKIX
>master OID Table. Hash's, techniques, and maybe even the IOTP Transaction
>types or something like that as well.
>
>>
>> Russ Housley appears to agree: "The selected one-way hash function must
be
>> uniquely identified by an OID."
>>
>> I'd still rather have the TSA autonomously stamp an octet string and
leave
>> the client to decide what it all means.
>
>We are confusing the term "Client" here for the term "USER OF"... and this
>is an important concept in understanding what we are really talking about.
>
>The key issue is whether the time stamp is used to control some other
>external process, almost analogous to dropping a coin into a vending
>machine,
>or whether it is standing as evidentiary testimony to some event. As it
>happens the Coin does both, but generally the mindset about how the TSP has
>been thought about is form using time as a control parameter rather than an
>evidentiary one. By the way - We generally as a group seem to assume
>automatically between 'using data elements for control' rather than  'for
>content'.
>
>In one case they are used to control the infrastructure or policy
>like a signal, and on the other they are used to stand audit. The uses of
>the same parametric data elements here are very different and have
different
>needs to support their respective end use models.
>
>> What business is it of the TSA to
>> know what it is stamping (semantically or syntactically)?
>
>Depends on what the purpose of the TSA is. If there is a conveyance in a
>legal sense of Agency, then the TSA may have legally binding reasons for
>being able to identify the type of content it is stamping. Maybe to the
>granularity of needing to parse the file first to determine its data type.
>
>.. and this leads us to the fact that a HASH in and of itself as a
>timestamping record is very difficult to use from an end user model. What
>the TST should be is a framework or harness itself and internally it should
>represent a number of events interchangeably. There would need to be
>different grades of Tokens with varying levels of overhead for their
>management, and the approriate BCP to match.
>
>But realize that in no uncertain terms what we are sitting on is  the
>designing of the Global Mint here.
>
>"The real end user goal is a simple bolt-on system that allows end users
to,
>with the transaction infrastructure they have today,  add non-repudiation
>at a commercial level to their process, and  at a scaleable and reasonable
>overhead."
>
>Simple to say, not so simple to do as there are so many different
>transaction
>processing systems in the world today, but the common elements in all of
>them is that they have some DB system that they are layered on and an OS
>under that of some sort.
>
>With that being the key the DB that is, doesn't the idea of a common binary
>data structure that is a timestamp token appeal to you (represented in the
>cyber world as ASN.1 if you want) . We can build an TST Binary to XML
>presentation system and absorb or bridge the IOTP/XML Receipt efforts at
>some level into the PKIX Timestamping systems  and deliver evidentiary
grade
>standards for representing events in time and space. YOW - look at the
>potential
>there!!!.
>
>These tokens and their respective API's will be able to specify its level
of
>trust, the event it marks and the data components that make up that event,
>and the rules of processing the token. If a lighter token is necessary
>portions of the system can be replaced by OIDS on as "as many as possible"
>basis based in the OID tree idea (see above). More risk mitigated
>transactions may require self authenticating tokens as well and we should
>provide for these at the high end of the API.
>
>Poof - Instant transaction systems. I think that this is what DigiCash and
>most all of the other token based transactor companies tried to do but they
>were too far ahead of the curve to get real traction - and as scary as it
>sounds, PKIX is in the perfect position to make this fly now.
>
>BTW, in and of itself is reason for not advancing the TPS Draft.
>
>>
>> Adrian Pickering/
>> Electronics and Computer Science
>> University of Southampton
>> UK
>>
>>
>
>



Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27083 for <[e-mail]>; Mon, 11 Sep 2000 16:36:28 -0700 (PDT)
Received: from tsg1 ([12.72.64.169]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000911233754.NNHA2687.mtiwmhc23.worldnet.att.net@tsg1>; Mon, 11 Sep 2000 23:37:54 +0000
Message-ID: <001d01c01c49$3bf3fd10$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><006f01c019ac$2f9b7380$020aff0c@tsg1> <v04220810b5e2fd870ec2@[171.78.30.107]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Date: Mon, 11 Sep 2000 16:37: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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 11, 2000 3:33 PM
Subject: Re: draft-ietf-pkix-time-stamp-09 comments


> Todd,
>
> <snip>
>
> >The TSP is still in and of itself incomplete.
> >------------------------------------------
> >I  am really concerned that significant changes are needed in the TSP
BEFORE
> >it is advanced, and I have already posted to the IESG saying this as well
as
> >the WG Chairs.
> >
> >If it is to be used to create "evidentiary marques" then we had damn well
> >better define what the marques are and how they are used PRIOR to
erecting a
> >standard on the API for how to create them.

The problem is that the term Evidence pertains to PROOF and that these
proofing models are what we are up to is becoming really clear here.

>
> I think your interpretation of the term "evidence" differs from that
> of the authors.  The term appears 5 times in the document, whereas
> the term "evidentiary marques" does not appear at all. So, we're not
> derelict for not defining the latter term :-). PKIX and the PKI
> literature in general has often used "evidence" in an informal way to
> refer to the body of data that supports non repudiation, e.g., certs,
> CRLs, etc.
>
> Note that PKIX has avoided developing standards that are influenced
> by the various emerging legal criteria for digital signatures in
> different countries, states, etc.

This is becuase PKIX was focusing on the CORE Technologies not the use of
them. Now that the Core Technologies are done the next step is to put
together a set of recommended uses for them.

> Note also the long debate over the
> term "non-repudiation" and the creation of an informational document
> on "Technical Non-Repudiation" by Tom Gindin.  So, in this spirit, I
> do not anticipate that PKIX will treat time stamping differently. We
> will focus on technical TSP mechanisms that yield what would be
> considered evidence in the same spirit as CRLs, OCSP responses, etc.
>
> >New Evidentiary Focus
> >------------------------
> >This concern, since the 9.0 draft finally started to talk about
"evidentiary
> >processes" is right on the money. What timestamps are is not simple
> >processes to verify signatures at a specific time, but rather mechanisms
for
> >memorialiing events in time and space as an evidentiary process.
> >
> >Poof! The whole world changes.
>
> Not really. Many other aspects of the PKIX work address NR, not just
> TSP.

Steve I disagree. What they do is to use the term NR to refer to a wrath of
services that they may offer. But in the context of this group the TERM NR
went through months of hammering out and still does not mean the same thing
to everyone here.

what we maybe might look at is definign the NR process a  suite of methods
to create comparable levels of non-repudiation at the process component
level, but this is another issue all together.


> We have adopted a consistent approach to this work, as noted
> above, which is independent of the vagaries of the legal systems that
> are now trying to address these complex issues.
>
> >
> >Now what is important is:
> >--------------------------
> >             o-    What Evidentiary Standards the model conforms to (US,
UK,
> >who's else?)
>
> See comments above on technical focus vs. legal focus.  The notion of
> tailoring this work to the legal system of any of the above is not
> going to happen.

Are you saying this as the group's chair or as a member? I am assuming I
just annoyed you by bringing this up again. So I am not offended.

My feeling is that this take dooms  PKIX in that this is what the inustry
and the world needs now.

>
> >             o-    How is the quality of the data inside the stamp token
> >assured and how its is obtained. (I.e. the chain of custody and audit
trail,
> >and certification process for the data. BTW - This goes back to my
concept
> >of TRUST ANCHORS)
>
> In developing standards, the IETF often chooses to address parts of a
> problem,  rather than all aspects of a problem.

This attitude may only work for low level core components, when you step
ooutside these domains the requirements change and PKIX is clearly stepping
into areas that need use models and BCP recommendations.

> TCP moves data
> without regard for the type of data being transported. In the context
> of TSP, we rely on the users of a TSP to do whatever is necessary to
> achieve the desired evidentiary assurance that is appropriate for
> their environment. Thus, some TSPs may be suitable for some contexts,
> but inadequate for others. This is analogous to asking what
> algorithms and key lengths are necessary to ensure that a digital
> signature is valid for a transactions of a given value.  the answer
> will be context dependent and is outside the scope of our work.
>
> >             o-    The mechanisms through which stamps are made
comparable to
> >each other (and thus made Portable)
>
> This issue has been addressed on the list, but the document could do
> a better job of clarifying the position it takes. Time stamps from a
> given TSA are ordered, but there is no guarantee that time stamps
> issued by different TSAs are ordered, since different TSAs may employ
> different time bases, offer different accuracy guarantees, etc. On
> can image various scenarios in which two time stamps, issued by two
> TSAs are not comparable. I agree that the document could do a better
> job of discussing this issue.

Thanks. But what do you think about the idea of reorientating that document
so that it has two major sections before it gets advanced.  The TST's and
their Use Models would be one and the API"s to support them - this would
involve the addition of the AD section on the use and a number of TST
models. All in all it could be easily done and then we could all put the
standard to bed. I


I and the others that are concerned get the evidentiary grades of content we
want in the timestamps and the rest of the world gets what's alreadyin the
draft - This is a workable solution I think


SNIP -

Todd



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26618 for <[e-mail]>; Mon, 11 Sep 2000 16:12:16 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA03934; Mon, 11 Sep 2000 19:14:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220814b5e313f954c8@[171.78.30.107]>
In-Reply-To: <00e201c01c22$5201a840$020aff0c@tsg1>
References: <[e-mail]> <00e201c01c22$5201a840$020aff0c@tsg1>
Date: Mon, 11 Sep 2000 19:12:17 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
Cc: <[e-mail]>, "J Adrian Pickering" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Hi all -
>
>----- Original Message -----
>From: "J Adrian Pickering" <[e-mail]>
>To: <[e-mail]>
>Sent: Wednesday, September 06, 2000 7:57 AM
>Subject: Re: CMC issues, TSP hashes
>
>
>  > At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>  >
>  > >- Use of SHA1 is hard coded in section 5.2. This does not leave the
>  > >standard open for other hash algorithms. Are there any plans to change
>  > >this?
>  >
>  > This is a problem shared with the TSP Draft also.
>  >
>  > (see posting -
>  > Date: Sat, 02 Sep 2000 17:37:43 +0100
>  > From: J Adrian Pickering <[e-mail]>
>  > Subject: TSP Draft - hash enforcement &c
>  > which is rather lost amongst the OCSP debate!)
>  >
>  > Please can something be done about this for everyone's benefit? My
>  > suggestion is to introduce a PKIX globally available OID
>  > HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
>  > will enable other hashes to be used where required/wanted. The overloading
>  > of the AlgorithmIdentifier allows for a parameter which I'm not sure is
>any
>  > use in the hash arena?
>
>Actually Adrian  your right - but I think we need a little more than this.
>We need an official PKIX OID Tree and it needs to be available.
>
>For each complex data structure or process that can be uniquely identified
>and that would want to be identified, PKIX needs an OID entry in some PKIX
>master OID Table. Hashs, techniques, and maybe even the IOTP Transaction
>types or something like that as well.

I've sent mail to Adrian separately re his concerns over the use of 
AlgorithmIdentifier, since I don't appreciate the basis for his 
concern. But, as for your suggestion above, I am very much puzzled. 
We have access to an OID arc from which various PKIX-specific values 
are selected, when needed. Algorithms are NOT PKIX-specific and thus 
would not be appropriate for this arc. In generating ASN.1 structures 
one makes decisions about when an OID is needed, and when locally 
interpreted values suffice. I'm not sure we have a lot of examples 
where a knowledgeable ASN.1 author would disagree with the choices we 
have made.  Could you be more specific in your suggestions? Cite 
examples where we have chosen to not use an OID, and then note 
comparable situations in other ASN.1 defined protocols where they 
have chosen to use an OID.


<snip>

Steve



Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26322 for <[e-mail]>; Mon, 11 Sep 2000 16:02:33 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA03424; Mon, 11 Sep 2000 19:04:35 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220812b5e3119dc6f6@[171.78.30.107]>
In-Reply-To: <005201c01c05$30876e10$020aff0c@tsg1>
References: <005201c01c05$30876e10$020aff0c@tsg1>
Date: Mon, 11 Sep 2000 18:56:50 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Proposed Charter Amendment...
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1243408913==_ma============"

--============_-1243408913==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

>Gentlefolk -
>
>A year or so ago I brought up the concept that PKIX Standards and 
>RFC's were different than many of the other standards that the IETF 
>was producing in that many of them would be concerned with end-user 
>processes and requirements. Because of this I am proposing (again) 
>to set an additional requirement that ALL RFC's in PKIX that are to 
>be advanced to STANDARDS have an associated Applicability Document 
>(AD) and that no standard effort will be allowed to proceed past RFC 
>without one.

Why would one declare this to be a requirement for PKIX documents, 
but not for all other IETF RFCs? It is the nature of many RFCs that 
they provide infrastructure elements upon which many different 
applications are built.  When TCP and IP were devised 25 years ago, 
there was no appreciation for the very wide range of applications 
that would be making use of these protocols today. If we're lucky, 
the same will be true of the PKIX RFCs.

>  This  requirement is needed for a number of reasons not the least 
>of them being that other standards orgs need to use this material as 
>a basis of their efforts (the IETF being one of the lowest links on 
>the Standard's Food Chain.

I'm sure this was meant as a compliment, said the co-chair of the 
bacteria standards committee :-).

>  My belief is that this is critically true of a number of the 
>efforts currently underway, like the TSP and OCSP protocol efforts. 
>Anyway - the current charter is included below for reference as well 
>as the proposed amendment to paragraph two.

I think Russ's reply is accurate, i.e., each I-D contains an 
introduction section and we judge each document in terms of the 
adequacy of all of its parts.  I'm not saying that we could not do 
better, but I do not think a separate AD is required.

Your proposed rewording of the charter is consistent with your 
earlier message about wanting to transform our standards process to 
more directly support the use of PKI in various business models. But, 
that's not what we do. Again, I refer to the NR debates we have had 
and the distinction we chose to make between technical NR and legal 
NR, as detailed in Tom's document.

Steve

--============_-1243408913==_ma============
Content-Type: text/enriched; charset="us-ascii"

Todd,


<excerpt><fontfamily><param>Arial</param>Gentlefolk -

 

A year or so ago I brought up the concept that PKIX Standards and RFC's
were different than many of the other standards that the IETF was
producing in that many of them would be concerned with end-user
processes and requirements. Because of this I am proposing (again) to
set an additional requirement that ALL RFC's in PKIX that are to be
advanced to STANDARDS have an associated Applicability Document (AD)
and that no standard effort will be allowed to proceed past RFC without
one.

</fontfamily></excerpt><fontfamily><param>Arial</param>

</fontfamily>Why would one declare this to be a requirement for PKIX
documents, but not for all other IETF RFCs? It is the nature of many
RFCs that they provide infrastructure elements upon which many
different applications are built.  When TCP and IP were devised 25
years ago, there was no appreciation for the very wide range of
applications that would be making use of these protocols today. If
we're lucky, the same will be true of the PKIX RFCs.


<excerpt> <fontfamily><param>Arial</param>This  requirement is needed
for a number of reasons not the least of them being that other
standards orgs need to use this material as a basis of their efforts
(the IETF being one of the lowest links on the Standard's Food Chain.

</fontfamily></excerpt><fontfamily><param>Arial</param>

</fontfamily>I'm sure this was meant as a compliment, said the co-chair
of the bacteria standards committee :-).


<excerpt> <fontfamily><param>Arial</param>My belief is that this is
critically true of a number of the efforts currently underway, like the
TSP and OCSP protocol efforts. Anyway - the current charter is included
below for reference as well as the proposed amendment to paragraph
two.

</fontfamily></excerpt><fontfamily><param>Arial</param>

</fontfamily>I think Russ's reply is accurate, i.e., each I-D contains
an introduction section and we judge each document in terms of the
adequacy of all of its parts.  I'm not saying that we could not do
better, but I do not think a separate AD is required.


Your proposed rewording of the charter is consistent with your earlier
message about wanting to transform our standards process to more
directly support the use of PKI in various business models. But, that's
not what we do. Again, I refer to the NR debates we have had and the
distinction we chose to make between technical NR and legal NR, as
detailed in Tom's document.


Steve

--============_-1243408913==_ma============--


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25775 for <[e-mail]>; Mon, 11 Sep 2000 15:32:28 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA01188; Mon, 11 Sep 2000 18:34:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220810b5e2fd870ec2@[171.78.30.107]>
In-Reply-To: <006f01c019ac$2f9b7380$020aff0c@tsg1>
References: <[e-mail]> <006f01c019ac$2f9b7380$020aff0c@tsg1>
Date: Mon, 11 Sep 2000 18:33:29 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Todd,

<snip>

>The TSP is still in and of itself incomplete.
>------------------------------------------
>I  am really concerned that significant changes are needed in the TSP BEFORE
>it is advanced, and I have already posted to the IESG saying this as well as
>the WG Chairs.
>
>If it is to be used to create "evidentiary marques" then we had damn well
>better define what the marques are and how they are used PRIOR to erecting a
>standard on the API for how to create them.

I think your interpretation of the term "evidence" differs from that 
of the authors.  The term appears 5 times in the document, whereas 
the term "evidentiary marques" does not appear at all. So, we're not 
derelict for not defining the latter term :-). PKIX and the PKI 
literature in general has often used "evidence" in an informal way to 
refer to the body of data that supports non repudiation, e.g., certs, 
CRLs, etc.

Note that PKIX has avoided developing standards that are influenced 
by the various emerging legal criteria for digital signatures in 
different countries, states, etc. Note also the long debate over the 
term "non-repudiation" and the creation of an informational document 
on "Technical Non-Repudiation" by Tom Gindin.  So, in this spirit, I 
do not anticipate that PKIX will treat time stamping differently. We 
will focus on technical TSP mechanisms that yield what would be 
considered evidence in the same spirit as CRLs, OCSP responses, etc.

>New Evidentiary Focus
>------------------------
>This concern, since the 9.0 draft finally started to talk about "evidentiary
>processes" is right on the money. What timestamps are is not simple
>processes to verify signatures at a specific time, but rather mechanisms for
>memorialiing events in time and space as an evidentiary process.
>
>Poof! The whole world changes.

Not really. Many other aspects of the PKIX work address NR, not just 
TSP. We have adopted a consistent approach to this work, as noted 
above, which is independent of the vagaries of the legal systems that 
are now trying to address these complex issues.

>
>Now what is important is:
>--------------------------
>             o-    What Evidentiary Standards the model conforms to (US, UK,
>who's else?)

See comments above on technical focus vs. legal focus.  The notion of 
tailoring this work to the legal system of any of the above is not 
going to happen.

>             o-    How is the quality of the data inside the stamp token
>assured and how its is obtained. (I.e. the chain of custody and audit trail,
>and certification process for the data. BTW - This goes back to my concept
>of TRUST ANCHORS)

In developing standards, the IETF often chooses to address parts of a 
problem,  rather than all aspects of a problem. TCP moves data 
without regard for the type of data being transported. In the context 
of TSP, we rely on the users of a TSP to do whatever is necessary to 
achieve the desired evidentiary assurance that is appropriate for 
their environment. Thus, some TSPs may be suitable for some contexts, 
but inadequate for others. This is analogous to asking what 
algorithms and key lengths are necessary to ensure that a digital 
signature is valid for a transactions of a given value.  the answer 
will be context dependent and is outside the scope of our work.

>             o-    The mechanisms through which stamps are made comparable to
>each other (and thus made Portable)

This issue has been addressed on the list, but the document could do 
a better job of clarifying the position it takes. Time stamps from a 
given TSA are ordered, but there is no guarantee that time stamps 
issued by different TSAs are ordered, since different TSAs may employ 
different time bases, offer different accuracy guarantees, etc. On 
can image various scenarios in which two time stamps, issued by two 
TSAs are not comparable. I agree that the document could do a better 
job of discussing this issue.

>             o-    And last but not least a recommendation on how to use the
>damn things and a statement as to their limitations i.e. what they can and
>cannot do for us with these use models...

We devote little space in other documents to how one might use 
signatures, or certificates in general, so I don't think this 
document is inconsistent with our practice in that regard.

>
>  > On the other hand, the editorial changes improve
>  > readability.
>  >
>  > TECHNICAL
>  >
>  > Section 2.1, 6th requirement.  I do not understand "hash-function
>  > OID."  OIDs, when managed correctly, are collision free.  I think we need
>  > to be discussing the one-way hash function, not its OID.  The selected
>  > one-way hash function must be uniquely identified by an OID.

yes, this should be reworded to make clear that it is the hash 
function, not the OID, that is collision resistant.

>  >
>  > Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says
>  > that the client SHOULD make the check, but that the client MAY elect to
>  > skip the check.  The checking requirement is either a SHOULD or a MAY, it
>  > cannot be both.
>
>Russ - I agree -  the word SHOULD is specific to a USE MODEL as it is a
>recommedation . i.e If you are using this as XYZ then you SHOULD... The word
>MAY creates an choice on the part of the user that is separate of the
>recommendation. This is one of the confusing things in the "Restricted Word"
>definitions. But in this instance since there is no USE MODEL for the TSP
>Defined maybe both are appropriate.

I know that use models are a favorite topic of yours, Todd, but we're 
not going to start adopting them here. Russ's comments address a 
concern over consistency of terminology.  I would assert that it is 
always the case that the client SHOULD check the policy field to 
determine if the time stamp will be useful, in context. The "MAY" 
here should be used differently, e.g., "The client MAY elect to 
ignore the results of this check.' This is not a deep issue, just a 
matter of wording.

We need to review the rest of Russ's comments, and see what changes 
may be necessary, but I don't see any of these as show stoppers.

Steve



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA25446 for <[e-mail]>; Mon, 11 Sep 2000 15:25:52 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 11 Sep 2000 16:27:13 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Mon, 11 Sep 2000 16:27:10 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes -
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 ns.secondary.com id PAA25447

In this regard, I was interested to hear on the Federal PKI TWG list that NIST 
is considering releasing a SHA-256 and SHA-512 hash algorithm.

No new algorithms will be forthcoming -- the only question is whether to 
bundle them with the conventional signature OID, or to separate them out.

Bundling them makes them somewhat harder to change, but on the other hand, 
allowing complete freedom to choose the signing algorithm independently tends to
raise issue of N-squared combinations that have to be tested.

Some combinations might not even make technical sense -- for example 200-bit
elliptic curve DSA with SHA-512, since the hash function wouldn't fit within the 
signature result.

On balance, and noting the generally poor track record we have in limiting 
combinations of things to stable profiles, I am inclined to continue the practice of
specifying the signature algorithm and the hash algorithm as one joint specification.

Bob

>>> "todd glassey" <[e-mail]> 09/11/00 01:06PM >>>
Hi all -

----- Original Message -----
From: "J Adrian Pickering" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 06, 2000 7:57 AM
Subject: Re: CMC issues, TSP hashes


> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>
> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
> >standard open for other hash algorithms. Are there any plans to change
> >this?
>
> This is a problem shared with the TSP Draft also.
>
> (see posting -
> Date: Sat, 02 Sep 2000 17:37:43 +0100
> From: J Adrian Pickering <[e-mail]>
> Subject: TSP Draft - hash enforcement &c
> which is rather lost amongst the OCSP debate!)
>
> Please can something be done about this for everyone's benefit? My
> suggestion is to introduce a PKIX globally available OID
> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
> will enable other hashes to be used where required/wanted. The overloading
> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
any
> use in the hash arena?

Actually Adrian  your right - but I think we need a little more than this.
We need an official PKIX OID Tree and it needs to be available.

For each complex data structure or process that can be uniquely identified
and that would want to be identified, PKIX needs an OID entry in some PKIX
master OID Table. Hash's, techniques, and maybe even the IOTP Transaction
types or something like that as well.

>
> Russ Housley appears to agree: "The selected one-way hash function must be
> uniquely identified by an OID."
>
> I'd still rather have the TSA autonomously stamp an octet string and leave
> the client to decide what it all means.

We are confusing the term "Client" here for the term "USER OF"... and this
is an important concept in understanding what we are really talking about.

The key issue is whether the time stamp is used to control some other
external process, almost analogous to dropping a coin into a vending
machine,
or whether it is standing as evidentiary testimony to some event. As it
happens the Coin does both, but generally the mindset about how the TSP has
been thought about is form using time as a control parameter rather than an
evidentiary one. By the way - We generally as a group seem to assume
automatically between 'using data elements for control' rather than  'for
content'.

In one case they are used to control the infrastructure or policy
like a signal, and on the other they are used to stand audit. The uses of
the same parametric data elements here are very different and have different
needs to support their respective end use models.

> What business is it of the TSA to
> know what it is stamping (semantically or syntactically)?

Depends on what the purpose of the TSA is. If there is a conveyance in a
legal sense of Agency, then the TSA may have legally binding reasons for
being able to identify the type of content it is stamping. Maybe to the
granularity of needing to parse the file first to determine its data type.

.. and this leads us to the fact that a HASH in and of itself as a
timestamping record is very difficult to use from an end user model. What
the TST should be is a framework or harness itself and internally it should
represent a number of events interchangeably. There would need to be
different grades of Tokens with varying levels of overhead for their
management, and the approriate BCP to match.

But realize that in no uncertain terms what we are sitting on is  the
designing of the Global Mint here.

"The real end user goal is a simple bolt-on system that allows end users to,
with the transaction infrastructure they have today,  add non-repudiation
at a commercial level to their process, and  at a scaleable and reasonable
overhead."

Simple to say, not so simple to do as there are so many different
transaction
processing systems in the world today, but the common elements in all of
them is that they have some DB system that they are layered on and an OS
under that of some sort.

With that being the key the DB that is, doesn't the idea of a common binary
data structure that is a timestamp token appeal to you (represented in the
cyber world as ASN.1 if you want) . We can build an TST Binary to XML
presentation system and absorb or bridge the IOTP/XML Receipt efforts at
some level into the PKIX Timestamping systems  and deliver evidentiary grade
standards for representing events in time and space. YOW - look at the
potential
there!!!.

These tokens and their respective API's will be able to specify its level of
trust, the event it marks and the data components that make up that event,
and the rules of processing the token. If a lighter token is necessary
portions of the system can be replaced by OIDS on as "as many as possible"
basis based in the OID tree idea (see above). More risk mitigated
transactions may require self authenticating tokens as well and we should
provide for these at the high end of the API.

Poof - Instant transaction systems. I think that this is what DigiCash and
most all of the other token based transactor companies tried to do but they
were too far ahead of the curve to get real traction - and as scary as it
sounds, PKIX is in the perfect position to make this fly now.

BTW, in and of itself is reason for not advancing the TPS Draft.

>
> Adrian Pickering/
> Electronics and Computer Science
> University of Southampton
> UK
>
>




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA25115 for <[e-mail]>; Mon, 11 Sep 2000 15:15:29 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 11 Sep 2000 16:16:58 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.4.1
Date: Mon, 11 Sep 2000 16:16:57 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Client-side revocation checking capability
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 ns.secondary.com id PAA25116

David,

It's always useful to get someone else's perspective on these kinds of 
issues, especially when the issue is not really technical but cost/benefit.

Paraphrasing what you've said, and playing it back to be sure we are 
on the same page, I conclude that since Visa, MasterCard, and
American Express have effectively lowered the liability for consumers for 
electronic transactions to $0, waving the Reg. E/Reg. Z $50 limit of liability,
my only risk in the event of a credit card scam on the Internet is the hassle 
factor of notifying my bank that I didn't make the purchase in question.
And since checking CRLs still doesn't guarantee that an employee of
the merchant can't rip off my card (or the waitress at my favorite restaurant), 
if CRL checking slows me down by more than a fraction of a second, it 
probably isn't worth doing.

On the other hand, if I am logging on to some other type of web server,
in particular one where the merchant/bank is NOT collecting a percentage of 
the transaction,. and therefore cannot be quite so forgiving with respect to 
poor security on my part. perhaps, then CRL checking might be quite important.

For example, if my bank or my e-trade broker provides an SSL session to protect
my password or other form of authentication, and someone puts up a bogus 
site that compromises that password, then the limit of my liability may be the 
amount I have on deposit (or even more, if someone sells sort and I can't 
cover it.)

Likewise, if I am consulting my attorney and divulge the details of some heinous
crime, and in reality I'm talking to the District Attorney, I could end up with a 
lot more than just a financial cost.

I do like Bob Moskowitz's solution, and hadn't heard of it -- pass a 
current CRL along with the TLS certificate chain, and make sure that the 
CRL is nearly always empty, so that an excessive amount of time
is not consumed in validating the certificate chain.  Do you know where
that approach stands in the standards track for TSL?

On the other hand, sending the same certificate chain down the line every 
time I log on to Amazon.com is really wasteful of bandwidth. I would like to 
have the option of only downloading the certificates, and the CRLS (and/or 
OCSP response) if my relying party software finds it necessary.  Most of the time
those certificates should either be cached by the relying party, or in a directory 
or other form of cache that can be accessed locally, and quickly.

Regards,

Bob




>>> "David P. Kemp" <[e-mail]> 09/11/00 11:12AM >>>
Bob, you ask "is there a significant security benefit to doing revocation
checking on web server certificates?"  I'll only consider the first reason,
key compromise, since if it provides a positive answer, no other reasons
need to be considered.

PKI serves the relying party, not the subscriber.  If I connect to a web
site, do I get any benefit from checking for certificate revocation?  What
do I lose if I trust a cert whose private key has been compromised?
Obviously, if I'm just surfing around, I don't lose anything.  It doesn't
harm me if I see the content of "whitehouse.com" when I really wanted
"whitehouse.gov".  But if I'm buying something with a credit card, I
might want to do whatever is possible to prevent my card from being used
fraudulently.

You are correct, there needs to be
  1) a detected compromise, and
  2) a MITM,
for CRLs to provide useful protection against key compromise.
DNS spoofing is certainly not the only way for an attacker to insert
himself somewhere between a client and a server on the Internet, so
even if DNSsec were 100% implemented and effective, unauthenticated SSL
(a session where the user clicked "Yes" to ignore a path validation
problem) would not guarantee a secure connection to the desired
server.

I don't agree that the pertinent question is "is this a million dollar
transaction?".  The question is "does the potential benefit of checking
a CRL exceed the cost of checking it?".  If I had $0 liability for
credit card fraud if I followed best commercial cert validation
practice, and $50 if I ignored it, then I'd probably follow it even if
the probability of loss were very small.  Unless of course following
"best practice" caused a significant slowdown, in which case I'd turn
off revocation checking entirely or get in the habit of clicking "Ignore"
when the (hypothetical) "Fetching CRL ..." window pops up.

So how to make revocation checking invisible enough that users don't
turn it off?  Bob Moskowitz already gave the answer to that: partition
so that CA/server CRLs remain tiny (empty 99.999999% of the time), and
pass them from server to client along with certs in the TLS handshake
so they don't cause any additional delay.

Regards,
Dave




> Date: Tue, 05 Sep 2000 10:02:59 -0600
> From: "Bob Jueneman" <[e-mail]>
> To: <[e-mail]>, <[e-mail]>
> Subject: Re: Client-side revocation checking capability
> Content-Disposition: inline
> 
> David, I agree with you completely.
> 
> But at the risk of arguing in circles, I would appreciate your thoughts on the 
need to do CRL checking of web site addresses, at least for the majority of 
applications.
> 
> Presumably there are two reasons why a web server's certificate would ever be 
revoked:
> 
> 1.  The key has been compromised somehow, and (this is bit of a stretch), the 
organization knows that it has been compromised.
> 
> 2.  The information contained in the certificate is no longer valid.
> 
> Now, since SSL downloads the certificates to be used to validate the session 
(they aren't obtained out of band somehow), I would contend that if the 
organization knows it has been compromised, it would immediately stop using that 
key and certificate  go get a new one, and use that one instead.
> 
> Likewise, if for example Land Rover wants to change their name from something 
like "Land Rover, a subsidiary of BMW" to "Land Rover, a subsidiary of the Ford 
Motor Company," they would just get a new certificate and start using it.
> 
> Now, I don't deny the possibility that VeriSign, upon hearing that Ford had 
bought Land Rover, might take it upon themselves to unilaterally revoke a 
certificate that identifies them as belong to BMW, but I think it is exceedingly 
unlikely.  In fact, it is rather hard for me to imagine ANY type of circumstance 
other than outright, blatant fraud of the most egregious kind that would cause 
VeriSign to take such unilateral action -- they would almost surely go the cease 
and desist route, rather than subjecting themselves to a potentially huge suit 
for damages by unilaterally revoking a certificate. (I'm only using VeriSign as 
the example here because of their dominance int he server certificate market.)
> 
> So that leaves us with the key compromise possibility.
> 
> Now, in order to somehow benefit from a key compromise, the perpetrator would 
have to: (1) first install the compromised key on a server somewhere, and then 
(2) spoof or otherwise divert the DNS routing so that requests to 
www.whitehouse.gov go to say  www.dirtytricks.com. But assuming that the 
legitimate organization knows about the key compromise, they would be on the 
lookout for such trickery, and would presumably notify the DNS naming 
authorities to reject any attempt to modify the IP routing for their DNS name.
> 
> But putting up a server at a given IP address that contains a stolen key would 
effectively constitute a smoking gun pointed directly at the instigator's head, 
to mix a metaphor.  It provide prima facie evidence that they were responsible 
for the key theft.
> 
> OK, I'll grant that this isn't absolutely airtight and foolproof, and that for 
some really, really important transactions it might be nice to actually check 
the web server's CRL, "just in case".  But assuming that you aren't involved in 
million dollar transactions, the risk seems very slight, and certainly 
acceptable to most users.
> 
> Do you agree with this analysis?
> 
> Bob
> 
> >>> "David P. Kemp" <[e-mail]> 09/01/00 10:53AM >>>
> 
> > From: [e-mail] 
> >
> > Now looking at possibly a trivial occurance of relying party checking ...m
>  aybe
> > only a trivial 99.99999999999999% of all relying party "checking" currently
> > going on ... it would appear that the most common occurance of a relying 
party
> > checking something is a SSL relying party checking a domain name.
> > 99.999999999999% of all such checking might not seem like a valid situation 
to
> > consider.
> 
> 
> What is the threat that the PKI is addressing?   My assumption is that
> in 99.99999999% of the cases the company hosting the web server is interested
> in preventing the following:
> 
> 1) user sees "www.companyA.com" on an advertisement and types it in, or
>    clicks a link.
> 
> 2) DNS has been hijacked, the user connects to a bogus server, and the
>    user gives up his personal info to the bad guy.  Or the user sees a
>    parody of www.companyA.com, or worse.
> 
> A server certificate issued by a CA to the company binds a company name
> (real world and/or DNS) to the company's private key.  If DNS has been
> hijacked, the bad guy still can't impersonate the company web site.
> I'd say that 99.999999% of the relying party checking involves seeing
> the company's legitimate content; the DNS name is largely irrelevant
> for the user's purposes.  The user could type an IP address, or any one
> of a number of DNS names, and as long as he gets to the company's
> information he couldn't care less how he got it.
> 
> In fact, including DNSnames in relying party (browser) checking causes
> unnecessary problems with virtual hosting. "www.CompanyA.com" should be
> a DNS *Name*, something the user types when he wants to see CompanyA's
> information.  It shouldn't be any problem if CompanyA's information is
> actually being served from https://www.hosting-service.com/account51/;
> the only thing that matters is that the user can be referred from what
> he types to where the information resides, and that the legitimate
> information provider has CompanyA's private key.
> 
>  * DNS security should be about binding DNS names to IP addresses, and 
>    should have nothing to do with EE keys.
>  * PKI security should be about binding names (DNS, rfc822, or a real
>    world brand name - "Ford Motor Company") to keys.  The CA's responsibility
>    is to ensure that the brand owner and the key are properly matched -
>    this is far beyond the scope of a DNS administrator's duties.
>  * application security should be about protecting whatever is meaningful
>    about the user with the user's private key.  In the case of web servers,
>    what is meaningful is the company's content, not a DNSname.
> 
> If you try to take shortcuts (by combining DNS and PKI, for example),
> you prevent useful things from happening.  DNS security supports
> infrastructure availability; PKI supports application security.
> Unnecessarily sacrificing web server functionality for security just
> gives security a bad name.  And increasing the DNS administrator's
> workload hinders the adoption of simple yet valuable name-to-IP
> security.



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21287 for <[e-mail]>; Mon, 11 Sep 2000 12:05:43 -0700 (PDT)
Received: from tsg1 ([12.72.64.169]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000911190713.KSVM6605.mtiwmhc25.worldnet.att.net@tsg1>; Mon, 11 Sep 2000 19:07:13 +0000
Message-ID: <00f401c01c23$6c2cead0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "J Adrian Pickering" <[e-mail]>
References: <[e-mail]>
Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes - 
Date: Mon, 11 Sep 2000 12:06:41 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Hi all -

----- Original Message -----
From: "J Adrian Pickering" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 06, 2000 7:57 AM
Subject: Re: CMC issues, TSP hashes


> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>
> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
> >standard open for other hash algorithms. Are there any plans to change
> >this?
>
> This is a problem shared with the TSP Draft also.
>
> (see posting -
> Date: Sat, 02 Sep 2000 17:37:43 +0100
> From: J Adrian Pickering <[e-mail]>
> Subject: TSP Draft - hash enforcement &c
> which is rather lost amongst the OCSP debate!)
>
> Please can something be done about this for everyone's benefit? My
> suggestion is to introduce a PKIX globally available OID
> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
> will enable other hashes to be used where required/wanted. The overloading
> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
any
> use in the hash arena?

Actually Adrian  your right - but I think we need a little more than this.
We need an official PKIX OID Tree and it needs to be available.

For each complex data structure or process that can be uniquely identified
and that would want to be identified, PKIX needs an OID entry in some PKIX
master OID Table. Hash's, techniques, and maybe even the IOTP Transaction
types or something like that as well.

>
> Russ Housley appears to agree: "The selected one-way hash function must be
> uniquely identified by an OID."
>
> I'd still rather have the TSA autonomously stamp an octet string and leave
> the client to decide what it all means.

We are confusing the term "Client" here for the term "USER OF"... and this
is an important concept in understanding what we are really talking about.

The key issue is whether the time stamp is used to control some other
external process, almost analogous to dropping a coin into a vending
machine,
or whether it is standing as evidentiary testimony to some event. As it
happens the Coin does both, but generally the mindset about how the TSP has
been thought about is form using time as a control parameter rather than an
evidentiary one. By the way - We generally as a group seem to assume
automatically between 'using data elements for control' rather than  'for
content'.

In one case they are used to control the infrastructure or policy
like a signal, and on the other they are used to stand audit. The uses of
the same parametric data elements here are very different and have different
needs to support their respective end use models.

> What business is it of the TSA to
> know what it is stamping (semantically or syntactically)?

Depends on what the purpose of the TSA is. If there is a conveyance in a
legal sense of Agency, then the TSA may have legally binding reasons for
being able to identify the type of content it is stamping. Maybe to the
granularity of needing to parse the file first to determine its data type.

... and this leads us to the fact that a HASH in and of itself as a
timestamping record is very difficult to use from an end user model. What
the TST should be is a framework or harness itself and internally it should
represent a number of events interchangeably. There would need to be
different grades of Tokens with varying levels of overhead for their
management, and the approriate BCP to match.

But realize that in no uncertain terms what we are sitting on is  the
designing of the Global Mint here.

"The real end user goal is a simple bolt-on system that allows end users to,
with the transaction infrastructure they have today,  add non-repudiation
at a commercial level to their process, and  at a scaleable and reasonable
overhead."

Simple to say, not so simple to do as there are so many different
transaction
processing systems in the world today, but the common elements in all of
them is that they have some DB system that they are layered on and an OS
under that of some sort.

With that being the key the DB that is, doesn't the idea of a common binary
data structure that is a timestamp token appeal to you (represented in the
cyber world as ASN.1 if you want) . We can build an TST Binary to XML
presentation system and absorb or bridge the IOTP/XML Receipt efforts at
some level into the PKIX Timestamping systems  and deliver evidentiary grade
standards for representing events in time and space. YOW - look at the
potential
there!!!.

These tokens and their respective API's will be able to specify its level of
trust, the event it marks and the data components that make up that event,
and the rules of processing the token. If a lighter token is necessary
portions of the system can be replaced by OIDS on as "as many as possible"
basis based in the OID tree idea (see above). More risk mitigated
transactions may require self authenticating tokens as well and we should
provide for these at the high end of the API.

Poof - Instant transaction systems. I think that this is what DigiCash and
most all of the other token based transactor companies tried to do but they
were too far ahead of the curve to get real traction - and as scary as it
sounds, PKIX is in the perfect position to make this fly now.

BTW, in and of itself is reason for not advancing the TPS Draft.

>
> Adrian Pickering/
> Electronics and Computer Science
> University of Southampton
> UK
>
>




Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20929 for <[e-mail]>; Mon, 11 Sep 2000 11:57:51 -0700 (PDT)
Received: from tsg1 ([12.72.64.169]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000911185920.KPHC6605.mtiwmhc25.worldnet.att.net@tsg1>; Mon, 11 Sep 2000 18:59:20 +0000
Message-ID: <00e201c01c22$5201a840$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "J Adrian Pickering" <[e-mail]>
References: <[e-mail]>
Subject: TS TOKEN TYPES - Re: CMC issues, TSP hashes - 
Date: Mon, 11 Sep 2000 11:58: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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Hi all -

----- Original Message -----
From: "J Adrian Pickering" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 06, 2000 7:57 AM
Subject: Re: CMC issues, TSP hashes


> At 11:57 06/09/00 +0200, Avi Gozlan wrote:
>
> >- Use of SHA1 is hard coded in section 5.2. This does not leave the
> >standard open for other hash algorithms. Are there any plans to change
> >this?
>
> This is a problem shared with the TSP Draft also.
>
> (see posting -
> Date: Sat, 02 Sep 2000 17:37:43 +0100
> From: J Adrian Pickering <[e-mail]>
> Subject: TSP Draft - hash enforcement &c
> which is rather lost amongst the OCSP debate!)
>
> Please can something be done about this for everyone's benefit? My
> suggestion is to introduce a PKIX globally available OID
> HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This
> will enable other hashes to be used where required/wanted. The overloading
> of the AlgorithmIdentifier allows for a parameter which I'm not sure is
any
> use in the hash arena?

Actually Adrian  your right - but I think we need a little more than this.
We need an official PKIX OID Tree and it needs to be available.

For each complex data structure or process that can be uniquely identified
and that would want to be identified, PKIX needs an OID entry in some PKIX
master OID Table. Hashs, techniques, and maybe even the IOTP Transaction
types or something like that as well.

>
> Russ Housley appears to agree: "The selected one-way hash function must be
> uniquely identified by an OID."
>
> I'd still rather have the TSA autonomously stamp an octet string and leave
> the client to decide what it all means.

We are confusing the term "Client" here for the term "USER OF"... and this
is an important concept in understanding what we are really talking about.

The key issue is whether the time stamp is used to control some other
external process, almost analogus to dropping a coin into a vending machine,
or whether it is standing as evidentiary testimony to some event. As it
happens the Coin does both, but generally the mindset about hopw the TSP has
been thought about is form using time as a control parameter rather than an
evidentiary one.

By the way - We generally as a group seem to assume automatically between
'using data elements for control' rather than  'for content' on the other
hand . In one case they are used to control the infrastructure or policy
like a signal, and on the other they are used to stand audit. The uses of
the same parametric data elements here are very different and have different
needs to support their respective end use models.

> What business is it of the TSA to
> know what it is stamping (semantically or syntactically)?

Depends on what the purpose of the TSA is. If there is a conveyance in a
legal sense of Agency, then the TSA may have legally binding reasons for
being able to identify the type of content it is stamping. Maybe to the
granularity of needing to parse the file first to determine its data type.


... and this leads us to the fact that a HASH in and of itself as a
timestamping record is very difficult to use from an end user model. What
the TST should be is a framework or harness itself and internally it should
represent a number of ebents interchangable. There would need to be
different grades of Tokens with varying levels of overhead for their
management, and the approriate BCP to match.

But realize that in no uncertain terms what we are sitting on is  the
designing of the Global Mint here.

What we need more than anything is a simple system that allows end users to,
with the transaction systems they have today,  add non-repudiation at a
commercial level to their process, and  at a scaleable and reasonable
overhead.

Simple to say, not so simple to do as there are so many differnt transaction
processing systems in the world today, but the common elements in all of
them is that they have some DB system that they are layered on and an OS
under that of some sort.

With that being the key, doesnt the idea of a common binary data structure
that is a timestamp token appeal to you(represented in the cyber world as
ASN.1 if you want) . We can build an TST Binary to XML presentation system
and absorb the IOTP/XML Receipt efforts at some level into the PKIX
Timestamping systems  and deliver evidentiary grade standards for all levels
of the transaction market. YOW - look at the potential there!!!.

These tokens and their respective API's will be able to specify its level of
trust, the event it marks and the data componetns that make up that event,
and the rules of processing the token. If a lighter token is necessary
portions of the system can be replaced by OIDS on as "as many as possible"
basis based in the OID tree idea (see above). More risk mitigated
transactions may require self authenticating tokens as well and we should
provide for these at the high end of the API.

Poof - Instant transaction systems. I think that this is what DigiCash and
most all of the other token based transactor companies tried to do but they
were too far ahead of the curve to get real traction - and as scary as it
sounds, PKIX is in the perfect position to make this fly now.

BTW, in and of itself is reason for not advancing the TPS Draft.

>
> Adrian Pickering/
> Electronics and Computer Science
> University of Southampton
> UK
>
>



Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19688 for <[e-mail]>; Mon, 11 Sep 2000 10:52:23 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id KAA08504; Mon, 11 Sep 2000 10:53:48 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 11 Sep 2000 13:34:09 -0400
To: "todd glassey" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Proposed Charter Amendment...
Cc: <[e-mail]>, "J Adrian Pickering" <[e-mail]>
In-Reply-To: <005201c01c05$30876e10$020aff0c@tsg1>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

<html>
Todd:<br>
<br>
I do not agree.&nbsp; In my view, the Introduction section of each
document should provide the necessary context for the rest of the
document.&nbsp; If you do not believe that sufficient context is being
provide, then send comments to the list -- and offer some additional
text.&nbsp; The debase on the list will determine if there is
concensus.<br>
<br>
Russ<br>
<br>
<br>
At 08:30 AM 09/11/2000 -0700, todd glassey wrote:<br>
<blockquote type=cite cite><font face="arial" size=2>Gentlefolk -
</font><br>
&nbsp;<br>
<font face="arial" size=2>A year or so ago I brought up the concept that
PKIX Standards and RFC's were different than many of the other standards
that the IETF was producing in that many of them would be concerned with
end-user processes and requirements. Because of this I am proposing
(again) to set an additional requirement that ALL RFC's in PKIX that are
to be advanced to STANDARDS have an associated Applicability Document
(AD) and that no standard effort will be allowed to proceed past RFC
without one. </font><br>
&nbsp;<br>
<font face="arial" size=2>This&nbsp; requirement is needed for a number
of reasons not the least of them being that other standards orgs need to
use this material as a basis of their efforts (the IETF being one of the
lowest links on the Standard's Food Chain.</font><br>
&nbsp;<br>
<font face="arial" size=2>My belief is that this is critically true of a
number of the efforts currently underway, like the TSP and OCSP protocol
efforts. Anyway - the current charter is included below for reference as
well as the proposed amendment to paragraph two.</font><br>
&nbsp;<br>
<font face="arial" size=2>---------------------</font><br>
&nbsp;<br>
<font face="arial" size=2>The PKIX Working Group was established in the
Fall of 1995 with the intent of developing Internet standards needed to
support an X.509-based PKI. Several informational and standards track
documents in support of the original goals of the WG have been approved
by the IESG. The first of these standards, RFC 2459, profiles the X.509
version 3 certificates and version 2 CRLs for use in the Internet. The
Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate
Status Protocol (OCSP) (RFC 2560), and the Certificate Management Request
Format (CRMF) (RFC 2511) have been approved, as have profiles for the use
of LDAP v2 for certificate and CRL storage (RFC 2587) and the use of FTP
and HTTP for transport of PKI operations (RFC 2585). RFC 2527, an
informational RFC on guidelines for certificate policies and practices
also has been published, and the IESG has approved publication of an
information RFC on use of KEA (RFC 2528) and is expected to do the same
for ECDSA. Work continues on a second certificate management protocol,
CMC, closely aligned with the PKCS publications and with the
cryptographic message syntax (CMS) developed for S/MIME. A roadmap,
providing a guide to the growing set of PKIX document, is also being
developed as an informational RFC. <br>
<br>
The working group is now embarking on additional standards work to
develop protocols that are either integral to PKI management, or that are
otherwise closely related to PKI use. Work is ongoing on alternative
certificate revocation methods. There also is work defining conventions
for certificate name forms and extension usage for &quot;qualified
certificates,&quot; certificates designed for use in (legally binding)
non-repudiation contexts. Finally, work is underway on protocols for time
stamping and data certification. These protocols are designed primarily
to support non-repudiation, making use of certificates and CRLs, and are
so tightly bound to PKI use that they warrant coverage under this working
group. <br>
<br>
Additional work will be initiated on a profile for X.509 attribute
certificates, resulting in a new RFC and, perhaps, in extensions to
existing certificate management standards to accommodate differences
between attribute certificates and public-key certificates. <br>
<br>
---------------------------------<br>
<br>
Amended Text for Paragraph 2:<br>
<br>
The working group is now embarking on additional standards work to
develop protocols that are either integral to PKI management, or that are
otherwise closely related to PKI use. Many of these standards are
directly tied to end use standards and where applicable, external input
will be sought and factored into the efforts. <br>
<br>
These projects currently include a number of ancillary efforts like:
alternative certificate revocation methods; defining conventions for
certificate name forms and extension usage for &quot;qualified
certificates&quot;; certificates designed for use in (legally binding)
non-repudiation contexts, and NON-REPUDIATION Services like time stamping
and data certification.&nbsp; Many of these protocols are designed
primarily to support non-repudiation, making use of certificates and
CRLs, and are so tightly bound to PKI and end-use models that their
technology warrants coverage under this working group. <br>
<br>
&nbsp;<br>
<br>
--------------------------------</font></blockquote></html>



Received: from roadblock.missi.ncsc.mil ([144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18951 for <[e-mail]>; Mon, 11 Sep 2000 10:16:32 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA01637 for <[e-mail]>; Mon, 11 Sep 2000 13:03:07 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Mon, 11 Sep 2000 13:12:54 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Client-side revocation checking capability
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: MYl8Luwy4dm/BSJbC5CjKA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Bob, you ask "is there a significant security benefit to doing revocation
checking on web server certificates?"  I'll only consider the first reason,
key compromise, since if it provides a positive answer, no other reasons
need to be considered.

PKI serves the relying party, not the subscriber.  If I connect to a web
site, do I get any benefit from checking for certificate revocation?  What
do I lose if I trust a cert whose private key has been compromised?
Obviously, if I'm just surfing around, I don't lose anything.  It doesn't
harm me if I see the content of "whitehouse.com" when I really wanted
"whitehouse.gov".  But if I'm buying something with a credit card, I
might want to do whatever is possible to prevent my card from being used
fraudulently.

You are correct, there needs to be
  1) a detected compromise, and
  2) a MITM,
for CRLs to provide useful protection against key compromise.
DNS spoofing is certainly not the only way for an attacker to insert
himself somewhere between a client and a server on the Internet, so
even if DNSsec were 100% implemented and effective, unauthenticated SSL
(a session where the user clicked "Yes" to ignore a path validation
problem) would not guarantee a secure connection to the desired
server.

I don't agree that the pertinent question is "is this a million dollar
transaction?".  The question is "does the potential benefit of checking
a CRL exceed the cost of checking it?".  If I had $0 liability for
credit card fraud if I followed best commercial cert validation
practice, and $50 if I ignored it, then I'd probably follow it even if
the probability of loss were very small.  Unless of course following
"best practice" caused a significant slowdown, in which case I'd turn
off revocation checking entirely or get in the habit of clicking "Ignore"
when the (hypothetical) "Fetching CRL ..." window pops up.

So how to make revocation checking invisible enough that users don't
turn it off?  Bob Moskowitz already gave the answer to that: partition
so that CA/server CRLs remain tiny (empty 99.999999% of the time), and
pass them from server to client along with certs in the TLS handshake
so they don't cause any additional delay.

Regards,
Dave




> Date: Tue, 05 Sep 2000 10:02:59 -0600
> From: "Bob Jueneman" <[e-mail]>
> To: <[e-mail]>, <[e-mail]>
> Subject: Re: Client-side revocation checking capability
> Content-Disposition: inline
> 
> David, I agree with you completely.
> 
> But at the risk of arguing in circles, I would appreciate your thoughts on the 
need to do CRL checking of web site addresses, at least for the majority of 
applications.
> 
> Presumably there are two reasons why a web server's certificate would ever be 
revoked:
> 
> 1.  The key has been compromised somehow, and (this is bit of a stretch), the 
organization knows that it has been compromised.
> 
> 2.  The information contained in the certificate is no longer valid.
> 
> Now, since SSL downloads the certificates to be used to validate the session 
(they aren't obtained out of band somehow), I would contend that if the 
organization knows it has been compromised, it would immediately stop using that 
key and certificate  go get a new one, and use that one instead.
> 
> Likewise, if for example Land Rover wants to change their name from something 
like "Land Rover, a subsidiary of BMW" to "Land Rover, a subsidiary of the Ford 
Motor Company," they would just get a new certificate and start using it.
> 
> Now, I don't deny the possibility that VeriSign, upon hearing that Ford had 
bought Land Rover, might take it upon themselves to unilaterally revoke a 
certificate that identifies them as belong to BMW, but I think it is exceedingly 
unlikely.  In fact, it is rather hard for me to imagine ANY type of circumstance 
other than outright, blatant fraud of the most egregious kind that would cause 
VeriSign to take such unilateral action -- they would almost surely go the cease 
and desist route, rather than subjecting themselves to a potentially huge suit 
for damages by unilaterally revoking a certificate. (I'm only using VeriSign as 
the example here because of their dominance int he server certificate market.)
> 
> So that leaves us with the key compromise possibility.
> 
> Now, in order to somehow benefit from a key compromise, the perpetrator would 
have to: (1) first install the compromised key on a server somewhere, and then 
(2) spoof or otherwise divert the DNS routing so that requests to 
www.whitehouse.gov go to say  www.dirtytricks.com. But assuming that the 
legitimate organization knows about the key compromise, they would be on the 
lookout for such trickery, and would presumably notify the DNS naming 
authorities to reject any attempt to modify the IP routing for their DNS name.
> 
> But putting up a server at a given IP address that contains a stolen key would 
effectively constitute a smoking gun pointed directly at the instigator's head, 
to mix a metaphor.  It provide prima facie evidence that they were responsible 
for the key theft.
> 
> OK, I'll grant that this isn't absolutely airtight and foolproof, and that for 
some really, really important transactions it might be nice to actually check 
the web server's CRL, "just in case".  But assuming that you aren't involved in 
million dollar transactions, the risk seems very slight, and certainly 
acceptable to most users.
> 
> Do you agree with this analysis?
> 
> Bob
> 
> >>> "David P. Kemp" <[e-mail]> 09/01/00 10:53AM >>>
> 
> > From: [e-mail] 
> >
> > Now looking at possibly a trivial occurance of relying party checking ...m
>  aybe
> > only a trivial 99.99999999999999% of all relying party "checking" currently
> > going on ... it would appear that the most common occurance of a relying 
party
> > checking something is a SSL relying party checking a domain name.
> > 99.999999999999% of all such checking might not seem like a valid situation 
to
> > consider.
> 
> 
> What is the threat that the PKI is addressing?   My assumption is that
> in 99.99999999% of the cases the company hosting the web server is interested
> in preventing the following:
> 
> 1) user sees "www.companyA.com" on an advertisement and types it in, or
>    clicks a link.
> 
> 2) DNS has been hijacked, the user connects to a bogus server, and the
>    user gives up his personal info to the bad guy.  Or the user sees a
>    parody of www.companyA.com, or worse.
> 
> A server certificate issued by a CA to the company binds a company name
> (real world and/or DNS) to the company's private key.  If DNS has been
> hijacked, the bad guy still can't impersonate the company web site.
> I'd say that 99.999999% of the relying party checking involves seeing
> the company's legitimate content; the DNS name is largely irrelevant
> for the user's purposes.  The user could type an IP address, or any one
> of a number of DNS names, and as long as he gets to the company's
> information he couldn't care less how he got it.
> 
> In fact, including DNSnames in relying party (browser) checking causes
> unnecessary problems with virtual hosting. "www.CompanyA.com" should be
> a DNS *Name*, something the user types when he wants to see CompanyA's
> information.  It shouldn't be any problem if CompanyA's information is
> actually being served from https://www.hosting-service.com/account51/;
> the only thing that matters is that the user can be referred from what
> he types to where the information resides, and that the legitimate
> information provider has CompanyA's private key.
> 
>  * DNS security should be about binding DNS names to IP addresses, and 
>    should have nothing to do with EE keys.
>  * PKI security should be about binding names (DNS, rfc822, or a real
>    world brand name - "Ford Motor Company") to keys.  The CA's responsibility
>    is to ensure that the brand owner and the key are properly matched -
>    this is far beyond the scope of a DNS administrator's duties.
>  * application security should be about protecting whatever is meaningful
>    about the user with the user's private key.  In the case of web servers,
>    what is meaningful is the company's content, not a DNSname.
> 
> If you try to take shortcuts (by combining DNS and PKI, for example),
> you prevent useful things from happening.  DNS security supports
> infrastructure availability; PKI supports application security.
> Unnecessarily sacrificing web server functionality for security just
> gives security a bad name.  And increasing the DNS administrator's
> workload hinders the adoption of simple yet valuable name-to-IP
> security.



Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13545 for <[e-mail]>; Mon, 11 Sep 2000 08:29:23 -0700 (PDT)
Received: from tsg1 ([12.72.64.169]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000911153047.HDHU6605.mtiwmhc25.worldnet.att.net@tsg1>; Mon, 11 Sep 2000 15:30:47 +0000
Message-ID: <005201c01c05$30876e10$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Cc: "J Adrian Pickering" <[e-mail]>
Subject: Proposed Charter Amendment...
Date: Mon, 11 Sep 2000 08:30:16 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C01BCA.8338B7D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

This is a multi-part message in MIME format.

------=_NextPart_000_004F_01C01BCA.8338B7D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Gentlefolk -=20

A year or so ago I brought up the concept that PKIX Standards and RFC's =
were different than many of the other standards that the IETF was =
producing in that many of them would be concerned with end-user =
processes and requirements. Because of this I am proposing (again) to =
set an additional requirement that ALL RFC's in PKIX that are to be =
advanced to STANDARDS have an associated Applicability Document (AD) and =
that no standard effort will be allowed to proceed past RFC without one. =


This  requirement is needed for a number of reasons not the least of =
them being that other standards orgs need to use this material as a =
basis of their efforts (the IETF being one of the lowest links on the =
Standard's Food Chain.

My belief is that this is critically true of a number of the efforts =
currently underway, like the TSP and OCSP protocol efforts. Anyway - the =
current charter is included below for reference as well as the proposed =
amendment to paragraph two.

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

The PKIX Working Group was established in the Fall of 1995 with the =
intent of developing Internet standards needed to support an X.509-based =
PKI. Several informational and standards track documents in support of =
the original goals of the WG have been approved by the IESG. The first =
of these standards, RFC 2459, profiles the X.509 version 3 certificates =
and version 2 CRLs for use in the Internet. The Certificate Management =
Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP) =
(RFC 2560), and the Certificate Management Request Format (CRMF) (RFC =
2511) have been approved, as have profiles for the use of LDAP v2 for =
certificate and CRL storage (RFC 2587) and the use of FTP and HTTP for =
transport of PKI operations (RFC 2585). RFC 2527, an informational RFC =
on guidelines for certificate policies and practices also has been =
published, and the IESG has approved publication of an information RFC =
on use of KEA (RFC 2528) and is expected to do the same for ECDSA. Work =
continues on a second certificate management protocol, CMC, closely =
aligned with the PKCS publications and with the cryptographic message =
syntax (CMS) developed for S/MIME. A roadmap, providing a guide to the =
growing set of PKIX document, is also being developed as an =
informational RFC.=20
The working group is now embarking on additional standards work to =
develop protocols that are either integral to PKI management, or that =
are otherwise closely related to PKI use. Work is ongoing on alternative =
certificate revocation methods. There also is work defining conventions =
for certificate name forms and extension usage for "qualified =
certificates," certificates designed for use in (legally binding) =
non-repudiation contexts. Finally, work is underway on protocols for =
time stamping and data certification. These protocols are designed =
primarily to support non-repudiation, making use of certificates and =
CRLs, and are so tightly bound to PKI use that they warrant coverage =
under this working group.=20

Additional work will be initiated on a profile for X.509 attribute =
certificates, resulting in a new RFC and, perhaps, in extensions to =
existing certificate management standards to accommodate differences =
between attribute certificates and public-key certificates.=20

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

Amended Text for Paragraph 2:

The working group is now embarking on additional standards work to =
develop protocols that are either integral to PKI management, or that =
are otherwise closely related to PKI use. Many of these standards are =
directly tied to end use standards and where applicable, external input =
will be sought and factored into the efforts.=20

These projects currently include a number of ancillary efforts like: =
alternative certificate revocation methods; defining conventions for =
certificate name forms and extension usage for "qualified certificates"; =
certificates designed for use in (legally binding) non-repudiation =
contexts, and NON-REPUDIATION Services like  time stamping and data =
certification.  Many of these protocols are designed primarily to =
support non-repudiation, making use of certificates and CRLs, and are so =
tightly bound to PKI and end-use models that their technology warrants =
coverage under this working group.=20



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


------=_NextPart_000_004F_01C01BCA.8338B7D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3019.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c8e0d8>
<DIV><FONT face=3DArial size=3D2>Gentlefolk - </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A year or so ago I brought up the =
concept that PKIX=20
Standards and RFC's were different than many of the other standards that =
the=20
IETF was producing in that many of them would be concerned with end-user =

processes and requirements. Because of this I am proposing (again) to =
set an=20
additional requirement that ALL RFC's in PKIX that are to be advanced to =

STANDARDS have an associated Applicability Document (AD) and that no =
standard=20
effort will be allowed to proceed past RFC without one. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This&nbsp; requirement is needed for a =
number of=20
reasons not the least of them being that other standards orgs need to =
use this=20
material as a basis of their efforts (the IETF being one of the lowest =
links on=20
the Standard's Food Chain.</FONT><FONT face=3DArial =
size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My belief is that this is critically =
true of a=20
number of the efforts currently underway, like the TSP and OCSP protocol =

efforts. Anyway - the current charter is included below for reference as =
well as=20
the proposed amendment to paragraph two.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>---------------------</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The PKIX Working Group was established =
in the Fall=20
of 1995 with the intent of developing Internet standards needed to =
support an=20
X.509-based PKI. Several informational and standards track documents in =
support=20
of the original goals of the WG have been approved by the IESG. The =
first of=20
these standards, RFC 2459, profiles the X.509 version 3 certificates and =
version=20
2 CRLs for use in the Internet. The Certificate Management Protocol =
(CMP) (RFC=20
2510), the Online Certificate Status Protocol (OCSP) (RFC 2560), and the =

Certificate Management Request Format (CRMF) (RFC 2511) have been =
approved, as=20
have profiles for the use of LDAP v2 for certificate and CRL storage =
(RFC 2587)=20
and the use of FTP and HTTP for transport of PKI operations (RFC 2585). =
RFC=20
2527, an informational RFC on guidelines for certificate policies and =
practices=20
also has been published, and the IESG has approved publication of an =
information=20
RFC on use of KEA (RFC 2528) and is expected to do the same for ECDSA. =
Work=20
continues on a second certificate management protocol, CMC, closely =
aligned with=20
the PKCS publications and with the cryptographic message syntax (CMS) =
developed=20
for S/MIME. A roadmap, providing a guide to the growing set of PKIX =
document, is=20
also being developed as an informational RFC. </DIV>
<P>The working group is now embarking on additional standards work to =
develop=20
protocols that are either integral to PKI management, or that are =
otherwise=20
closely related to PKI use. Work is ongoing on alternative certificate=20
revocation methods. There also is work defining conventions for =
certificate name=20
forms and extension usage for "qualified certificates," certificates =
designed=20
for use in (legally binding) non-repudiation contexts. Finally, work is =
underway=20
on protocols for time stamping and data certification. These protocols =
are=20
designed primarily to support non-repudiation, making use of =
certificates and=20
CRLs, and are so tightly bound to PKI use that they warrant coverage =
under this=20
working group.=20
<P>Additional work will be initiated on a profile for X.509 attribute=20
certificates, resulting in a new RFC and, perhaps, in extensions to =
existing=20
certificate management standards to accommodate differences between =
attribute=20
certificates and public-key certificates. </P>
<P>---------------------------------</P>
<P>Amended Text for Paragraph 2:</P>
<P>The working group is now embarking on additional standards work to =
develop=20
protocols that are either integral to PKI management, or that are =
otherwise=20
closely related to PKI use. Many of these standards are directly tied to =
end use=20
standards and where applicable, external input will be sought and =
factored into=20
the efforts. </P>
<P>These projects currently include a number of ancillary efforts like:=20
alternative certificate revocation methods; defining conventions for =
certificate=20
name forms and extension usage for "qualified certificates"; =
certificates=20
designed for use in (legally binding) non-repudiation contexts, and=20
NON-REPUDIATION Services like  time stamping and data =
certification.&nbsp; Many=20
of these&nbsp;protocols are designed primarily to support =
non-repudiation,=20
making use of certificates and CRLs, and are so tightly bound to PKI and =
end-use=20
models&nbsp;that their technology warrants coverage under this working =
group.=20
</P>
<P>&nbsp;</P>
<P>--------------------------------</P></FONT></BODY></HTML>

------=_NextPart_000_004F_01C01BCA.8338B7D0--



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10599 for <[e-mail]>; Mon, 11 Sep 2000 06:46:56 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA46604; Mon, 11 Sep 2000 15:53:31 +0200
Received: from bull.net (frpq6118.frpq.bull.fr [129.184.8.64]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA18884; Mon, 11 Sep 2000 15:48:13 +0200
Message-ID: <[e-mail]>
Date: Mon, 11 Sep 2000 15:48:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ,

I have been away from some time and I picked up your message. I fear
that your message, whatever its content is, has been addressed to
the wrong mailing list.

On Monday August 28, the IETF last call was launched by the IESG
with the following E-mail sent to the PKIX mailing list:

"The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet X.509 Public Key
Infrastructure Time Stamp Protocols (TSP)
<draft-ietf-pkix-time-stamp-09.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action.  Please send any comments to
the [e-mail] or [e-mail] mailing lists by September 8,
2000."

So your mail should have been addressed to the [e-mail] or
[e-mail] mailing lists by September 8, 2000. I hope you did so.

Denis

 
> Here are my comments on draft-ietf-pkix-time-stamp-09.  I have divided them
> into two categories: technical and editorial.  In my view, the technical
> changes are needed.  On the other hand, the editorial changes improve
> readability.
> 
> TECHNICAL
> 
> Section 2.1, 6th requirement.  I do not understand "hash-function
> OID."  OIDs, when managed correctly, are collision free.  I think we need
> to be discussing the one-way hash function, not its OID.  The selected
> one-way hash function must be uniquely identified by an OID.
> 
> Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says
> that the client SHOULD make the check, but that the client MAY elect to
> skip the check.  The checking requirement is either a SHOULD or a MAY, it
> cannot be both.
> 
> Section 2.4.1, reqPolicy Discussion.  I do not think that a reference to
> RFC 2459 is adequate.  First, I do not believe that a certification policy
> and a TSA policy are equivalent.  At a minimum, the TSA Policy and TSA
> Practice Statement will have significantly different content.  These
> differences need to be discussed.  Second, I would prefer syntax without
> qualifiers.  What value do they add in the TSA context?
> 
> Section 2.4.1, nonce Discussion.  Please replace "shall" with "MUST."
> 
> Section 2.4.2, 3rd paragraph.  The text does not match the comments in the
> ASN.1 structure.  I assume that the comments are correct.  Please
> rewrite.  I suggest:
>         "When status contains the value zero or one, a Time Stamp Token
>         MUST be present.  When status contains a value other than zero or
>         one, a Time Stamp Token MUST NOT be present.  One of the following
>         values MUST be contained in status:"
> 
> Section 2.4.2, 11th paragraph (counting paragraphs is difficult since the
> ASN.1 fragments are not indented).   Please replace "shall" with "MUST."
> 
> Section 2.4.2, serialNumber Discussion.  Please reword the last sentence to
> include a MUST.  I suggest: "This property MUST be preserved even after an
> interruption in service (e.g. crash)."
> 
> Section 2.4.2, genTime Discussion.  Please replace "shall" with
> "MUST."  There are at least five occurances.
> 
> Section 3.1.  How does the MIME type distinguish a time stamp request from
> a time stamp token?  The recipient must either decode a TimeStampReq or a
> ContentInfo, and this does not provide enough information to determine
> which operation to perform.
> 
> Section 3.2.  It would be helpful to specify file extensions for a time
> stamp request and a time stamp token.  Such extensions would permit the
> recipient to determine which decode to perform.
> 
> Section 3.3.  It would be useful to implementors to include the state
> machine for the TCP-based protocol.
> 
> Section 3.4.  How does the MIME type distinguish a time stamp request from
> a time stamp token?  The recipient must either decode a TimeStampReq or a
> ContentInfo, and this does not provide enough information to determine
> which operation to perform.
> 
> Section 4, item 4.  Each of the transports specified has different delay
> characteristics.  This should be pointed out.
> 
> EDITORIAL
> 
> Whole document.  Either add "SHALL" to the list of words that you say are
> defined in RFC 2119, or change "SHALL" to "MUST."
> 
> Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the second to
> last sentence.  It should say: "For more details about replay attack
> detection, see the security considerations section (item 6)."
> 
> Section 2.4.1, MessageImprint Definition.  I suggest the replacement of
> "hashedMessage" with "MessageHash."  To me, the current name implies the
> full message text rather than a hash of the message text.
> 
> Section 2.4.1, certReq Disscussion.  Typo.  Please move the comma.  The
> sentence should read: "If the certReq field is missing or if the certReq
> field is present and set to false, then ..."
> 
> Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the registry calls
> this OID id-ct-TSTInfo. Second, I think that it would be more readable to
> define it as follows:
>         id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
>                  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
> 
> Section 2.4.2, genTime Discussion.  Some require course granularity, others
> require fine granularity.  I suggest that a TSA MUST offer at least 1
> second granularity.  Filling in the genTime structure with "00" as the
> seconds does not meet this requirement.
> 
> Section 2.4.2, accuracy Discussion.  I think that a bit more discussion is
> needed.  the syntax permits the seconds and micros fields to be present and
> the millis to be absent.  I am not sure how to add and subtract such a
> structure.
> 
> Section 2.4.2, ordering Discussion.  Please replace the last sentence with:
> "... TSA can always be ordered based on the genTime field, regardless of
> the genTime accuracy.
> 
> Section 2.4.2, tsa Discussion.  Please change "an hint" to "a hint."
> 
> Section 4, item 6.  Please change "(algorithm and)" to "algorithm and."
> 
> Appendix A.  First, the registry calls this OID id-aa-timeStampToken.
> Second, I think that it would be more readable to define it as follows:
>         id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>                 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }


Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10410 for <[e-mail]>; Mon, 11 Sep 2000 06:40:55 -0700 (PDT)
Received: from HEMLOCK ([10.10.3.101]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RQJ8JSPP; Mon, 11 Sep 2000 06:36:17 -0700
Message-ID: <008601c01bf6$6b641600$[e-mail]>
Reply-To: "Steve Wang" <[e-mail]>
From: "Steve Wang" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Certificate request from P10 to PEM
Date: Mon, 11 Sep 2000 09:44:33 -0400
Organization: Entegrity Solutions
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Hello, there,

Are there any tools available to convert a certificate request from P10
format to PEM format?

Thank you in advance.

Steve



Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10268 for <[e-mail]>; Mon, 11 Sep 2000 06:31:39 -0700 (PDT)
From: [e-mail]
Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Mon, 11 Sep 2000 14:32:20 +0100
Received: by cbtlipnt01.btlabs.bt.co.uk  with Internet Mail Service (5.5.2652.35) id <SWKX79PR>; Mon, 11 Sep 2000 14:32:31 +0100
Message-ID: <[e-mail]>
To: [e-mail]
Subject: 
Date: Mon, 11 Sep 2000 14:31:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: text/plain

Unsubscribe


Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28327 for <[e-mail]>; Fri, 8 Sep 2000 11:52:24 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA15974; Fri, 8 Sep 2000 11:53:36 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 08 Sep 2000 14:46:21 -0400
To: Peter Sylvester <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Peter:

>- The draft references a non-existing or not-yet-existing feature
>   in 'son of 2459'. Is this allowed in a proposed standard?
>   I have asked that question a week ago to the iesg (no answer so far).

My understanding is that the time stamp document could not be published as 
an RFC until the son-of-RFC 2459 was also published.  They would come out 
together.

>- Should the security section mention the case of an active
>   attacker intercepts a response and provokes a network error
>   to the client, thus the attacker may later have
>   'earlier evidence' (whatever that would mean). Or, there
>   is no discussion at all about whether it is necessary to
>   authenticate the TSA, or about confidentiality.

This is a reasonable thing to include.

Russ



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26771 for <[e-mail]>; Fri, 8 Sep 2000 10:18:42 -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 NAA26254; Fri, 8 Sep 2000 13:20:29 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Qualified Certificates Profile to Proposed Standard
Reply-to: [e-mail]
Date: Fri, 08 Sep 2000 13:20:29 -0400
Sender: [e-mail]

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Internet X.509 Public Key
Infrastructure Qualified Certificates Profile
<draft-ietf-pkix-qc-06.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by September 22, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-06.txt


Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26170 for <[e-mail]>; Fri, 8 Sep 2000 09:58:42 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA26386 for <[e-mail]>; Fri, 8 Sep 2000 12:45:24 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 8 Sep 2000 12:54:55 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: CMC issues
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 98aGDEP2l6A3CJzSrqvkpg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Jim Schaad" <[e-mail]>
> 
> - It seems to me that the single round trip preference mentioned in 
> section 1 cannot come along with the industry practice of PKCS#10/PKCS#7
> 
> (mentioned in the same section). Proof of Identity may be supplied in 
> the full enrollment message (thus not using the PKCS#10 request) or 
> pending token must be returned (and having more then single round trip).
> 
> 
> <JLS>  Using the current PKCS#10/PKCS#7 resonse, there is no simple way 
> to do any proof of identity in a single round trip.  Note that you 
> cannot even return a pending token here so there is no standard way to 
> do a multiple trip proof. The Proof-of-Identity is normally done in some
> 
> external non-standard way (either entering the proof on the web 
> enrollment page or an external e-mail message are normal ways today) or 
> not at all under current industry practice.


So will CMC recommend that Proof-of-Identity be done in a non-standard
way or not at all, or will it recommend using the standard (full) way
of doing it?

CRMF was designed expressly to address the limitations of PKCS#10;
free-form web interfaces are fine for some purposes, but for others a
well-defined transaction interface with explicit data structures is
preferred.  The problem statement is "how can a client from one
vendor request a cert from a CA based on a different vendor's
product?".  I don't think suggesting that Checkpoint follow current
(non-standard) industry practice helps solve that problem.  If "the
normal ways today" are good enough, why bother writing CMC at all?

  Dave



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25921 for <[e-mail]>; Fri, 8 Sep 2000 09:53:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA03231 for <[e-mail]>; Fri, 8 Sep 2000 18:55:14 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 8 Sep 2000 18:55:14 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA14600 for <[e-mail]>; Fri, 8 Sep 2000 18:55:13 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA16013 for [e-mail]; Fri, 8 Sep 2000 18:55:12 +0200 (MET DST)
Date: Fri, 8 Sep 2000 18:55:12 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments

I had thought that my following three comments wouldn't be
worth to be mentioned in order not to disturb the process but
since lots of other stuff is coming to the surface, here they
are: 

- The draft references a non-existing or not-yet-existing feature
  in 'son of 2459'. Is this allowed in a proposed standard? 
  I have asked that question a week ago to the iesg (no answer so far).

- The direct socket protocol is not adjusted with the one in cmp, 
  this is unfortunate, shouldn't the protocol reference cmp. 
  
- Should the security section mention the case of an active
  attacker intercepts a response and provokes a network error
  to the client, thus the attacker may later have 
  'earlier evidence' (whatever that would mean). Or, there
  is no discussion at all about whether it is necessary to
  authenticate the TSA, or about confidentiality. 

Peter Sylvester
 



Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24726 for <[e-mail]>; Fri, 8 Sep 2000 08:47:04 -0700 (PDT)
Received: from tsg1 ([12.72.112.102]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000908154818.VABB17935.mtiwmhc21.worldnet.att.net@tsg1>; Fri, 8 Sep 2000 15:48:18 +0000
Message-ID: <006f01c019ac$2f9b7380$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
References: <[e-mail]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Date: Fri, 8 Sep 2000 08:48:07 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Hi all , might as well get this started here.

I have formally filed a request to stop the advancement of the TSP Protocol
to a Standard because it is still incomplete and in a number of senses,
broken.

Please read on.

----- Original Message -----
From: "Russ Housley" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, September 06, 2000 7:23 AM
Subject: draft-ietf-pkix-time-stamp-09 comments


> Here are my comments on draft-ietf-pkix-time-stamp-09.  I have divided
them
> into two categories: technical and editorial.  In my view, the technical
> changes are needed.

The TSP is still in and of itself incomplete.
------------------------------------------
I  am really concerned that significant changes are needed in the TSP BEFORE
it is advanced, and I have already posted to the IESG saying this as well as
the WG Chairs.

If it is to be used to create "evidentiary marques" then we had damn well
better define what the marques are and how they are used PRIOR to erecting a
standard on the API for how to create them.

New Evidentiary Focus
------------------------
This concern, since the 9.0 draft finally started to talk about "evidentiary
processes" is right on the money. What timestamps are is not simple
processes to verify signatures at a specific time, but rather mechanisms for
memorialiing events in time and space as an evidentiary process.

Poof! The whole world changes.

Now what is important is:
--------------------------
            o-    What Evidentiary Standards the model conforms to (US, UK,
who's else?)
            o-    How is the quality of the data inside the stamp token
assured and how its is obtained. (I.e. the chain of custody and audit trail,
and certification process for the data. BTW - This goes back to my concept
of TRUST ANCHORS)
            o-    The mechanisms through which stamps are made comparable to
each other (and thus made Portable)
            o-    And last but not least a recommendation on how to use the
damn things and a statement as to their limitations i.e. what they can and
cannot do for us with these use models...

> On the other hand, the editorial changes improve
> readability.
>
> TECHNICAL
>
> Section 2.1, 6th requirement.  I do not understand "hash-function
> OID."  OIDs, when managed correctly, are collision free.  I think we need
> to be discussing the one-way hash function, not its OID.  The selected
> one-way hash function must be uniquely identified by an OID.
>
> Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says
> that the client SHOULD make the check, but that the client MAY elect to
> skip the check.  The checking requirement is either a SHOULD or a MAY, it
> cannot be both.

Russ - I agree -  the word SHOULD is specific to a USE MODEL as it is a
recommedation . i.e If you are using this as XYZ then you SHOULD... The word
MAY creates an choice on the part of the user that is separate of the
recommendation. This is one of the confusing things in the "Restricted Word"
definitions. But in this instance since there is no USE MODEL for the TSP
Defined maybe both are appropriate.

>
> Section 2.4.1, reqPolicy Discussion.  I do not think that a reference to
> RFC 2459 is adequate.  First, I do not believe that a certification policy
> and a TSA policy are equivalent.  At a minimum, the TSA Policy and TSA
> Practice Statement will have significantly different content.  These
> differences need to be discussed.  Second, I would prefer syntax without
> qualifiers.  What value do they add in the TSA context?
>
> Section 2.4.1, nonce Discussion.  Please replace "shall" with "MUST."
>
> Section 2.4.2, 3rd paragraph.  The text does not match the comments in the
> ASN.1 structure.  I assume that the comments are correct.  Please
> rewrite.  I suggest:
> "When status contains the value zero or one, a Time Stamp Token
> MUST be present.  When status contains a value other than zero or
> one, a Time Stamp Token MUST NOT be present.  One of the following
> values MUST be contained in status:"
>
> Section 2.4.2, 11th paragraph (counting paragraphs is difficult since the
> ASN.1 fragments are not indented).   Please replace "shall" with "MUST."
>
> Section 2.4.2, serialNumber Discussion.  Please reword the last sentence
to
> include a MUST.  I suggest: "This property MUST be preserved even after an
> interruption in service (e.g. crash)."
>
> Section 2.4.2, genTime Discussion.  Please replace "shall" with
> "MUST."  There are at least five occurances.
>
> Section 3.1.  How does the MIME type distinguish a time stamp request from
> a time stamp token?  The recipient must either decode a TimeStampReq or a
> ContentInfo, and this does not provide enough information to determine
> which operation to perform.
>
> Section 3.2.  It would be helpful to specify file extensions for a time
> stamp request and a time stamp token.  Such extensions would permit the
> recipient to determine which decode to perform.
>
> Section 3.3.  It would be useful to implementors to include the state
> machine for the TCP-based protocol.
>
> Section 3.4.  How does the MIME type distinguish a time stamp request from
> a time stamp token?  The recipient must either decode a TimeStampReq or a
> ContentInfo, and this does not provide enough information to determine
> which operation to perform.
>
> Section 4, item 4.  Each of the transports specified has different delay
> characteristics.  This should be pointed out.
>
> EDITORIAL
>
> Whole document.  Either add "SHALL" to the list of words that you say are
> defined in RFC 2119, or change "SHALL" to "MUST."
>
> Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the second to
> last sentence.  It should say: "For more details about replay attack
> detection, see the security considerations section (item 6)."
>
> Section 2.4.1, MessageImprint Definition.  I suggest the replacement of
> "hashedMessage" with "MessageHash."  To me, the current name implies the
> full message text rather than a hash of the message text.
>
> Section 2.4.1, certReq Disscussion.  Typo.  Please move the comma.  The
> sentence should read: "If the certReq field is missing or if the certReq
> field is present and set to false, then ..."
>
> Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the registry calls
> this OID id-ct-TSTInfo. Second, I think that it would be more readable to
> define it as follows:
> id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
> rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}
>
> Section 2.4.2, genTime Discussion.  Some require course granularity,
others
> require fine granularity.  I suggest that a TSA MUST offer at least 1
> second granularity.  Filling in the genTime structure with "00" as the
> seconds does not meet this requirement.
>
> Section 2.4.2, accuracy Discussion.  I think that a bit more discussion is
> needed.  the syntax permits the seconds and micros fields to be present
and
> the millis to be absent.  I am not sure how to add and subtract such a
> structure.
>
> Section 2.4.2, ordering Discussion.  Please replace the last sentence
with:
> "... TSA can always be ordered based on the genTime field, regardless of
> the genTime accuracy.
>
> Section 2.4.2, tsa Discussion.  Please change "an hint" to "a hint."
>
> Section 4, item 6.  Please change "(algorithm and)" to "algorithm and."
>
> Appendix A.  First, the registry calls this OID id-aa-timeStampToken.
> Second, I think that it would be more readable to define it as follows:
> id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
> us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }
>



Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15731 for <[e-mail]>; Fri, 8 Sep 2000 05:17:58 -0700 (PDT)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A95EBD0152; Fri, 08 Sep 2000 14:19:42 +0200
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Fri, 08 Sep 2000 14:18:21 +0100
From: "Karl Scheibelhofer" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP support for historical reference to certificate suspension
Date: Fri, 8 Sep 2000 14:18:21 +0200
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

> Time-stamp of a third party are a possible way that can help if
> the parties
> have agreed in advance that this is the game to play, or when a law
> indicates that this would be sufficient.
>
> Would you consider the following procedure as time stamping?
> I sign something and indicate a date in it (an arbitrary one). You
> are the verifier, and you give me a co-signature indicating that
> you believe/agree with what I have signed.

if the verifier accepts your signature, it is all rigth and you two are in
business. but if your signature is legally binding (treated equally to a
handwritten signature according to law), is independent of this.

> > the first timestamp could prevent similar things. i could claim
> that i had
> > the key-pair before i received a certificate or before it got
> valid. i admit
> > this case is not as important as the previous one, because it is rarely
> > necessary to prove that i signed something after some date.
> nevertheless, i
> > would not ignore it.
>
> If you consider that not being allowed to sign while a cert is suspended
> and can be valid later, then this time is as important as the other one?

i am pleased to see that you agree.

> Instead of 'time stamps', one could also just use a OCSP responder to
> validate your cert putting the message or digest or whatever as a Nonce.
> Note that OCSP requests and responselist can be empty sequences,
> at least in the current syntax.

i prefer a timestamping authority to get a timestamp.

regards

  Karl



Received: from imail.mbs.gov.on.ca ([142.106.10.116]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA25684 for <[e-mail]>; Thu, 7 Sep 2000 12:58:59 -0700 (PDT)
Received: from MBSDOM04-Message_Server by imail.mbs.gov.on.ca with Novell_GroupWise; Thu, 07 Sep 2000 15:58:16 -0400
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.3
Date: Thu, 07 Sep 2000 15:48:09 -0400
From: "Eric Lawton" <[e-mail]>
To: <[e-mail]>
Subject: acceptable documentation
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 ns.secondary.com id MAA25685

As a new subscriber, I'm not aware if this subject has been discussed already.  I searched the archives, but was not able to find a relevant thread.

I'm wondering if there's support, on the basis of experience or formal policy, for our proposed requirement for authenticating LRA's to have the individual produce two pieces of ID from a list of primary identification and one item of ID from a secondary list.

On the primary list, GO-PKI will accept a Driver's license, passport, certificate of citizenship or Naturalization, Indian Status Band Card, or another document of identity issued by a government minitry or agency with a vigorous registration process or security clearance process.  (Note: birth certificates are not in this list)

On the secondary list, we will accept: bank account statements, ATM cards showing the subscriber's full name and signature, credit cards showing name and sig, accounts showing name and address, insurance renewal documents showing the same address as the subscribers application,marriage certificate issued by a government ministry or agency.

I'm hearing about resistance to the 2 primary ID requirement and a preference to go with 1 primary and 1 secondary due to the hassle of finding 2 pieces of ID.  Any comments or pointers to other jurisdictions' CPs that I can use as support?

I should also mention that the prospective LRA would also be put through an Enhanced Reliability Check which must include a finger print check and credit check prior to undertaking their LRA role.

Any comments would be appreciated.

Eric Lawton
PKI Security Advisor
iSERV ONTARIO




Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24615 for <[e-mail]>; Thu, 7 Sep 2000 12:10:38 -0700 (PDT)
Received: from tsg1 ([12.72.67.12]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20000907191143.GYNL17935.mtiwmhc21.worldnet.att.net@tsg1>; Thu, 7 Sep 2000 19:11:43 +0000
Message-ID: <003c01c018ff$73275ae0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: "Khaja Ahmed" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)
Date: Thu, 7 Sep 2000 12:11:37 -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.3018.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300

Doesn't it seem like a AD and the associated use model descriptions would
displace most all of this argument. What is going on here is the there a
number of orthogonal uses in people heads and since there is no one place to
point to and say - this is what it is and this is how its supposed to be
used in the real world... well what can I say.

Todd
----- Original Message -----
From: <[e-mail]>
To: "Michael Myers" <[e-mail]>
Cc: "Khaja Ahmed" <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 06, 2000 6:47 AM
Subject: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)


> Michael Myers writes ("Asymmetric OCSP"):
>
> >The concept applies best to the road warrior using IPSEC to securely
> >reach back home, to a customer site on a trouble call, etc..
> >Basically, during the IPSEC setup phase the IPSEC server or gateway
> >first checks the RW's cert by reference to an enterprise OCSP server.
> >There you get revocation/validation enforcement on the client.  The
> >server or gateway then turns around and asks the OCSP server for
> >status on it's (the gw's) cert, puts this into the handshake and so
> >delivers back to the client revocation/validation assurance.
>
> Perhaps I'm missing something, but this appears to suggest that the
> client is expected to accept the server's unexamined claim that its
> own cert is unrevoked.
>
> If the GW cert is being used to support the server's side of the IPSEC
> connection, then there is definitely a problem.
>
> David Boyce
>
> [e-mail]



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA05387 for <[e-mail]>; Thu, 7 Sep 2000 01:53:58 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA16179; Thu, 7 Sep 2000 10:55:38 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 7 Sep 2000 10:55:38 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA09066; Thu, 7 Sep 2000 10:55:37 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA15449; Thu, 7 Sep 2000 10:55:36 +0200 (MET DST)
Date: Thu, 7 Sep 2000 10:55:36 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspension

> 
> > I do not see in text that something is required to do something like
> > time stamping so that a verifier has some date to use to determine
> > the validity of a cert.
> 
> the second timestamp is absolutely required to achieve non-repudiation.
> otherwise i could easily revoke my certificate at any time and claim that
> someone other signed it afterwards. no one could prove the contrary without
> a timestamp.

Unless maybe the the other party in front of you has a gun. :-) 

Time-stamp of a third party are a possible way that can help if the parties
have agreed in advance that this is the game to play, or when a law
indicates that this would be sufficient. 

Would you consider the following procedure as time stamping?
I sign something and indicate a date in it (an arbitrary one). You
are the verifier, and you give me a co-signature indicating that
you believe/agree with what I have signed.


> the first timestamp could prevent similar things. i could claim that i had
> the key-pair before i received a certificate or before it got valid. i admit
> this case is not as important as the previous one, because it is rarely
> necessary to prove that i signed something after some date. nevertheless, i
> would not ignore it.

If you consider that not being allowed to sign while a cert is suspended
and can be valid later, then this time is as important as the other one?

Instead of 'time stamps', one could also just use a OCSP responder to
validate your cert putting the message or digest or whatever as a Nonce.
Note that OCSP requests and responselist can be empty sequences,
at least in the current syntax.



Received: from femail2.sdc1.sfba.home.com (femail2.sdc1.sfba.home.com [24.0.95.82]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03990 for <[e-mail]>; Thu, 7 Sep 2000 00:51:34 -0700 (PDT)
Received: from amdk6300 ([24.3.200.232]) by femail2.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20000907075304.NDWX27630.femail2.sdc1.sfba.home.com@amdk6300>; Thu, 7 Sep 2000 00:53:04 -0700
From: "Peter H. Gien" <[e-mail]>
To: "'Liaquat Khan'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RFC 2560 - OCSP - Clarification
Date: Sun, 7 Sep 1997 04:07:10 -0400
Message-ID: <001101bcbb65$0b40ac10$[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 CWS, Build 9.0.2212 (4.71.2419.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <000f01c01580$94c04680$851efea9@vaio>
Importance: Normal

Liaquat,

RFC 2560 is a technical specification that uses common English words such as
"good" in a strictly defined manner. If you're suggesting that the use of
handles in computer code might have legal implications, then I'm afraid
we're headed down a very slippery slope. I can just imagine lawyers
examining some of my code and trying to attach meaning to my variable names?
This is a ridiculous situation. Every technical discipline has its strictly
defined, context dependent vocabulary that can become highly amusing or
disastrous if taken in a universal context. So let's stick with the choice
of words in RFC2560.

	"The enemy of Good is Better"

Peter H. Gien


-----Original Message-----
From: Liaquat Khan [mailto:[e-mail]]
Sent: Sunday, September 03, 2000 4:26 AM
To: Denis Pinkas; Michael Myers
Cc: [e-mail]
Subject: Re: RFC 2560 - OCSP - Clarification


I tend to agree... a certificate status of "good" is a bit misleading, not
only from the viewpoint that the certificate may never been issued in the
first place, but also because it kind of implies that the certificate is
acceptable for a particular purpose.  It might be better to have a status of
"not-revoked", which simply means that the CA has not revoked the
certificate, for what ever reason  (i.e. either it never issued the
certificate in the first place or because the certificate is still valid).
>From a legal point of view this may be better for the CA, than claiming the
certificate is good.

Regards,
Liaquat Khan



----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: Liaquat Khan <[e-mail]>; <[e-mail]>
Sent: Saturday, September 02, 2000 5:34 PM
Subject: Re: RFC 2560 - OCSP - Clarification


> Michael,
>
> > Liaquat,
> >
> > Thanks for taking a careful look at 2560 regarding CRLs.  This thread
will
> > feed productively into 2560bis.
> >
> > But I do need to point out that OCSP does not, nor was ever intended, to
> > require the use of CRLs.
>
> As you said, OSCP does not require, but does allow the use of CRLs
> as the primary information used by the OCSP server to respond.
>
>
> > In fact, here are a few references from 2560 as
> > currently written:
> >
> > Abstract
> > "This document specifies a protocol useful in determining the current
status
> > of a digital certificate without requiring CRLs."
> >             ^^^^^^^^^^^^^^^^^^^^^^
> >
> > 2.  Protocol Overview
> > "OCSP may be used to satisfy some of the operational requirements of
> > providing more timely revocation information than is possible with CRLs
. .
> > . ."
> >                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Now, that said, 2560 does recognize that CRLs are a useful input to OCSP
and
> > so we made certain to accomodate that data source in the event that
> > periodically produced CRLs were the ONLY means by which an OCSP service
> > could be offered.  We enabled the use of CRL extensions to accomodate
> > environments where this feature was useful.
> >
> > But OCSP is and was primarly intended to address immediate timeliness, a
> > feature that is inherently beyond the scope of periodically produced
CRLs.
> >
>
> The problem is that the protocol does not take advantage of this
> feature. So the notion of "immediate timeliness" does not reaaly
> make sense, since anyway there is some delay in the overall process.
> A "good" status does not guarantee in any way that the certificate
> is presently "good", but only that it has not be declared to be
> revoked at some previous *undefined* time which may be a few
> minutes,
> hours (or even days) from the current time.
>
> So let me propose a "clarification" about the meaning of the "good"
> status.
>
>  The "good" state indicates a positive response to the status
>  inquiry. At a minimum, this positive response indicates
>  that the certificate  has not be declared or requested
>  to be revoked at some point  of time prior the current time,
>  and does not necessarily mean  that the certificate was
>  ever issued by the CA or that the time  at which the
>  response was produced is within the certificate's validity
>  interval.
>
> I do know that this definition gives less than the previous one, but
> it provides a better reality of the situation: no assurance that, at
> the time of the response, the private key is not compromised or the
> association between the key value and the content of the certificate
> is still correct.
>
> > 2560bis will clarify this intent.
>
> I think it is important to maintain that the use of CRLs as the
> primary information used by the OCSP server is one of the options to
> provide the real
> time information. So be *very* careful when making the
> "clarification".
>
> Denis
>
> P.S. Since in your message from August 31, you said:
>
> " Given the current work underway regarding 2560bis, I propose to
> include in
> the 2560bis work effort an optional "ValidAt" (or some such) field
> in the
> request syntax to accomodate this requirement."
>
> I do not support your proposal and I fear you are planning to change
> RFC 2560 by adding new functionality. So, here is my question: *In
> addition* to 2560bis, when are you expecting to provide a draft for
> OSCP extensions (i.e. OCSP-X) able to cover additional functionality
> ?
>
>
> > Mike
> >
> > > -----Original Message-----
> > > From: Liaquat Khan [mailto:[e-mail]]
> > > Sent: Wednesday, August 30, 2000 9:02 AM
> > > To: [e-mail]
> > > Subject: Re: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > The problem is linked to the fact that OCSP generally uses
> > > CRLs as the base
> > > information (although of course this doesn't have to be the
> > > case). And CRLs
> > > basically contain identifiers for those certificates that
> > > have been revoked
> > > (or suspended).  Therefore, if a particular certificates
> > > serial number is
> > > not on a CRL, it maybe because it is still valid or maybe
> > > because it was
> > > never issued in the first place.
> > >
> > > Note that the OCSP standard makes a reference that extensions
> > > should be used
> > > for providing additional information.
> > >
> > > Regards,
> > > Liaquat Khan
> > > Technical Manager
> > > Global Trust Authority
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Mathew Butler <[e-mail]>
> > > To: 'Rich Salz' <[e-mail]>; Sam Schaen
> > > <[e-mail]>;
> > > <[e-mail]>
> > > Sent: Monday, August 28, 2000 9:13 PM
> > > Subject: RE: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > > I think that there's a problem with this idea.  If the
> > > responder doesn't
> > > > know about the CA, or have the ability to verify the CA's
> > > signature on the
> > > > certificate versus the CRL, the response should be
> > > "unknown" rather than
> > > > "good".
> > > >
> > > > "Good" should indicate: "The certificate was apparently
> > > issued by a CA
> > > that
> > > > the responder has current revocation information for, and
> > > the certificate
> > > > has not been revoked."
> > > >
> > > > Forgive me for not reading the draft as thoroughly as I
> > > should have; is
> > > > there any call for the responder to cryptographically check the
> > > certificate
> > > > at any point during the request?
> > > >
> > > > -Mat Butler
> > > >
> > > > -----Original Message-----
> > > > From: Rich Salz [mailto:[e-mail]]
> > > > Sent: Monday, August 28, 2000 8:08 AM
> > > > To: Sam Schaen
> > > > Cc: '[e-mail]'
> > > > Subject: Re: RFC 2560 - OCSP - Clarification
> > > >
> > > >
> > > > The text in uppercase is contradicted by the sentence that
> > > immediately
> > > > follows.  If good doesn't mean the certificate was issued,
> > > then there
> > > > need not be a CA that issued it. :)
> > > >
> > > >
> > > > > 'The "good" state indicates that THE RESPONDER HAS
> > > CURRENT REVOCATION
> > > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND
> > > the certificate
> > > > has not
> > > > > been revoked. It
> > > > > does not indicate whether the certificate was ever
> > > issued, is still
> > > valid
> > > > or
> > > > > any other assertion.
> > > >
> > >
>
>
>



Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01275 for <[e-mail]>; Wed, 6 Sep 2000 23:09:03 -0700 (PDT)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A165EB601B2; Thu, 07 Sep 2000 08:10:45 +0200
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Thu, 07 Sep 2000 08:09:36 +0100
From: "Karl Scheibelhofer" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP support for historical reference to certificate suspension
Date: Thu, 7 Sep 2000 08:09:36 +0200
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>

> I do not see in text that something is required to do something like
> time stamping so that a verifier has some date to use to determine
> the validity of a cert.

the second timestamp is absolutely required to achieve non-repudiation.
otherwise i could easily revoke my certificate at any time and claim that
someone other signed it afterwards. no one could prove the contrary without
a timestamp.
the first timestamp could prevent similar things. i could claim that i had
the key-pair before i received a certificate or before it got valid. i admit
this case is not as important as the previous one, because it is rarely
necessary to prove that i signed something after some date. nevertheless, i
would not ignore it.

  Karl



Received: from home.x509.com (home.x509.com [199.175.150.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17713 for <[e-mail]>; Wed, 6 Sep 2000 17:42:11 -0700 (PDT)
Received: from xcert.com (saxifrage.x509.com [199.175.148.75]) by home.x509.com (8.10.0/XCERT) with ESMTP id e870hkp16174 for <[e-mail]>; Wed, 6 Sep 2000 17:43:46 -0700 (PDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 06 Sep 2000 19:59:53 -0700
From: Marc Branchaud <[e-mail]>
Organization: Xcert International Inc.
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.10 i686)
X-Accept-Language: en, fr
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP in S/MIME and IPSEC
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This idea is very useful, but it's important to keep in mind that it isn't
applicable in all situations.

In particular, it breaks down when the client and the server/gateway don't
trust the same entities.  The server/gateway may be able to get an OCSP
server to sign off on its certificate, but that's useless unless the client
somehow trusts that OCSP server.

So while embedding OCSP responses works fine for road-warriors and similar
situations, where both parties belong to the same trust domain (so to speak),
it doesn't work when a client from one domain wishes to authenticate a server
in another domain.

I don't mean for this to be a show-stopper or anything, but I do think any
specification of such a system has to be clear about where things break down.

		M.

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [e-mail]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1


Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13720 for <[e-mail]>; Wed, 6 Sep 2000 16:18:21 -0700 (PDT)
Received: from revelation (ip186.du1.bel.nwlink.com [209.20.136.186]) by smtp.nwlink.com (8.9.3/8.9.1) with SMTP id QAA19038; Wed, 6 Sep 2000 16:19:44 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Avi Gozlan'" <[e-mail]>
Cc: "IETF-PKIX" <[e-mail]>
Subject: RE: CMC issues
Date: Wed, 6 Sep 2000 16:20:20 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C0181E.A8B71470"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

This is a multi-part message in MIME format.

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

Avi,

-- see below for answers

Hi,

After reading CMC, I have got questions about the standard. Comments are
welcomed.

- ASN.1 module issues:
1. In the module, pendToken in pendInfo is defined to be an INTEGER,
while queryPending is defined as OCTET STRING in 5.13.

<JLS> This is an editing error.  The correct value in the module should
be OCTET STRING.  This is on the list of updates for the revised version
of the document.

2. The definition of bodyList in 5.1 is "SEQUENCE SIZE (1..MAX) OF
BodyPartID" while in the module it is defined as "SEQUENCE SIZE (1..MAX)
OF INTEGER"

<JLS> The text is correct for this item.  This has been appended to the
list of corrctions for the document.

3. The module imports AttributeCertificate and CertificateList. Both are
superfluous.

<JLS> Noted and will be removed in the next version.

- Use of SHA1 is hard coded in section 5.2. This does not leave the
standard open for other hash algorithms. Are there any plans to change
this?

<JLS> There has already been discussion about this issue on the mail
list.  THere are no plans to change this to allow for arbitrary hash
algorithms in this location.  If a new hash algorithm is required (i.e.
SHA1 becomes really broken) then a new control attribute would be
defined with a new fixed hash algorithm.  Allowing for different hash
algorithms here would also require the ability to discover this
information.

- If the shared secret method is used as proof of identity, it may be
exposed to off line dictionary attack (if supplied by the user). Usually
such an attack becomes harder by enforcing expensive computation for
each trial of a shared secret (computation of the hash 1000 times or
so). The CMC standard does not use this technique. It should at least
state that the shared secret must be randomly chosen (not a user
supplied password).
This attack is usually meaningless, as the shared secret is used only
once, however, if the initial enrollment request fails, the same secret
may be used in following requests (the standard does not require
replacement of it). As mentioned, a requirement of randomly chosen
secret may solve this.

<JLS>  Noted in the update documented comment list.

- It seems to me that the single round trip preference mentioned in
section 1 cannot come along with the industry practice of PKCS#10/PKCS#7
(mentioned in the same section). Proof of Identity may be supplied in
the full enrollment message (thus not using the PKCS#10 request) or
pending token must be returned (and having more then single round trip).

<JLS>  Using the current PKCS#10/PKCS#7 resonse, there is no simple way
to do any proof of identity in a single round trip.  Note that you
cannot even return a pending token here so there is no standard way to
do a multiple trip proof. The Proof-of-Identity is normally done in some
external non-standard way (either entering the proof on the web
enrollment page or an external e-mail message are normal ways today) or
not at all under current industry practice.

- According to the standard, the crm is signed (otherwise, there is no
meaning to the addition of the idPOPLinkWitness in the control section
of crm as described in 5.3.1). On the other side the full enrollment
request is signed, as described in section 4.2. In a case of renewal,
both signatures are required (the crm/pkcs10 are signed by the new key,
the whole message is signed by the old key). In the initial enrollment,
though, there is one redundant signature.

<JLS> The signature may or may not be redundant, however there are no
plans to remove the extra signature so that the structure and processing
of the message is consistant independent of the renewal/initial
enrollment processing.

Avi
--
Avi Gozlan
Encryption Group, R&D
Check Point Software Tech. Ltd
e-mail: [e-mail]




------=_NextPart_000_0009_01C0181E.A8B71470
Content-Type: text/html;
	charset="iso-8859-1"
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=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4208.0">
<TITLE>RE: CMC issues</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Avi,</FONT>
</P>

<P><FONT SIZE=3D2>-- see below for answers</FONT>
</P>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>After reading CMC, I have got questions about the =
standard. Comments are</FONT>

<BR><FONT SIZE=3D2>welcomed.</FONT>
</P>

<P><FONT SIZE=3D2>- ASN.1 module issues:</FONT>

<BR><FONT SIZE=3D2>1. In the module, pendToken in pendInfo is defined to =
be an INTEGER,</FONT>

<BR><FONT SIZE=3D2>while queryPending is defined as OCTET STRING in =
5.13.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;JLS&gt; This is an editing error.&nbsp; The =
correct value in the module should</FONT>

<BR><FONT SIZE=3D2>be OCTET STRING.&nbsp; This is on the list of updates =
for the revised version</FONT>

<BR><FONT SIZE=3D2>of the document.</FONT>
</P>

<P><FONT SIZE=3D2>2. The definition of bodyList in 5.1 is &quot;SEQUENCE =
SIZE (1..MAX) OF</FONT>

<BR><FONT SIZE=3D2>BodyPartID&quot; while in the module it is defined as =
&quot;SEQUENCE SIZE (1..MAX)</FONT>

<BR><FONT SIZE=3D2>OF INTEGER&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&lt;JLS&gt; The text is correct for this item.&nbsp; =
This has been appended to the</FONT>

<BR><FONT SIZE=3D2>list of corrctions for the document.</FONT>
</P>

<P><FONT SIZE=3D2>3. The module imports AttributeCertificate and =
CertificateList. Both are</FONT>

<BR><FONT SIZE=3D2>superfluous.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;JLS&gt; Noted and will be removed in the next =
version.</FONT>
</P>

<P><FONT SIZE=3D2>- Use of SHA1 is hard coded in section 5.2. This does =
not leave the</FONT>

<BR><FONT SIZE=3D2>standard open for other hash algorithms. Are there =
any plans to change</FONT>

<BR><FONT SIZE=3D2>this?</FONT>
</P>

<P><FONT SIZE=3D2>&lt;JLS&gt; There has already been discussion about =
this issue on the mail</FONT>

<BR><FONT SIZE=3D2>list.&nbsp; THere are no plans to change this to =
allow for arbitrary hash</FONT>

<BR><FONT SIZE=3D2>algorithms in this location.&nbsp; If a new hash =
algorithm is required (i.e.</FONT>

<BR><FONT SIZE=3D2>SHA1 becomes really broken) then a new control =
attribute would be</FONT>

<BR><FONT SIZE=3D2>defined with a new fixed hash algorithm.&nbsp; =
Allowing for different hash</FONT>

<BR><FONT SIZE=3D2>algorithms here would also require the ability to =
discover this</FONT>

<BR><FONT SIZE=3D2>information.</FONT>
</P>

<P><FONT SIZE=3D2>- If the shared secret method is used as proof of =
identity, it may be</FONT>

<BR><FONT SIZE=3D2>exposed to off line dictionary attack (if supplied by =
the user). Usually</FONT>

<BR><FONT SIZE=3D2>such an attack becomes harder by enforcing expensive =
computation for</FONT>

<BR><FONT SIZE=3D2>each trial of a shared secret (computation of the =
hash 1000 times or</FONT>

<BR><FONT SIZE=3D2>so). The CMC standard does not use this technique. It =
should at least</FONT>

<BR><FONT SIZE=3D2>state that the shared secret must be randomly chosen =
(not a user</FONT>

<BR><FONT SIZE=3D2>supplied password).</FONT>

<BR><FONT SIZE=3D2>This attack is usually meaningless, as the shared =
secret is used only</FONT>

<BR><FONT SIZE=3D2>once, however, if the initial enrollment request =
fails, the same secret</FONT>

<BR><FONT SIZE=3D2>may be used in following requests (the standard does =
not require</FONT>

<BR><FONT SIZE=3D2>replacement of it). As mentioned, a requirement of =
randomly chosen</FONT>

<BR><FONT SIZE=3D2>secret may solve this.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;JLS&gt;&nbsp; Noted in the update documented =
comment list.</FONT>
</P>

<P><FONT SIZE=3D2>- It seems to me that the single round trip preference =
mentioned in</FONT>

<BR><FONT SIZE=3D2>section 1 cannot come along with the industry =
practice of PKCS#10/PKCS#7</FONT>

<BR><FONT SIZE=3D2>(mentioned in the same section). Proof of Identity =
may be supplied in</FONT>

<BR><FONT SIZE=3D2>the full enrollment message (thus not using the =
PKCS#10 request) or</FONT>

<BR><FONT SIZE=3D2>pending token must be returned (and having more then =
single round trip).</FONT>
</P>

<P><FONT SIZE=3D2>&lt;JLS&gt;&nbsp; Using the current PKCS#10/PKCS#7 =
resonse, there is no simple way</FONT>

<BR><FONT SIZE=3D2>to do any proof of identity in a single round =
trip.&nbsp; Note that you</FONT>

<BR><FONT SIZE=3D2>cannot even return a pending token here so there is =
no standard way to</FONT>

<BR><FONT SIZE=3D2>do a multiple trip proof. The Proof-of-Identity is =
normally done in some</FONT>

<BR><FONT SIZE=3D2>external non-standard way (either entering the proof =
on the web</FONT>

<BR><FONT SIZE=3D2>enrollment page or an external e-mail message are =
normal ways today) or</FONT>

<BR><FONT SIZE=3D2>not at all under current industry practice.</FONT>
</P>

<P><FONT SIZE=3D2>- According to the standard, the crm is signed =
(otherwise, there is no</FONT>

<BR><FONT SIZE=3D2>meaning to the addition of the idPOPLinkWitness in =
the control section</FONT>

<BR><FONT SIZE=3D2>of crm as described in 5.3.1). On the other side the =
full enrollment</FONT>

<BR><FONT SIZE=3D2>request is signed, as described in section 4.2. In a =
case of renewal,</FONT>

<BR><FONT SIZE=3D2>both signatures are required (the crm/pkcs10 are =
signed by the new key,</FONT>

<BR><FONT SIZE=3D2>the whole message is signed by the old key). In the =
initial enrollment,</FONT>

<BR><FONT SIZE=3D2>though, there is one redundant signature.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;JLS&gt; The signature may or may not be redundant, =
however there are no</FONT>

<BR><FONT SIZE=3D2>plans to remove the extra signature so that the =
structure and processing</FONT>

<BR><FONT SIZE=3D2>of the message is consistant independent of the =
renewal/initial</FONT>

<BR><FONT SIZE=3D2>enrollment processing.</FONT>
</P>

<P><FONT SIZE=3D2>Avi</FONT>

<BR><FONT SIZE=3D2>--</FONT>

<BR><FONT SIZE=3D2>Avi Gozlan</FONT>

<BR><FONT SIZE=3D2>Encryption Group, R&amp;D</FONT>

<BR><FONT SIZE=3D2>Check Point Software Tech. Ltd</FONT>

<BR><FONT SIZE=3D2>e-mail: [e-mail]</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0009_01C0181E.A8B71470--



Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13708 for <[e-mail]>; Wed, 6 Sep 2000 16:18:18 -0700 (PDT)
Received: from revelation (ip186.du1.bel.nwlink.com [209.20.136.186]) by smtp.nwlink.com (8.9.3/8.9.1) with SMTP id QAA19047; Wed, 6 Sep 2000 16:19:49 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Avi Gozlan'" <[e-mail]>
Cc: "IETF-PKIX" <[e-mail]>
Subject: RE: CMC transport
Date: Wed, 6 Sep 2000 16:22:24 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0181E.ABB7D150"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700

This is a multi-part message in MIME format.

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

Avi,

-----Original Message-----
From: Avi Gozlan [mailto:[e-mail]]
Posted At: Wednesday, September 06, 2000 2:57 AM
Posted To: New-PKIX
Conversation: CMC transport
Subject: CMC transport
Importance: High


Hi,

Is there any port allocated for CMC? Are there any wrapping protocol (as
in CMP)? If using HTTP, what are the details of the protocol used
(whether to use POST or not, whether to maintain the connection open in
the case of more then one single trip etc.)?

1. No ports have been allocated for CMC.
2. HTTP details are going to need to be worked out and are currently not
specified. (I have not gotten that far on my implementation yet.)

Avi

--
Avi Gozlan
Encryption Group, R&D
Check Point Software Tech. Ltd
e-mail: [e-mail]







------=_NextPart_000_000D_01C0181E.ABB7D150
Content-Type: text/html;
	charset="iso-8859-1"
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=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4208.0">
<TITLE>RE: CMC transport</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Avi,</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: Avi Gozlan [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>

<BR><FONT SIZE=3D2>Posted At: Wednesday, September 06, 2000 2:57 =
AM</FONT>

<BR><FONT SIZE=3D2>Posted To: New-PKIX</FONT>

<BR><FONT SIZE=3D2>Conversation: CMC transport</FONT>

<BR><FONT SIZE=3D2>Subject: CMC transport</FONT>

<BR><FONT SIZE=3D2>Importance: High</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Is there any port allocated for CMC? Are there any =
wrapping protocol (as</FONT>

<BR><FONT SIZE=3D2>in CMP)? If using HTTP, what are the details of the =
protocol used</FONT>

<BR><FONT SIZE=3D2>(whether to use POST or not, whether to maintain the =
connection open in</FONT>

<BR><FONT SIZE=3D2>the case of more then one single trip etc.)?</FONT>
</P>

<P><FONT SIZE=3D2>1. No ports have been allocated for CMC.</FONT>

<BR><FONT SIZE=3D2>2. HTTP details are going to need to be worked out =
and are currently not</FONT>

<BR><FONT SIZE=3D2>specified. (I have not gotten that far on my =
implementation yet.)</FONT>
</P>

<P><FONT SIZE=3D2>Avi</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>

<BR><FONT SIZE=3D2>Avi Gozlan</FONT>

<BR><FONT SIZE=3D2>Encryption Group, R&amp;D</FONT>

<BR><FONT SIZE=3D2>Check Point Software Tech. Ltd</FONT>

<BR><FONT SIZE=3D2>e-mail: [e-mail]</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------=_NextPart_000_000D_01C0181E.ABB7D150--



Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19166 for <[e-mail]>; Wed, 6 Sep 2000 11:02:28 -0700 (PDT)
Received: from mega (t2o69p10.telia.com [62.20.144.130]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id UAA27502; Wed, 6 Sep 2000 20:04:00 +0200 (CEST)
Message-ID: <002c01c01835$121ede00$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: Comment on AttributeCertificate draft
Date: Wed, 6 Sep 2000 21:02:54 +0200
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 ns.secondary.com id LAA19167

Ron

<snip>
>X.509 certificates can be used as SPKI certificates and therefore there is no limit.
>However, the typical application of PKI was for a long time thought to be where
>a user has a (i.e. single) PKC, as you call it. This PKC is posted in a
>directory with a name to certificate mapping and the certificate contained no
>authorizations. Granted, this is just a typical application.

A single PKC is IMO a very good thing for the user.  I only have one credit-card
and it allows me to pay in 99% of all credit-card-enabled shops.  Why would I get "the other brand" as well?
Would be a waste of wallet-space.

To post the certificate in a public directory is on the other hand a bad thing due
to privacy reasons.  An unnesseary as well unless it is posted together with other
subject data which would be even more privacy-depriving.  Individual RP's
may though put certificates in directories occassionaly.


>Now, it is clear that for inter-enterprise, or inter-organizational
>communications, that directory entry and associated profile will be meaningless
>because there will be no access to it from outside the organization.


Agreed. 


>Its also clear that this type of communication needs to be secure on the network
>layer as well as the application layer. IP traffic will need to be authorized
>first to go through. After that the application layer, say an XML parser, would
>decide whether the specifically requested operation is authorized to the
>key-holder since IP layer cannot necessarily make this decision.
>What was suggested below means that the communication on the IP level is not
>secured, as this is what I understand.


I don't follow this.  SSL-level security with server (receiver)-authentication should be
enough for transmitting signed XML-documents.  This is at least what is used 
commercially today. 

>Another example is where QoS guarantees need to be made on RSVPed  traffic
>flowing from a user connected to an ISP to an organization. Also consider a
>small regional office of an organization with a broadband connection to a local
>ISP. How about extranet access? It could be a video conference, IP telephony.
>Would you imagine not being able to speak on the phone with anyone outside your
>organization? SPKI claims that doing this "conservatively" would not be
>scalable.


Question: Is this in conflict with organization-signed XML-documents over SSL?


>Authorizations cross organizational boundaries, as traffic does. That's the
>nature of the internet. So, I do not think it would be rare.
>Let us avoid the pitfalls outlined in SPKI theory and come up with something
>which can scale globally

Which XML-documents (containing authorizations, credentials) signed by organizations
should be able to do.

The thing that make PKI not scale is the totally obsolete idea saying that you must have an unbroken
"PKI-connection" from an individual belonging to one organization authenticating to another organization.

That idea made SET (Safe Electronic Transaction) kill itself under its own weight.   VISA has fortunately
abandoned SET 1.0 in favour of a solution that deviates from classic PKI that will (soon) prove that PKI
scales well if not implemented exactly as it is written in the book (X500).

PKI-approaches like VISA's make ACs (and SPKI) less likely to succeed.  Particularly
when augmented with XML schemas.  The latter BTW makes ASN.1 look like stone-age.

Regards
Anders



Received: from indy.gradient.com ([e-mail] [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18669 for <[e-mail]>; Wed, 6 Sep 2000 10:46:32 -0700 (PDT)
Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id NAA02310; Wed, 6 Sep 2000 13:48:09 -0400 (EDT)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id <R9CM8XMR>; Wed, 6 Sep 2000 13:41:28 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Mitchell Arnone'" <[e-mail]>, IETF-PKIX LIST <[e-mail]>
Subject: RE: Key Usage - Intended Usage
Date: Wed, 6 Sep 2000 13:41:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

You will be happy to hear that this mailing list has had all of the same
arguments, with little resolution. Check the archives back 12-24 months.

Hal

=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [e-mail]
F: 1-508-229-0338             www.entegrity.com
=======================================================


> -----Original Message-----
> From: Mitchell Arnone [mailto:[e-mail]]
> Sent: Wednesday, September 06, 2000 1:31 PM
> To: IETF-PKIX LIST
> Subject: Key Usage - Intended Usage
> 
> 
> It is my understanding that certificates issued for use with Privacy
> Enhanced Mail (PEM) and/or S/MIME should include the Key 
> Usage extension
> with the "keyEncipherment" bit set.  However, I have been 
> challenged by
> management to find proof that this is so.  I have looked in rfc 1421,
> 1422, 1521, PKCS7 and nowhere is there documented a 
> requirement or even
> a recommendation stating that certificates used for PEM and/or S/MIME
> applications should require this extension and bit.  While it 
> may appear
> obvious, after reading the standards identifying key encipherment as
> part of the process, I still need something more specific.  Can anyone
> shed some light for me?
> 
> So much of PKI seems to be left up to interpretation with little or no
> supporting evidence that can be used by an organization to justify a
> particular strategy as being standards based.  Many have a real
> love/hate relationship with PKI  and I believe that it is because,
> though this is great technology, without well defined (less ambiguity)
> and openly supported (and enforced) standards, it is hard to build and
> sell.
> 
> Another good example of our frustration is non-repudiation.  This bit
> has spawned many intense discussions pertaining to its intended use as
> well as proper configuration/implementation (used with the digital
> signature bit enabled as well or not).  Some argue that 
> non-repudiation
> can be established without this bit set so why set it at all. 
>  Some have
> said that this bit should trigger some action on the part of the
> application to verify that non-repudiation will result if the user
> intends to "proceed to the next step" (digital signature) in a
> particular process and still others think that it is intended 
> to be used
> by organizations as a means to restrict a particular certificate to a
> specific use (keep some "high value" signature certs (key pair) from
> being used for day-to-day authentication or signing personal email and
> etc.).  Any opinions on this?
> 
> Mitch Arnone
> ***************
> PKI Engineer
> [e-mail]
> 
> 
> 
> 


Received: from mailhost.tdpt.net ([63.146.0.238]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17927 for <[e-mail]>; Wed, 6 Sep 2000 10:31:09 -0700 (PDT)
Received: from tidepoint.net ([192.168.10.52]) by mailhost.tdpt.net (Netscape Messaging Server 4.15) with ESMTP id G0H7E600.3A0 for <[e-mail]>; Wed, 6 Sep 2000 13:32:30 -0400 
Message-ID: <[e-mail]>
Date: Wed, 06 Sep 2000 13:31:29 -0400
From: "Mitchell Arnone" <[e-mail]>
Organization: TidePoint
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF-PKIX LIST <[e-mail]>
Subject: Key Usage - Intended Usage
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDA0E587CCEBDF994FF914A0D"

This is a cryptographically signed message in MIME format.

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

It is my understanding that certificates issued for use with Privacy
Enhanced Mail (PEM) and/or S/MIME should include the Key Usage extension
with the "keyEncipherment" bit set.  However, I have been challenged by
management to find proof that this is so.  I have looked in rfc 1421,
1422, 1521, PKCS7 and nowhere is there documented a requirement or even
a recommendation stating that certificates used for PEM and/or S/MIME
applications should require this extension and bit.  While it may appear
obvious, after reading the standards identifying key encipherment as
part of the process, I still need something more specific.  Can anyone
shed some light for me?

So much of PKI seems to be left up to interpretation with little or no
supporting evidence that can be used by an organization to justify a
particular strategy as being standards based.  Many have a real
love/hate relationship with PKI  and I believe that it is because,
though this is great technology, without well defined (less ambiguity)
and openly supported (and enforced) standards, it is hard to build and
sell.

Another good example of our frustration is non-repudiation.  This bit
has spawned many intense discussions pertaining to its intended use as
well as proper configuration/implementation (used with the digital
signature bit enabled as well or not).  Some argue that non-repudiation
can be established without this bit set so why set it at all.  Some have
said that this bit should trigger some action on the part of the
application to verify that non-repudiation will result if the user
intends to "proceed to the next step" (digital signature) in a
particular process and still others think that it is intended to be used
by organizations as a means to restrict a particular certificate to a
specific use (keep some "high value" signature certs (key pair) from
being used for day-to-day authentication or signing personal email and
etc.).  Any opinions on this?

Mitch Arnone
***************
PKI Engineer
[e-mail]




--------------msDA0E587CCEBDF994FF914A0D
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

MIIIKwYJKoZIhvcNAQcCoIIIHDCCCBgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcwwggLXMIICQKADAgECAhEArBkEZgAAAnwAAAAVAAAACTANBgkqhkiG9w0BAQUFADCBtjEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCE1hcnlsYW5kMRIwEAYDVQQHEwlCYWx0aW1vcmUxHjAc
BgNVBAoTFVRpZGVQb2ludCBDb3Jwb3JhdGlvbjEMMAoGA1UECxMDUEtJMR8wHQYDVQQDExZU
aWRlUG9pbnQgQ29ycG9yYXRlIENBMTEwLwYJKoZIhvcNAQkBFiJicmlhbi5kaWxsZXlAYjJi
Y29tbXVuaWNhdGlvbnMuY29tMB4XDTAwMDgwMTE0NTcxNloXDTAzMDcwMzIwMTgxNlowgYox
CzAJBgNVBAYTAnVzMREwDwYDVQQIEwhNYXJ5bGFuZDESMBAGA1UEBxMJQmFsdGltb3JlMR4w
HAYDVQQKExVUaWRlUG9pbnQgQ29ycG9yYXRpb24xDDAKBgNVBAsTA1BLSTEmMCQGA1UEAxMd
TWl0Y2hlbGwgVCBBcm5vbmUgKFNpZ25hdHVyZSkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBALRwJhDwGHIxVV5FNHITbjGCeccK70+6vZ5xegTDflWwoJXb2T1eEqHZTZ+NUmgHTaNj
ckbS4RP0CbO7bnthENbknm/dj77gzMQy1ouZgctMNbkR9ktry4MGvn1sNkCnNJD4I5eRlWuw
FDIwn3OB8Q4Mm45omq9+9TWeSKYzRJbJAgMBAAGjDzANMAsGA1UdDwQEAwIHgDANBgkqhkiG
9w0BAQUFAAOBgQCHSm7EfCrk9ZDWvKxTbu4xWgCq+z2unLCnI2lSU8QJpRtqk1qfrCx1ZoE7
C6kcef+oo36NNJQWSX6lI6IvwA0GRM20aW/J11keuiZvNnOG2xqYbp8GAtiCpY2c4j06a1wW
JyHLiPrT+APVq+9HGYv+aC1a9q7hXHHd4Z3yZWaSWTCCAu0wggJWAhEArBkEZQAAAnwAAAAC
AAAABDANBgkqhkiG9w0BAQUFADCBtjELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE1hcnlsYW5k
MRIwEAYDVQQHEwlCYWx0aW1vcmUxHjAcBgNVBAoTFVRpZGVQb2ludCBDb3Jwb3JhdGlvbjEM
MAoGA1UECxMDUEtJMRwwGgYDVQQDExNUaWRlUG9pbnQgUHJpbmNpcGxlMTQwMgYJKoZIhvcN
AQkBFiVtaXRjaGVsbC5hcm5vbmVAYjJiY29tbXVuaWNhdGlvbnMuY29tMB4XDTAwMDcwNjIw
MTk1N1oXDTAzMDcwNjIwMTk1N1owgbYxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNYXJ5bGFu
ZDESMBAGA1UEBxMJQmFsdGltb3JlMR4wHAYDVQQKExVUaWRlUG9pbnQgQ29ycG9yYXRpb24x
DDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWVGlkZVBvaW50IENvcnBvcmF0ZSBDQTExMC8GCSqG
SIb3DQEJARYiYnJpYW4uZGlsbGV5QGIyYmNvbW11bmljYXRpb25zLmNvbTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEA1/CKGYEMULAuj6+5EYuFl1R6NvmslYywzTFL5suvKNeEH5rA
jH8jlV6qv7ugoryeL+130Atsh1muS+bKDYUTg+eCSNTZ0G0Pi4qLzzNwZPxTk7prJvErD0b8
3ByEZb+7LJ0wXeI5TxU8n2sLWecHKnXmQTpVrxA6Ub0uOxFbbKsCAwEAATANBgkqhkiG9w0B
AQUFAAOBgQBIAW6ADXwSIanrFKnX66xdWXlblwc2pfasIr3uDrPBRSpwrvt8RyCM+eWUByAi
G03AD+y40G0hdMEoljZMgZabeZ5fwtM3zLm13z9G/ec7oU2jUNy7N9MQ6HNg8kd2kDNNoSDR
yG1sYLPBSIPgtghDZg2MnxBxc40GVDzxaUXVGzGCAicwggIjAgEBMIHMMIG2MQswCQYDVQQG
EwJVUzERMA8GA1UECBMITWFyeWxhbmQxEjAQBgNVBAcTCUJhbHRpbW9yZTEeMBwGA1UEChMV
VGlkZVBvaW50IENvcnBvcmF0aW9uMQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFlRpZGVQb2lu
dCBDb3Jwb3JhdGUgQ0ExMTAvBgkqhkiG9w0BCQEWImJyaWFuLmRpbGxleUBiMmJjb21tdW5p
Y2F0aW9ucy5jb20CEQCsGQRmAAACfAAAABUAAAAJMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDAwOTA2MTczMTI5WjAjBgkqhkiG
9w0BCQQxFgQUWh25QxBPeFu771SwLepqmNYvNwQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN
AwICASgwDQYJKoZIhvcNAQEBBQAEgYBD3MghaHLXD9JHplkTXyZNmevY9pggHoGGE6ioq8r6
BCCoTHm6ZJYFuwcZvId0Y4F/0Z0JB9KY3RLr9YfnNZGChzLvyyExeSjPJ1zM426luw7vTJ1I
AJOmbpb+T1BsBp51svx3PZIv25vDkCy6sHTfWeZHfvNZ+96pBOpKU4N5Og==
--------------msDA0E587CCEBDF994FF914A0D--



Received: from mail.nexsi.com (sdsl-208-185-176-210.dsl.sjc.megapath.net [208.185.176.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17302 for <[e-mail]>; Wed, 6 Sep 2000 10:17:40 -0700 (PDT)
Received: from denali (dynam69.nexsi.com [172.16.212.69]) by mail.nexsi.com (8.9.3/8.9.3) with SMTP id DAA14852; Wed, 6 Sep 2000 03:21:59 -0700
From: "sankar ramamoorthi" <[e-mail]>
To: <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: "Khaja Ahmed" <[e-mail]>, <[e-mail]>
Subject: RE: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)
Date: Wed, 6 Sep 2000 10:15:19 -0700
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <[e-mail]>
Importance: Normal

>To: [e-mail]; Michael Myers
>Cc: Khaja Ahmed; [e-mail]
>Subject: RE: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)
>
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]
>Sent: Wednesday, September 06, 2000 6:48 AM
>To: Michael Myers
>Cc: Khaja Ahmed; [e-mail]
>Subject: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)
>
>
>Michael Myers writes ("Asymmetric OCSP"):
>
>>The concept applies best to the road warrior using IPSEC to securely
>>reach back home, to a customer site on a trouble call, etc..
>>Basically, during the IPSEC setup phase the IPSEC server or gateway
>>first checks the RW's cert by reference to an enterprise OCSP server.
>>There you get revocation/validation enforcement on the client.  The
>>server or gateway then turns around and asks the OCSP server for
>>status on it's (the gw's) cert, puts this into the handshake and so
>>delivers back to the client revocation/validation assurance.
>
>Perhaps I'm missing something, but this appears to suggest that the
>client is expected to accept the server's unexamined claim that its
>own cert is unrevoked.

Since the CRL is a signed quantity it should not matter whether the
CRL comes from the server itself - right?

However a server may choose only to send the base CRL and not
the delta CRL information and thus may hide the truth that its certificate
is
revoked. How should this scenario be handled by the client?


>
>If the GW cert is being used to support the server's side of the IPSEC
>connection, then there is definitely a problem.
>
>David Boyce
>
>[e-mail]

-- sankar --




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17038 for <[e-mail]>; Wed, 6 Sep 2000 10:12:07 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA08809; Wed, 6 Sep 2000 19:13:43 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 6 Sep 2000 19:13:44 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA05435; Wed, 6 Sep 2000 19:13:42 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA15169; Wed, 6 Sep 2000 19:13:42 +0200 (MET DST)
Date: Wed, 6 Sep 2000 19:13:42 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspension

> 
> i meant the case where i as the signer (or verifier) want to proove later on
> that i signed a document at some time (or in an interval). i think it is
> important for the requirement of non-repudiation to have a chance to proove
> that the certificate was valid at the signature creation time. but this can
> be achieved, if it is not allowed to make any retroactive status changes. if
> there is no suspended status allowed that means that the certificate is not
> valid, OCSP as it is now is enough. but there are different interpretations
> of the suspended status. in the "ILLINOIS ELECTRONIC COMMERCE SECURITY ACT"
> (http://www.mbc.com/ecommerce/legis/ill-esca.html) one can read:
> > If a certificate is suspended rather than revoked, the operational period
> is considered to be terminated
> > for the duration of the period of suspension, and digital signatures
> created during the period of
> > suspension will not qualify as secure electronic signatures under Section
> 15-105.

I do not see in text that something is required to do something like
time stamping so that a verifier has some date to use to determine
the validity of a cert. 

In the comments, you have a remark that an electronic signature can
become invalid in the future. 

It seems to me that the idea is to set up some security procedure
where a creating and relying part agree at some point
within the operational period of a cert, that the electronic signature
is a good one, and then do something appropriate to keep that agreement.
  
Or, if a signer/verifier have the desire to prove later that an
electronic was valid at least at some time in this context, 
they make a cert validation and keep the result, this can include
time stamping etc.  

PS 



Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16323 for <[e-mail]>; Wed, 6 Sep 2000 09:51:15 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 4067815532; Wed,  6 Sep 2000 12:52:21 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id DD2857C0E8; Wed,  6 Sep 2000 12:52:21 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <SCK0R7G5>; Wed, 6 Sep 2000 12:52:21 -0400
Message-ID: <[e-mail]>
From: "Hewitt, Jim" <[e-mail]>
To: "'Markus Ruppert'" <[e-mail]>, [e-mail]
Subject: RE: OCSP Responder
Date: Wed, 6 Sep 2000 12:51:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

CertCo maintain an external instance of our CertValidator OCSP responder for
the purpose of third-party application testing.  Please contact me privately
for details.

Jim Hewitt
CertCo Inc.
[phone]
[e-mail]


-----Original Message-----
From: Markus Ruppert [mailto:[e-mail]]
Sent: Wednesday, September 06, 2000 12:26 PM
To: [e-mail]
Subject: OCSP Responder


Dear all,

  does anybody know an OSCP-responder to be used for
  tests.

  We want to test our own Java based implementation.

Thank's

  Markus Ruppert

 
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/


Received: from mailserver2.hrz.tu-darmstadt.de ([e-mail] [130.83.22.129]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14761 for <[e-mail]>; Wed, 6 Sep 2000 09:25:16 -0700 (PDT)
Received: from hrz2.hrz.tu-darmstadt.de (hrz2.hrz.tu-darmstadt.de [130.83.47.115]) by mailserver2.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id SAA01649 for <[e-mail]>; Wed, 6 Sep 2000 18:24:56 +0200 (MET DST)
Received: from HRZ2/SpoolDir by hrz2.hrz.tu-darmstadt.de (Mercury 1.47); 6 Sep 00 18:25:04 +0200
Received: from SpoolDir by HRZ2 (Mercury 1.47); 6 Sep 00 18:24:46 +0200
Received: from pc132 (130.83.244.93) by hrz2.hrz.tu-darmstadt.de (Mercury 1.47); 6 Sep 00 18:24:43 +0200
From: "Markus Ruppert" <[e-mail]>
To: <[e-mail]>
Subject: OCSP Responder
Date: Wed, 6 Sep 2000 18:26:19 +0200
Message-ID: <000001c0181f$30355bf0$[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
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0

Dear all,

  does anybody know an OSCP-responder to be used for
  tests.

  We want to test our own Java based implementation.

Thank's

  Markus Ruppert

 


Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12581 for <[e-mail]>; Wed, 6 Sep 2000 08:52:43 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA05308; Wed, 6 Sep 2000 08:54:12 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <R9HYGDA1>; Wed, 6 Sep 2000 08:52:35 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Denis Pinkas <[e-mail]>, [e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification
Date: Wed, 6 Sep 2000 08:52:33 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Saturday, September 02, 2000 9:35 AM
> To: Michael Myers
> Cc: Liaquat Khan; [e-mail]
> Subject: Re: RFC 2560 - OCSP - Clarification

. . .

> *In
> addition* to 2560bis, when are you expecting to provide a draft for
> OSCP extensions (i.e. OCSP-X) able to cover additional functionality
> ? 


Denis,

We intend to get out by Sept. 15 the various drafts I proposed in Pittsburg.

Mike


Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12485 for <[e-mail]>; Wed, 6 Sep 2000 08:51:29 -0700 (PDT)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA05309; Wed, 6 Sep 2000 08:54:12 -0700 (PDT)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <R9HYGDAD>; Wed, 6 Sep 2000 08:52:35 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Ambarish Malpani <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: OCSP Common Profiles
Date: Wed, 6 Sep 2000 08:52:33 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Ambarish,

Following direction from the chairs in Pittsburg, we should defer calling
for consensus until all proposals are on the table.  This should occur by
Sept. 15.  Even then, we need to give folks a reasonable interval to
evaluate alternatives before calling for consensus.

Mike

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Tuesday, September 05, 2000 9:46 AM
> To: '[e-mail]'
> Subject: RE: OCSP Common Profiles
> 
> 
> 
> I would like to agree, that if there is nothing fundamentally
> broken with OCSP, we proceed with OCSP (with some clarifications)
> along the standards process.
> 
> If the main driving force to redo OCSP is to allow for remote
> path processing, it might be faster and cleaner to do it with
> SCVP.
> 
> From the mails I have seen on this list, it is unclear that there
> is overwhelming support to making a bunch of changes to OCSP.
> 
> Comments?
> 
> Regards,
> Ambarish
> 


Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06238 for <[e-mail]>; Wed, 6 Sep 2000 08:00:33 -0700 (PDT)
Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA26426 for <[e-mail]>; Wed, 6 Sep 2000 16:02:09 +0100 (BST)
Received: from jap.ecs.soton.ac.uk (jap.ecs.soton.ac.uk [152.78.69.201]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id QAA21112 for <[e-mail]>; Wed, 6 Sep 2000 16:02:08 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 06 Sep 2000 15:57:00 +0100
To: [e-mail]
From: J Adrian Pickering <[e-mail]>
Subject: Re: CMC issues, TSP hashes
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:57 06/09/00 +0200, Avi Gozlan wrote:

>- Use of SHA1 is hard coded in section 5.2. This does not leave the
>standard open for other hash algorithms. Are there any plans to change
>this?

This is a problem shared with the TSP Draft also.

(see posting -
Date: Sat, 02 Sep 2000 17:37:43 +0100
From: J Adrian Pickering <[e-mail]>
Subject: TSP Draft - hash enforcement &c
which is rather lost amongst the OCSP debate!)

Please can something be done about this for everyone's benefit? My 
suggestion is to introduce a PKIX globally available OID 
HashAlgorithmIdentifier which is distinct from AlgorithmIdentifier. This 
will enable other hashes to be used where required/wanted. The overloading 
of the AlgorithmIdentifier allows for a parameter which I'm not sure is any 
use in the hash arena?

Russ Housley appears to agree: "The selected one-way hash function must be 
uniquely identified by an OID."

I'd still rather have the TSA autonomously stamp an octet string and leave 
the client to decide what it all means. What business is it of the TSA to 
know what it is stamping (semantically or syntactically)?

Adrian Pickering/
Electronics and Computer Science
University of Southampton
UK




Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA04239 for <[e-mail]>; Wed, 6 Sep 2000 07:23:51 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.205]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA07284 for <[e-mail]>; Wed, 6 Sep 2000 07:24:55 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 06 Sep 2000 10:23:16 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-pkix-time-stamp-09 comments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Here are my comments on draft-ietf-pkix-time-stamp-09.  I have divided them 
into two categories: technical and editorial.  In my view, the technical 
changes are needed.  On the other hand, the editorial changes improve 
readability.

TECHNICAL

Section 2.1, 6th requirement.  I do not understand "hash-function 
OID."  OIDs, when managed correctly, are collision free.  I think we need 
to be discussing the one-way hash function, not its OID.  The selected 
one-way hash function must be uniquely identified by an OID.

Section 2.2, last paragraph.  Is this a SHOULD or a MAY?  The text says 
that the client SHOULD make the check, but that the client MAY elect to 
skip the check.  The checking requirement is either a SHOULD or a MAY, it 
cannot be both.

Section 2.4.1, reqPolicy Discussion.  I do not think that a reference to 
RFC 2459 is adequate.  First, I do not believe that a certification policy 
and a TSA policy are equivalent.  At a minimum, the TSA Policy and TSA 
Practice Statement will have significantly different content.  These 
differences need to be discussed.  Second, I would prefer syntax without 
qualifiers.  What value do they add in the TSA context?

Section 2.4.1, nonce Discussion.  Please replace "shall" with "MUST."

Section 2.4.2, 3rd paragraph.  The text does not match the comments in the 
ASN.1 structure.  I assume that the comments are correct.  Please 
rewrite.  I suggest:
	"When status contains the value zero or one, a Time Stamp Token
	MUST be present.  When status contains a value other than zero or
	one, a Time Stamp Token MUST NOT be present.  One of the following
	values MUST be contained in status:"

Section 2.4.2, 11th paragraph (counting paragraphs is difficult since the 
ASN.1 fragments are not indented).   Please replace "shall" with "MUST."

Section 2.4.2, serialNumber Discussion.  Please reword the last sentence to 
include a MUST.  I suggest: "This property MUST be preserved even after an 
interruption in service (e.g. crash)."

Section 2.4.2, genTime Discussion.  Please replace "shall" with 
"MUST."  There are at least five occurances.

Section 3.1.  How does the MIME type distinguish a time stamp request from 
a time stamp token?  The recipient must either decode a TimeStampReq or a 
ContentInfo, and this does not provide enough information to determine 
which operation to perform.

Section 3.2.  It would be helpful to specify file extensions for a time 
stamp request and a time stamp token.  Such extensions would permit the 
recipient to determine which decode to perform.

Section 3.3.  It would be useful to implementors to include the state 
machine for the TCP-based protocol.

Section 3.4.  How does the MIME type distinguish a time stamp request from 
a time stamp token?  The recipient must either decode a TimeStampReq or a 
ContentInfo, and this does not provide enough information to determine 
which operation to perform.

Section 4, item 4.  Each of the transports specified has different delay 
characteristics.  This should be pointed out.

EDITORIAL

Whole document.  Either add "SHALL" to the list of words that you say are 
defined in RFC 2119, or change "SHALL" to "MUST."

Section 2.2, 2nd paragraph.  Typo.  Please move the comma in the second to 
last sentence.  It should say: "For more details about replay attack 
detection, see the security considerations section (item 6)."

Section 2.4.1, MessageImprint Definition.  I suggest the replacement of 
"hashedMessage" with "MessageHash."  To me, the current name implies the 
full message text rather than a hash of the message text.

Section 2.4.1, certReq Disscussion.  Typo.  Please move the comma.  The 
sentence should read: "If the certReq field is missing or if the certReq 
field is present and set to false, then ..."

Section 2.4.2, id-smime-ct-TSTInfo definiton.  First, the registry calls 
this OID id-ct-TSTInfo. Second, I think that it would be more readable to 
define it as follows:
	id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
		 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

Section 2.4.2, genTime Discussion.  Some require course granularity, others 
require fine granularity.  I suggest that a TSA MUST offer at least 1 
second granularity.  Filling in the genTime structure with "00" as the 
seconds does not meet this requirement.

Section 2.4.2, accuracy Discussion.  I think that a bit more discussion is 
needed.  the syntax permits the seconds and micros fields to be present and 
the millis to be absent.  I am not sure how to add and subtract such a 
structure.

Section 2.4.2, ordering Discussion.  Please replace the last sentence with: 
"... TSA can always be ordered based on the genTime field, regardless of 
the genTime accuracy.

Section 2.4.2, tsa Discussion.  Please change "an hint" to "a hint."

Section 4, item 6.  Please change "(algorithm and)" to "algorithm and."

Appendix A.  First, the registry calls this OID id-aa-timeStampToken. 
Second, I think that it would be more readable to define it as follows:
	id-aa-timeStampToken  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
		us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 14 }



Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02261 for <[e-mail]>; Wed, 6 Sep 2000 06:49:31 -0700 (PDT)
From: [e-mail]
Received: from joshua.isode.com by woozle.isode.com (local) with ESMTP; Wed, 6 Sep 2000 14:49:34 +0100
X-Mailer: exmh version 2.1.1 10/15/1999
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: pkix
To: Michael Myers <[e-mail]>
cc: Khaja Ahmed <[e-mail]>, [e-mail]
Subject: Asymmetric OCSP (was: Re: OCSP in S/MIME and IPSEC)
In-Reply-To: Message from Michael Myers <[e-mail]> of "Fri, 01 Sep 2000 12:51:02 PDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain
Date: Wed, 06 Sep 2000 14:47:55 +0100
Message-ID: <[e-mail]>

Michael Myers writes ("Asymmetric OCSP"):

>The concept applies best to the road warrior using IPSEC to securely
>reach back home, to a customer site on a trouble call, etc..
>Basically, during the IPSEC setup phase the IPSEC server or gateway
>first checks the RW's cert by reference to an enterprise OCSP server.
>There you get revocation/validation enforcement on the client.  The
>server or gateway then turns around and asks the OCSP server for
>status on it's (the gw's) cert, puts this into the handshake and so
>delivers back to the client revocation/validation assurance.

Perhaps I'm missing something, but this appears to suggest that the
client is expected to accept the server's unexamined claim that its
own cert is unrevoked.

If the GW cert is being used to support the server's side of the IPSEC
connection, then there is definitely a problem.

David Boyce

[e-mail]


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27942 for <[e-mail]>; Wed, 6 Sep 2000 05:33:56 -0700 (PDT)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id AA187C901B2; Wed, 06 Sep 2000 14:35:36 +0200
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Wed, 06 Sep 2000 14:34:24 +0100
From: "Karl Scheibelhofer" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP support for historical reference to certificate suspension
Date: Wed, 6 Sep 2000 14:34:24 +0200
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Michael,

> Assume there exists a relationship between a wireless client (WC) and a
> wireless transaction facilitator (WTF) that enables mobile e-commerce, the
> secure interaction of which is assured via PKI.  Further assume that a
> wireless client's digital signature private key is compromised.  Then:
>
> 1. Between the (apparent) WC's commit to a wireless transaction (1st
> timestamp, produced by attacker) and WTF's execution of that transaction
> (2nd timestamp) there exists a non-zero probability that the
> client's report
> of that compromise would not reach the facilitator.
>
> 2. If the client's certificate issuer confirms "good" via OCSP
> between these
> two endpoints, then to the actual knowledge of the issuer, the certificate
> is reliable (or at the least, not revoked).

that is not what i actually meant with my example, but this can be a
problem. i am not sure, if you can solve the problem you sketched by
technical means. i also agree that this problem is related to the one i
explained.
if i get a qualified response that a certificate was valid at some time, it
must not be possible to get a  qualified response that contradicts the
previous one.

i meant the case where i as the signer (or verifier) want to proove later on
that i signed a document at some time (or in an interval). i think it is
important for the requirement of non-repudiation to have a chance to proove
that the certificate was valid at the signature creation time. but this can
be achieved, if it is not allowed to make any retroactive status changes. if
there is no suspended status allowed that means that the certificate is not
valid, OCSP as it is now is enough. but there are different interpretations
of the suspended status. in the "ILLINOIS ELECTRONIC COMMERCE SECURITY ACT"
(http://www.mbc.com/ecommerce/legis/ill-esca.html) one can read:
> If a certificate is suspended rather than revoked, the operational period
is considered to be terminated
> for the duration of the period of suspension, and digital signatures
created during the period of
> suspension will not qualify as secure electronic signatures under Section
15-105.
in the austrian signature law, a signature created while the certificate is
suspended is valid, if the certificate is not revoked after suspension.

in my first suggestion, i also missed that the status can change several
times in an interval. so it should sound like this:
"what was the state of certificate XYZ in the time interval [t1,t2]?" (where
t1 <= t2)

the answers could be:
1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...)
throughout the time intervall [t1,t2]
2) certificate XYZ changed its state from state A (e.g. valid) to state B
(e.g. suspended) at t(AB), from state B to state C at t(BC), from state C to
state D at t(CD),... ,where t1 <= t(AB) < t(BC) < t(CD) < ... <= t2

this would also have the advantage that one could get the history of a
certificate by requesting the state in the intervall [t(valid not before),
t(now)]. so if i have a OCSP server at my company, that get's a request for
the state of certificate XYZ it could contact the certificate issuer for its
state in the intervall [t(valid not before), t(now)] and cache this
response. by using this response my server could respond to all subsequent
requests for this certificate referring to any interval included in [t(valid
not before), t(now)]. if the certificate expired one can archive [t(valid
not before), t(valid not after)] as the complete history.
i would like to hear a comment from a CA provider, if this information is
easily available at a CA. i would really be surprised, if they would not
have the whole history of a certificate available in a database.

i hope that i am not the only one who finds this idea worth to consider.

regards

  Karl



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21150 for <[e-mail]>; Wed, 6 Sep 2000 03:43:27 -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 GAA06972; Wed, 6 Sep 2000 06:45:03 -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-ldap-v3-03.txt
Date: Wed, 06 Sep 2000 06:45:03 -0400
Sender: [e-mail]

--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 Operational 
                          Protocols - LDAPv3
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-ldap-v3-03.txt
	Pages		: 6
	Date		: 05-Sep-00
	
This document describes the features of the Lightweight Directory 
Access Protocol v3 that are needed in order to support a public key 
infrastructure based on X.509 certificates and CRLs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-v3-03.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-ldap-v3-03.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-ldap-v3-03.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-ldap-v3-03.txt

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

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

--OtherAccess--

--NextPart--




Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA14728 for <[e-mail]>; Wed, 6 Sep 2000 02:28:51 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Wed Sep 06 11:27:35 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <RPZ34VM4>; Wed, 6 Sep 2000 11:29:44 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, [e-mail], Simon Tardell <[e-mail]>
Subject: RE: OCSP support for historical reference to certificate suspensi on
Date: Wed, 6 Sep 2000 11:29:58 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Peter,

> I am not sure whether I understand the order of thisUpdate or 
> evaluateAt: 
> 
> The OCSP responder has a the latest copy of a CRL of t1, it gets a request
> asking for a status with an evaluation date of t2>t1. (t2 maybe less or
> larger than the 'now' date of the server). 
> what should the server respond?

If you ask for an evaluation date which is later than the latest CRL that
the responder has access to, the response must be "unknown". If you don't
give an evaluation date, then, effectively, the query will be evaluated at
the latest time for which there is information (i.e. the thisUpdate of the
latest CRL) and that will be documented in the thisUpdate of the response.

Simon

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from michael.checkpoint.com (michael.checkpoint.com [199.203.73.68]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12998 for <[e-mail]>; Wed, 6 Sep 2000 01:56:08 -0700 (PDT)
Received: from checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.9.3/8.9.1) with ESMTP id LAA01024 for <[e-mail]>; Wed, 6 Sep 2000 11:56:22 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Wed, 06 Sep 2000 11:57:42 +0200
From: Avi Gozlan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: CMC issues
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

After reading CMC, I have got questions about the standard. Comments are
welcomed.

- ASN.1 module issues:
1. In the module, pendToken in pendInfo is defined to be an INTEGER,
while queryPending is defined as OCTET STRING in 5.13.

2. The definition of bodyList in 5.1 is “SEQUENCE SIZE (1..MAX) OF
BodyPartID” while in the module it is defined as “SEQUENCE SIZE (1..MAX)
OF INTEGER”

3. The module imports AttributeCertificate and CertificateList. Both are
superfluous.

- Use of SHA1 is hard coded in section 5.2. This does not leave the
standard open for other hash algorithms. Are there any plans to change
this?

- If the shared secret method is used as proof of identity, it may be
exposed to off line dictionary attack (if supplied by the user). Usually
such an attack becomes harder by enforcing expensive computation for
each trial of a shared secret (computation of the hash 1000 times or
so). The CMC standard does not use this technique. It should at least
state that the shared secret must be randomly chosen (not a user
supplied password).
This attack is usually meaningless, as the shared secret is used only
once, however, if the initial enrollment request fails, the same secret
may be used in following requests (the standard does not require
replacement of it). As mentioned, a requirement of randomly chosen
secret may solve this.

- It seems to me that the single round trip preference mentioned in
section 1 cannot come along with the industry practice of PKCS#10/PKCS#7
(mentioned in the same section). Proof of Identity may be supplied in
the full enrollment message (thus not using the PKCS#10 request) or
pending token must be returned (and having more then single round trip).

- According to the standard, the crm is signed (otherwise, there is no
meaning to the addition of the idPOPLinkWitness in the control section
of crm as described in 5.3.1). On the other side the full enrollment
request is signed, as described in section 4.2. In a case of renewal,
both signatures are required (the crm/pkcs10 are signed by the new key,
the whole message is signed by the old key). In the initial enrollment,
though, there is one redundant signature.

Avi
--
Avi Gozlan
Encryption Group, R&D
Check Point Software Tech. Ltd
e-mail: [e-mail]




Received: from michael.checkpoint.com (michael.checkpoint.com [199.203.73.68]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12924 for <[e-mail]>; Wed, 6 Sep 2000 01:55:29 -0700 (PDT)
Received: from checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.9.3/8.9.1) with ESMTP id LAA00866 for <[e-mail]>; Wed, 6 Sep 2000 11:55:34 +0300 (IDT)
Message-ID: <[e-mail]>
Date: Wed, 06 Sep 2000 11:56:54 +0200
From: Avi Gozlan <[e-mail]>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: CMC transport
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Is there any port allocated for CMC? Are there any wrapping protocol (as
in CMP)? If using HTTP, what are the details of the protocol used
(whether to use POST or not, whether to maintain the connection open in
the case of more then one single trip etc.)?

Avi

--
Avi Gozlan
Encryption Group, R&D
Check Point Software Tech. Ltd
e-mail: [e-mail]





Received: from mail.interems.com ([207.104.29.181]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13036 for <[e-mail]>; Tue, 5 Sep 2000 15:10:12 -0700 (PDT)
Received: by MAIL with Internet Mail Service (5.5.2650.21) id <SFPZPF0V>; Tue, 5 Sep 2000 15:06:52 -0700
Message-ID: <69A40A314934D41190C70050DAD7F99063B5C6@MAIL>
From: Mathew  Butler <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, Karl Scheibelhofer <[e-mail]>, [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspensi on
Date: Tue, 5 Sep 2000 15:06:51 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

In other words, you want to provide for the possibility of repudiation of a
signature that appears valid, but for reasons outside the scope of the
specification really is not.

-Mat Butler

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Tuesday, September 05, 2000 3:02 PM
To: Karl Scheibelhofer; [e-mail]
Subject: RE: OCSP support for historical reference to certificate
suspensi on


Karl,

Very good catch!  At least, some very good inspiration.  We'll see . . . .

May I transform your cited case into more generalized trusted transaction
management practices for your confirmation and my own clarification.  

Assume there exists a relationship between a wireless client (WC) and a
wireless transaction facilitator (WTF) that enables mobile e-commerce, the
secure interaction of which is assured via PKI.  Further assume that a
wireless client's digital signature private key is compromised.  Then:

1. Between the (apparent) WC's commit to a wireless transaction (1st
timestamp, produced by attacker) and WTF's execution of that transaction
(2nd timestamp) there exists a non-zero probability that the client's report
of that compromise would not reach the facilitator.

2. If the client's certificate issuer confirms "good" via OCSP between these
two endpoints, then to the actual knowledge of the issuer, the certificate
is reliable (or at the least, not revoked).

Is this a reasonable generalization?

Mike





> -----Original Message-----
> From: Karl Scheibelhofer [mailto:[e-mail]]
> Sent: Sunday, September 03, 2000 11:55 PM
> To: Michael Myers; [e-mail]
> Subject: RE: OCSP support for historical reference to certificate
> suspension
> 
> 
> > But for discussion purposes, I've been architecting under 
> the presumption
> > that in the instance when signing time was important, the 
> time when the
> > digital signature was created would be integrated somehow 
> into the subject
> > electronic document and thus there exist a well-defined time.
> >
> > I believe you're implying that it may not be the case that 
> signing time is
> > integrated into a subject document, and so one is led to bracket
> > the signing
> > time.  Could confirm please, or otherwise clarify?  Thanks.
> 
> of course, it is desirable that the document is timestamped 
> before it gets
> signed. and to fulfill the requirement for non-repudiation, 
> it is necessary
> to timestamp the signed document afterwards. but there are 
> cases thinkable,
> where there is a longer time between these two timestamps; 
> e.g. if you are
> signing on a mobile device, that does not have permanent access to a
> timestamping sever. very often, the first time stamp will be 
> replaced by
> just a time value that is added before the document gets 
> signed. but if it
> is just a value, i can insert any value i like; it is not detectable
> afterwards. so you cannot proof that you signed the document 
> not before a
> specific time.
> only if you are using two timestamps, you can proof later on that the
> signature was created between these two timestamps. in case 
> of a dispute, i
> think this is very helpful.
> 
> regards
> 
>   Karl Scheibelhofer
> 
> --
> 
> Karl Scheibelhofer, <mailto:[e-mail]>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) [phone]
> 


Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12643 for <[e-mail]>; Tue, 5 Sep 2000 15:05:19 -0700 (PDT)
From: [e-mail]
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e85M5bh18973; Tue, 5 Sep 2000 15:05:37 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e85M5ov29470; Tue, 5 Sep 2000 15:05:50 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256951.00795E38 ; Tue, 5 Sep 2000 15:05:39 -0700
X-Lotus-FromDomain: 3COM
To: "Anders Rundgren" <[e-mail]>
cc: [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 5 Sep 2000 15:05:27 -0700
Subject: Re: Comment on AttributeCertificate draft
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

(Sorry for possible duplication)

First, I want to correct the (incorrect) impression I left saying that SPKI
explains why multiple certificates are unavoidable, I did not say that X.509
certificates are limited to one per user. X.509 certificates can be used as SPKI
certificates and therefore there is no limit.
However, the typical application of PKI was for a long time thought to be where
a user has a (i.e. single) PKC, as you call it. This PKC is posted in a
directory with a name to certificate mapping and the certificate contained no
authorizations. Granted, this is just a typical application.

Now, it is clear that for inter-enterprise, or inter-organizational
communications, that directory entry and associated profile will be meaningless
because there will be no access to it from outside the organization.

Its also clear that this type of communication needs to be secure on the network
layer as well as the application layer. IP traffic will need to be authorized
first to go through. After that the application layer, say an XML parser, would
decide whether the specifically requested operation is authorized to the
key-holder since IP layer cannot necessarily make this decision.
What was suggested below means that the communication on the IP level is not
secured, as this is what I understand.

Another example is where QoS guarantees need to be made on RSVPed  traffic
flowing from a user connected to an ISP to an organization. Also consider a
small regional office of an organization with a broadband connection to a local
ISP. How about extranet access? It could be a video conference, IP telephony.
Would you imagine not being able to speak on the phone with anyone outside your
organization? SPKI claims that doing this "conservatively" would not be
scalable.

Authorizations cross organizational boundaries, as traffic does. That's the
nature of the internet. So, I do not think it would be rare.
Let us avoid the pitfalls outlined in SPKI theory and come up with something
which can scale globally.

Regards,
Ron.






"Anders Rundgren" <[e-mail]> on 09/05/2000 02:34:09 PM

Sent by:  "Anders Rundgren" <[e-mail]>


To:   Ron Vered/HQ/3Com, [e-mail]
cc:   [e-mail], [e-mail], [e-mail],
      [e-mail]
Subject:  Re: Comment on AttributeCertificate draft



Ron et. al,

Actually I have hard to see the need for both SPKI and AC.

Authorization is usually a local business and is better handled by directories
or Kerberos

For inter-enterprize authorizations it seems to me that messages (preferably in
business-compatible formats like XML) signed by organization-keys are
sufficient.

In (the rare) case a certified individual must be a part of an inter-enterprize
operation, the message
could preferably first be signed by the individual's key.

What is left are few and pretty obscure applications IMO.   Off-line operations
maybe.

Regards
Anders Rundgren


>
>Stephen,
>
>The authors of RFC 2693 went to great lengths to explain why PKCs with
>Distinguished Names will not work on global scale and why multiple certificates
>per user are inescapable. They specifically address the subject of
>authorizations and the mapping of authorizations to key holders, a subject AC
>tries to address as well. Their reasoning can be ignored but the then ACs would
>suffer from caveats mentioned in the RFC above.
>
>In my opinion, ACs should *allow* adherence to the SPKI model, being a real
>global-scale model suited for the internet, not just intra-enterprise but also
>inter-enterprise. In particular: local names & global identifiers (a key
issue),
>reduced security with AA and CA (sec. 3.1).
>
>I do not think allowing SPKI adherence, given the simplicity of SPKI, would not
>be too difficult. There is no question in my mind that it is a very powerful
>model suited for the inter-net.
>
>Regards,
>Ron.
>
>
>
>
>
>Stephen Farrell <[e-mail]> on 09/04/2000 03:08:59 AM
>
>Please respond to [e-mail]
>
>Sent by:  Stephen Farrell <[e-mail]>
>
>
>To:   Ron Vered/HQ/3Com
>cc:   [e-mail], [e-mail], [e-mail],
>      [e-mail]
>Subject:  Re: Comment on AttributeCertificate draft
>
>
>
>
>Hi Ron,
>
>I'd have to say that the AC work doesn't have any direct "fit"
>with SPKI since its just a profile of X.509 ACs. Having said that
>however, a combination of X.509 ACs and PKCs can be used to
>achieve the same authorization functionality as SPKI, though
>you'd still have anti-ASN.1 reasons to use SPKI if you believe
>in those. So basically its another way to do the same thing,
>but based on X.509 and not 5-tuples.
>
>I'm not familiar with X9.57, so I can't comment on it.
>
>Regards,
>Stephen.
>
>[e-mail] wrote:
>>
>> Stephen,
>>
>> How does this proposal fit (or not) with the theoretical work on SPKI (RFC
>> 2693)?
>> In particular, an AC does not have a public key AND a single PKC may have
>> multiple ACs. Also, SPKI suggestion on the use of X9.57 to specify
>authorization
>> attributes in X.509v3.
>>
>> Regards,
>> Ron.
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>61 Fitzwilliam Lane,                    fax: [phone]
>Dublin 2.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com
>
>
>
>







Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA12367 for <[e-mail]>; Tue, 5 Sep 2000 15:02:23 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id OAA19658; Tue, 5 Sep 2000 14:59:53 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <R9H9LVBM>; Tue, 5 Sep 2000 15:02:17 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Karl Scheibelhofer <[e-mail]>, [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspensi on
Date: Tue, 5 Sep 2000 15:02:15 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Karl,

Very good catch!  At least, some very good inspiration.  We'll see . . . .

May I transform your cited case into more generalized trusted transaction
management practices for your confirmation and my own clarification.  

Assume there exists a relationship between a wireless client (WC) and a
wireless transaction facilitator (WTF) that enables mobile e-commerce, the
secure interaction of which is assured via PKI.  Further assume that a
wireless client's digital signature private key is compromised.  Then:

1. Between the (apparent) WC's commit to a wireless transaction (1st
timestamp, produced by attacker) and WTF's execution of that transaction
(2nd timestamp) there exists a non-zero probability that the client's report
of that compromise would not reach the facilitator.

2. If the client's certificate issuer confirms "good" via OCSP between these
two endpoints, then to the actual knowledge of the issuer, the certificate
is reliable (or at the least, not revoked).

Is this a reasonable generalization?

Mike





> -----Original Message-----
> From: Karl Scheibelhofer [mailto:[e-mail]]
> Sent: Sunday, September 03, 2000 11:55 PM
> To: Michael Myers; [e-mail]
> Subject: RE: OCSP support for historical reference to certificate
> suspension
> 
> 
> > But for discussion purposes, I've been architecting under 
> the presumption
> > that in the instance when signing time was important, the 
> time when the
> > digital signature was created would be integrated somehow 
> into the subject
> > electronic document and thus there exist a well-defined time.
> >
> > I believe you're implying that it may not be the case that 
> signing time is
> > integrated into a subject document, and so one is led to bracket
> > the signing
> > time.  Could confirm please, or otherwise clarify?  Thanks.
> 
> of course, it is desirable that the document is timestamped 
> before it gets
> signed. and to fulfill the requirement for non-repudiation, 
> it is necessary
> to timestamp the signed document afterwards. but there are 
> cases thinkable,
> where there is a longer time between these two timestamps; 
> e.g. if you are
> signing on a mobile device, that does not have permanent access to a
> timestamping sever. very often, the first time stamp will be 
> replaced by
> just a time value that is added before the document gets 
> signed. but if it
> is just a value, i can insert any value i like; it is not detectable
> afterwards. so you cannot proof that you signed the document 
> not before a
> specific time.
> only if you are using two timestamps, you can proof later on that the
> signature was created between these two timestamps. in case 
> of a dispute, i
> think this is very helpful.
> 
> regards
> 
>   Karl Scheibelhofer
> 
> --
> 
> Karl Scheibelhofer, <mailto:[e-mail]>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) [phone]
> 


Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12001 for <[e-mail]>; Tue, 5 Sep 2000 14:55:33 -0700 (PDT)
From: [e-mail]
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e85LtBh16948; Tue, 5 Sep 2000 14:55:11 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e85LtOv27878; Tue, 5 Sep 2000 14:55:24 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256951.00786ADD ; Tue, 5 Sep 2000 14:55:16 -0700
X-Lotus-FromDomain: 3COM
To: "Anders Rundgren" <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 5 Sep 2000 14:55:05 -0700
Subject: Re: Comment on AttributeCertificate draft
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

First, I want to correct the (incorrect) impression I left saying that SPKI
explains why multiple certificates are unavoidable, I did not say that X.509
certificates are limited to one per user. X.509 certificates can be used as SPKI
certificates and therefore there is no limit.
However, the typical application of PKI was for a long time thought to be where
a user has a (i.e. single) PKC, as you call it. This PKC is posted in a
directory with a name to certificate mapping and the certificate contained no
authorizations. Granted, this is just a typical application.

Now, it is clear that for inter-enterprise, or inter-organizational
communications, that directory entry and associated profile will be meaningless
because there will be no access to it from outside the organization.

Its also clear that this type of communication needs to be secure on the network
layer as well as the application layer. IP traffic will need to be authorized
first to go through. After that the application layer, say an XML parser, would
decide whether the specifically requested operation is authorized to the
key-holder since IP layer cannot necessarily make this decision.
What was suggested below means that the communication on the IP level is not
secured, as this is what I understand.

Another example is where QoS guarantees need to be made on RSVPed  traffic
flowing from a user connected to an ISP to an organization. Also consider a
small regional office of an organization with a broadband connection to a local
ISP. How about extranet access? It could be a video conference, IP telephony.
Would you imagine not being able to speak on the phone with anyone outside your
organization? SPKI claims that doing this "conservatively" would not be
scalable.

Authorizations cross organizational boundaries, as traffic does. That's the
nature of the internet. So, I do not think it would be rare.
Let us avoid the pitfalls outlined in SPKI theory and come up with something
which can scale globally.

Regards,
Ron.






"Anders Rundgren" <[e-mail]> on 09/05/2000 02:34:09 PM

Sent by:  "Anders Rundgren" <[e-mail]>


To:   Ron Vered/HQ/3Com, [e-mail]
cc:   [e-mail], [e-mail], [e-mail],
      [e-mail]
Subject:  Re: Comment on AttributeCertificate draft



Ron et. al,

Actually I have hard to see the need for both SPKI and AC.

Authorization is usually a local business and is better handled by directories
or Kerberos

For inter-enterprize authorizations it seems to me that messages (preferably in
business-compatible formats like XML) signed by organization-keys are
sufficient.

In (the rare) case a certified individual must be a part of an inter-enterprize
operation, the message
could preferably first be signed by the individual's key.

What is left are few and pretty obscure applications IMO.   Off-line operations
maybe.

Regards
Anders Rundgren


>
>Stephen,
>
>The authors of RFC 2693 went to great lengths to explain why PKCs with
>Distinguished Names will not work on global scale and why multiple certificates
>per user are inescapable. They specifically address the subject of
>authorizations and the mapping of authorizations to key holders, a subject AC
>tries to address as well. Their reasoning can be ignored but the then ACs would
>suffer from caveats mentioned in the RFC above.
>
>In my opinion, ACs should *allow* adherence to the SPKI model, being a real
>global-scale model suited for the internet, not just intra-enterprise but also
>inter-enterprise. In particular: local names & global identifiers (a key
issue),
>reduced security with AA and CA (sec. 3.1).
>
>I do not think allowing SPKI adherence, given the simplicity of SPKI, would not
>be too difficult. There is no question in my mind that it is a very powerful
>model suited for the inter-net.
>
>Regards,
>Ron.
>
>
>
>
>
>Stephen Farrell <[e-mail]> on 09/04/2000 03:08:59 AM
>
>Please respond to [e-mail]
>
>Sent by:  Stephen Farrell <[e-mail]>
>
>
>To:   Ron Vered/HQ/3Com
>cc:   [e-mail], [e-mail], [e-mail],
>      [e-mail]
>Subject:  Re: Comment on AttributeCertificate draft
>
>
>
>
>Hi Ron,
>
>I'd have to say that the AC work doesn't have any direct "fit"
>with SPKI since its just a profile of X.509 ACs. Having said that
>however, a combination of X.509 ACs and PKCs can be used to
>achieve the same authorization functionality as SPKI, though
>you'd still have anti-ASN.1 reasons to use SPKI if you believe
>in those. So basically its another way to do the same thing,
>but based on X.509 and not 5-tuples.
>
>I'm not familiar with X9.57, so I can't comment on it.
>
>Regards,
>Stephen.
>
>[e-mail] wrote:
>>
>> Stephen,
>>
>> How does this proposal fit (or not) with the theoretical work on SPKI (RFC
>> 2693)?
>> In particular, an AC does not have a public key AND a single PKC may have
>> multiple ACs. Also, SPKI suggestion on the use of X9.57 to specify
>authorization
>> attributes in X.509v3.
>>
>> Regards,
>> Ron.
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>61 Fitzwilliam Lane,                    fax: [phone]
>Dublin 2.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com
>
>
>
>







Received: from d1o69.telia.com ([e-mail] [62.20.144.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09895 for <[e-mail]>; Tue, 5 Sep 2000 13:33:50 -0700 (PDT)
Received: from mega (t5o69p98.telia.com [213.64.110.98]) by d1o69.telia.com (8.8.8/8.8.8) with SMTP id WAA16898; Tue, 5 Sep 2000 22:35:14 +0200 (CEST)
Message-ID: <008701c01781$08013210$[e-mail]>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: Comment on AttributeCertificate draft
Date: Tue, 5 Sep 2000 23:34:09 +0200
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 ns.secondary.com id NAA09896

Ron et. al,

Actually I have hard to see the need for both SPKI and AC.

Authorization is usually a local business and is better handled by directories
or Kerberos

For inter-enterprize authorizations it seems to me that messages (preferably in
business-compatible formats like XML) signed by organization-keys are sufficient.

In (the rare) case a certified individual must be a part of an inter-enterprize operation, the message
could preferably first be signed by the individual's key.

What is left are few and pretty obscure applications IMO.   Off-line operations maybe.

Regards
Anders Rundgren


>
>Stephen,
>
>The authors of RFC 2693 went to great lengths to explain why PKCs with
>Distinguished Names will not work on global scale and why multiple certificates
>per user are inescapable. They specifically address the subject of
>authorizations and the mapping of authorizations to key holders, a subject AC
>tries to address as well. Their reasoning can be ignored but the then ACs would
>suffer from caveats mentioned in the RFC above.
>
>In my opinion, ACs should *allow* adherence to the SPKI model, being a real
>global-scale model suited for the internet, not just intra-enterprise but also
>inter-enterprise. In particular: local names & global identifiers (a key issue),
>reduced security with AA and CA (sec. 3.1).
>
>I do not think allowing SPKI adherence, given the simplicity of SPKI, would not
>be too difficult. There is no question in my mind that it is a very powerful
>model suited for the inter-net.
>
>Regards,
>Ron.
>
>
>
>
>
>Stephen Farrell <[e-mail]> on 09/04/2000 03:08:59 AM
>
>Please respond to [e-mail]
>
>Sent by:  Stephen Farrell <[e-mail]>
>
>
>To:   Ron Vered/HQ/3Com
>cc:   [e-mail], [e-mail], [e-mail],
>      [e-mail]
>Subject:  Re: Comment on AttributeCertificate draft
>
>
>
>
>Hi Ron,
>
>I'd have to say that the AC work doesn't have any direct "fit"
>with SPKI since its just a profile of X.509 ACs. Having said that
>however, a combination of X.509 ACs and PKCs can be used to
>achieve the same authorization functionality as SPKI, though
>you'd still have anti-ASN.1 reasons to use SPKI if you believe
>in those. So basically its another way to do the same thing,
>but based on X.509 and not 5-tuples.
>
>I'm not familiar with X9.57, so I can't comment on it.
>
>Regards,
>Stephen.
>
>[e-mail] wrote:
>>
>> Stephen,
>>
>> How does this proposal fit (or not) with the theoretical work on SPKI (RFC
>> 2693)?
>> In particular, an AC does not have a public key AND a single PKC may have
>> multiple ACs. Also, SPKI suggestion on the use of X9.57 to specify
>authorization
>> attributes in X.509v3.
>>
>> Regards,
>> Ron.
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>61 Fitzwilliam Lane,                    fax: [phone]
>Dublin 2.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com
>
>
>
>



Received: from btw.plaintalk.bellevue.wa.us (btw-xl1.plaintalk.bellevue.wa.us [206.129.5.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06033 for <[e-mail]>; Tue, 5 Sep 2000 10:54:03 -0700 (PDT)
Received: from software-munitions.com (fwiw.plaintalk.bellevue.wa.us [206.129.5.157]) by btw.plaintalk.bellevue.wa.us (8.11.0/8.11.0) with ESMTP id e85Hss419894; Tue, 5 Sep 2000 10:54:54 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 05 Sep 2000 10:54:53 -0700
From: Dennis Glatting <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Jueneman <[e-mail]>, [e-mail]
Subject: Re: Client-side revocation checking capability
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bob Jueneman wrote:
> 
	[snip]

> So that leaves us with the key compromise possibility.
> 
> Now, in order to somehow benefit from a key compromise, the perpetrator would have to: (1) first install the compromised key on a server somewhere, and then (2) spoof or otherwise divert the DNS routing so that requests to www.whitehouse.gov go to say  www.dirtytricks.com. But assuming that the legitimate organization knows about the key compromise, they would be on the lookout for such trickery, and would presumably notify the DNS naming authorities to reject any attempt to modify the IP routing for their DNS name.
> 
> But putting up a server at a given IP address that contains a stolen key would effectively constitute a smoking gun pointed directly at the instigator's head, to mix a metaphor.  It provide prima facie evidence that they were responsible for the key theft.
> 


I'd like to point out that there is no Internet routing authority,
naming authority, or police. Bogus routes can be inserted into the
Internet infrastructure, DNS information changed (look at NSI), and
DNS spoofed. Additionally, a smoking gun is of little relevance if the
site in question is a compromised host or located in a jurisdiction of
little legal consequence, such as Russia, Croatia, or as recently
demonstrated by the ILOVEYOU virus, the Philippines.


> OK, I'll grant that this isn't absolutely airtight and foolproof, and that for some really, really important transactions it might be nice to actually check the web server's CRL, "just in case".  But assuming that you aren't involved in million dollar transactions, the risk seems very slight, and certainly acceptable to most users.
> 

All that is required is many transactions of less than USD $50 --
below the credit card companies' radar. This technique has been
perpetrated several times. Immediate examples include a Californian
ISP and a porn shop that kept changing names and shifting locations
globally.

It happens.


Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03886 for <[e-mail]>; Tue, 5 Sep 2000 10:14:22 -0700 (PDT)
Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA19178; Tue, 5 Sep 2000 13:15:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220803b5dad98663bf@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 5 Sep 2000 13:15:40 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Comment on AttributeCertificate draft
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ron,

>Stephen,
>
>The authors of RFC 2693 went to great lengths to explain why PKCs with
>Distinguished Names will not work on global scale and why multiple 
>certificates
>per user are inescapable.

There is nothing in X.509, or in the AC work that assumes a single 
cert per user. This mispercsption is helpful in supporting the SPKI 
ideas, but it is simply not true.

>  They specifically address the subject of
>authorizations and the mapping of authorizations to key holders, a subject AC
>tries to address as well. Their reasoning can be ignored but the 
>then ACs would
>suffer from caveats mentioned in the RFC above.

>Readers of this list should note that the cited RFC and the rest of 
>the SPKI documents, are experimental, not standards track.


>In my opinion, ACs should *allow* adherence to the SPKI model, being a real
>global-scale model suited for the internet, not just intra-enterprise but also
>inter-enterprise. In particular: local names & global identifiers (a 
>key issue),
>reduced security with AA and CA (sec. 3.1).

No. ACs are part of the PKIX WG and thus should be consistent with 
the model we have developed here.

>I do not think allowing SPKI adherence, given the simplicity of 
>SPKI, would not
>be too difficult. There is no question in my mind that it is a very powerful
>model suited for the inter-net.

PKIs are not simple, despite the inclusion of words to that effect 
:-).  Adding SPKI support will complicate ACs and we're not looking 
to make this a more complex standard.

Steve



Received: from fhufw.fhu.disa.mil (fhu2.fhu.disa.mil [207.132.160.62]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA03087 for <[e-mail]>; Tue, 5 Sep 2000 10:00:47 -0700 (PDT)
Received: from fhu2.fhu.disa.mil by fhufw.fhu.disa.mil via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Sep 2000 13:58:06 UT
Received: by fhu2.fhu.disa.mil with Internet Mail Service (5.5.2650.10) id <SGD6HYZX>; Tue, 5 Sep 2000 10:02:18 -0700
Message-ID: <[e-mail]>
From: "Baratta, Gary" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: unsubscribe
Date: Tue, 5 Sep 2000 10:02:17 -0700 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03086 for <[e-mail]>; Tue, 5 Sep 2000 10:00:46 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA25107; Tue, 5 Sep 2000 19:02:17 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 5 Sep 2000 19:02:18 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA00425; Tue, 5 Sep 2000 19:02:16 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA14776; Tue, 5 Sep 2000 19:02:16 +0200 (MET DST)
Date: Tue, 5 Sep 2000 19:02:16 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspensi on

> > The question is when and why do you want to discover whether a cert
> 
> No, that was not the actual question. Karl believes he has a valid case for
> asking the question "was this cert valid at t1 or between t1 and t2" and he
> wanted to have a standard way of expressing the query and the answer. I
> think we should separate the question of whether there are valid cases for
> asking such questions (and not whether there are cases where its not an
> interesting question to ask...) and how to best express the question.

My response was to Pat's remark.
To an extreme, without qualifying Karl's or Pat's question,
this approach seems equivalent to allowing to believe any kind of
non-sense, and force to treat how to express this non-sense in the best way. 

But let's assume that we want an online service that can detect this.

>  
> > Which date are you asking for, remember, the 'now' date is the one of
> > the OCSP server, and the answer of 'now' does not say whether
> > the cert is valid/invalid at 'now', but only that in case of 'good',
> > the server doesn't know anything negative at that moment. It
> > may happen that it receives a CRL a minute later, that has a
> > revoked cert with a revocation date 2 minutes ago, a new request
> > would now tell that. Since the two OCSP requests should inconsistent
> > information which of the two answer would you see for a validAt
> > send at the 'now' of the first response.     
> 
> Correct. For this to work revocation backwards in time can not be allowed
> (German SigG has this restriction, I don't know about Austrian). The
> response must contain the same "evaluateAt" (validAt, whatever) extension as
> the response, of course. The evaluateAt has to be less than the thisUpdate
> of the response. 

For what to work? I haven't said that something can work? 

If you allow backward revocation, the NO protocol to determine the actual
or past status can work in an absolute way. 

You still can spread the risk, as usual. Or, if the verifier
knows the probability curve of to how far a backwards revocation can occur,
it can wait until the risk becomes acceptable.  

The SigG does not say anywhere whether you can suspend and resume a cert.

I am not sure whether I understand the order of thisUpdate or evaluateAt: 

The OCSP responder has a the latest copy of a CRL of t1, it gets a request
asking for a status with an evaluation date of t2>t1. (t2 maybe less or
larger than the 'now' date of the server). 
what should the server respond?








  

 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02732 for <[e-mail]>; Tue, 5 Sep 2000 09:55:00 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 5 Sep 2000 09:56:27 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Tue, 05 Sep 2000 09:56:27 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <RMQWMNFB>; Tue, 05 Sep 2000 09:45:35 -0700
Content-return: allowed
Date: Tue, 05 Sep 2000 09:45:34 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP Common Profiles
To: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain;	charset="iso-8859-1"

I would like to agree, that if there is nothing fundamentally
broken with OCSP, we proceed with OCSP (with some clarifications)
along the standards process.

If the main driving force to redo OCSP is to allow for remote
path processing, it might be faster and cleaner to do it with
SCVP.

>From the mails I have seen on this list, it is unclear that there
is overwhelming support to making a bunch of changes to OCSP.

Comments?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Simon Tardell [mailto:[e-mail]]
> Sent: Tuesday, September 05, 2000 9:15 AM
> To: '[e-mail]'
> Subject: OCSP Common Profiles
> 
> 
> All,
> 
> In the interest of not delaying the standardization of OCSP, 
> I'd like to
> suggest that any extensions to OCSP that are not absolutely 
> core be moved to
> a separate RFC. A lot of these are interesting in _some 
> contexts_. These
> contexts will be common enough to warrant standardizations, 
> but should still
> not be part of the core protocol. Hence, I suggest that we 
> spin off a "OCSP
> Common Profiles" that would enumerate a number of 
> specializations of the
> protocol (such as the "validAt (orBetween...)" we're just 
> discussing). IMHO,
> the "archive cutoff" extension from RFC2560 also belongs to 
> this group. The
> semantics of that new document would be "if you want to 
> express this using
> OCSP, do it this way".
> 
> Simon.
> 
> Simon Tardell, Software Architect, iD2 Technologies
> voice [phone], fax [phone], cell [phone]
> [e-mail], http://www.iD2tech.com
> Securing the Internet economy
> 
> 


Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA29692 for <[e-mail]>; Tue, 5 Sep 2000 09:13:47 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Tue Sep 05 18:12:28 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <RPZ34P8X>; Tue, 5 Sep 2000 18:14:36 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: OCSP Common Profiles
Date: Tue, 5 Sep 2000 18:14:40 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

All,

In the interest of not delaying the standardization of OCSP, I'd like to
suggest that any extensions to OCSP that are not absolutely core be moved to
a separate RFC. A lot of these are interesting in _some contexts_. These
contexts will be common enough to warrant standardizations, but should still
not be part of the core protocol. Hence, I suggest that we spin off a "OCSP
Common Profiles" that would enumerate a number of specializations of the
protocol (such as the "validAt (orBetween...)" we're just discussing). IMHO,
the "archive cutoff" extension from RFC2560 also belongs to this group. The
semantics of that new document would be "if you want to express this using
OCSP, do it this way".

Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy




Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA29082 for <[e-mail]>; Tue, 5 Sep 2000 09:03:11 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Tue Sep 05 18:01:45 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <RPZ34P5S>; Tue, 5 Sep 2000 18:03:53 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Patrick G. Moore'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspensi on
Date: Tue, 5 Sep 2000 18:03:56 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> Hi,
> 
> In my case, the signing time is part of the signed data.  We may
> like to re-verify old data from our archives at any time.  Thus,
> we would also like a "VALID AT" type of option.  I agree that an interval
> could be problematic, if a cert was suspended for a period between
> the endpoints, how would you discover that.  Just checking the endpoints
> would not reveal the suspension.  I would say, if the app is uncertain
> of the signing time, let it make as many "VALID AT" queries 
> as it likes to make it happy.

I am not sure I follow. For the responder an interval is not problematic. If
it uses CRLs as the base of its answers it is only a problem if it misses a
CRL (in the interval), and then it has to return "unknown". For a client
there is no good way to know how many question it must ask in order to be
sure that it doesn't miss a quick suspension. Also, asking multiple
questions is not bandwidth conservative.

Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy



Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA28875 for <[e-mail]>; Tue, 5 Sep 2000 09:02:06 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 05 Sep 2000 10:03:00 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Tue, 05 Sep 2000 10:02:59 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Client-side revocation checking capability
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 ns.secondary.com id JAA28877

David, I agree with you completely.

But at the risk of arguing in circles, I would appreciate your thoughts on the need to do CRL checking of web site addresses, at least for the majority of applications.

Presumably there are two reasons why a web server's certificate would ever be revoked:

1.  The key has been compromised somehow, and (this is bit of a stretch), the organization knows that it has been compromised.

2.  The information contained in the certificate is no longer valid.

Now, since SSL downloads the certificates to be used to validate the session (they aren't obtained out of band somehow), I would contend that if the organization knows it has been compromised, it would immediately stop using that key and certificate  go get a new one, and use that one instead.

Likewise, if for example Land Rover wants to change their name from something like "Land Rover, a subsidiary of BMW" to "Land Rover, a subsidiary of the Ford Motor Company," they would just get a new certificate and start using it.

Now, I don't deny the possibility that VeriSign, upon hearing that Ford had bought Land Rover, might take it upon themselves to unilaterally revoke a certificate that identifies them as belong to BMW, but I think it is exceedingly unlikely.  In fact, it is rather hard for me to imagine ANY type of circumstance other than outright, blatant fraud of the most egregious kind that would cause VeriSign to take such unilateral action -- they would almost surely go the cease and desist route, rather than subjecting themselves to a potentially huge suit for damages by unilaterally revoking a certificate. (I'm only using VeriSign as the example here because of their dominance int he server certificate market.)

So that leaves us with the key compromise possibility.

Now, in order to somehow benefit from a key compromise, the perpetrator would have to: (1) first install the compromised key on a server somewhere, and then (2) spoof or otherwise divert the DNS routing so that requests to www.whitehouse.gov go to say  www.dirtytricks.com. But assuming that the legitimate organization knows about the key compromise, they would be on the lookout for such trickery, and would presumably notify the DNS naming authorities to reject any attempt to modify the IP routing for their DNS name.

But putting up a server at a given IP address that contains a stolen key would effectively constitute a smoking gun pointed directly at the instigator's head, to mix a metaphor.  It provide prima facie evidence that they were responsible for the key theft.

OK, I'll grant that this isn't absolutely airtight and foolproof, and that for some really, really important transactions it might be nice to actually check the web server's CRL, "just in case".  But assuming that you aren't involved in million dollar transactions, the risk seems very slight, and certainly acceptable to most users.

Do you agree with this analysis?

Bob

>>> "David P. Kemp" <[e-mail]> 09/01/00 10:53AM >>>

> From: [e-mail] 
>
> Now looking at possibly a trivial occurance of relying party checking ... 
maybe
> only a trivial 99.99999999999999% of all relying party "checking" currently
> going on ... it would appear that the most common occurance of a relying party
> checking something is a SSL relying party checking a domain name.
> 99.999999999999% of all such checking might not seem like a valid situation to
> consider.


What is the threat that the PKI is addressing?   My assumption is that
in 99.99999999% of the cases the company hosting the web server is interested
in preventing the following:

1) user sees "www.companyA.com" on an advertisement and types it in, or
   clicks a link.

2) DNS has been hijacked, the user connects to a bogus server, and the
   user gives up his personal info to the bad guy.  Or the user sees a
   parody of www.companyA.com, or worse.

A server certificate issued by a CA to the company binds a company name
(real world and/or DNS) to the company's private key.  If DNS has been
hijacked, the bad guy still can't impersonate the company web site.
I'd say that 99.999999% of the relying party checking involves seeing
the company's legitimate content; the DNS name is largely irrelevant
for the user's purposes.  The user could type an IP address, or any one
of a number of DNS names, and as long as he gets to the company's
information he couldn't care less how he got it.

In fact, including DNSnames in relying party (browser) checking causes
unnecessary problems with virtual hosting. "www.CompanyA.com" should be
a DNS *Name*, something the user types when he wants to see CompanyA's
information.  It shouldn't be any problem if CompanyA's information is
actually being served from https://www.hosting-service.com/account51/;
the only thing that matters is that the user can be referred from what
he types to where the information resides, and that the legitimate
information provider has CompanyA's private key.

 * DNS security should be about binding DNS names to IP addresses, and 
   should have nothing to do with EE keys.
 * PKI security should be about binding names (DNS, rfc822, or a real
   world brand name - "Ford Motor Company") to keys.  The CA's responsibility
   is to ensure that the brand owner and the key are properly matched -
   this is far beyond the scope of a DNS administrator's duties.
 * application security should be about protecting whatever is meaningful
   about the user with the user's private key.  In the case of web servers,
   what is meaningful is the company's content, not a DNSname.

If you try to take shortcuts (by combining DNS and PKI, for example),
you prevent useful things from happening.  DNS security supports
infrastructure availability; PKI supports application security.
Unnecessarily sacrificing web server functionality for security just
gives security a bad name.  And increasing the DNS administrator's
workload hinders the adoption of simple yet valuable name-to-IP
security.








Received: from naigwy (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28281 for <[e-mail]>; Tue, 5 Sep 2000 08:49:21 -0700 (PDT)
Received: FROM aunt15.ausys.se BY naigwy ; Tue Sep 05 17:46:57 2000 +0200
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <RPZ34PWR>; Tue, 5 Sep 2000 17:49:05 +0200
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspensi on
Date: Tue, 5 Sep 2000 17:49:07 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> The question is when and why do you want to discover whether a cert

No, that was not the actual question. Karl believes he has a valid case for
asking the question "was this cert valid at t1 or between t1 and t2" and he
wanted to have a standard way of expressing the query and the answer. I
think we should separate the question of whether there are valid cases for
asking such questions (and not whether there are cases where its not an
interesting question to ask...) and how to best express the question.
 
> Which date are you asking for, remember, the 'now' date is the one of
> the OCSP server, and the answer of 'now' does not say whether
> the cert is valid/invalid at 'now', but only that in case of 'good',
> the server doesn't know anything negative at that moment. It
> may happen that it receives a CRL a minute later, that has a
> revoked cert with a revocation date 2 minutes ago, a new request
> would now tell that. Since the two OCSP requests should inconsistent
> information which of the two answer would you see for a validAt
> send at the 'now' of the first response.     

Correct. For this to work revocation backwards in time can not be allowed
(German SigG has this restriction, I don't know about Austrian). The
response must contain the same "evaluateAt" (validAt, whatever) extension as
the response, of course. The evaluateAt has to be less than the thisUpdate
of the response. 

Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice [phone], fax [phone], cell [phone]
[e-mail], http://www.iD2tech.com
Securing the Internet economy


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20234 for <[e-mail]>; Tue, 5 Sep 2000 08:10:27 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA23762; Tue, 5 Sep 2000 17:11:58 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 5 Sep 2000 17:11:58 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA29879; Tue, 5 Sep 2000 17:11:57 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA14734; Tue, 5 Sep 2000 17:11:56 +0200 (MET DST)
Date: Tue, 5 Sep 2000 17:11:56 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: OCSP support for historical reference to certificate suspension

> 
> Hi,
> 
> In my case, the signing time is part of the signed data.  We may
> like to re-verify old data from our archives at any time.  Thus,
ok, you MAY LIKE. :-)

> we would also like a "VALID AT" type of option.  I agree that an interval
> could be problematic, if a cert was suspended for a period between
> the endpoints, how would you discover that.  Just checking the endpoints
> would not reveal the suspension.  I would say, if the app is uncertain
> of the signing time, let it make as many "VALID AT" queries as it likes
> to make it happy.

The question is when and why do you want to discover whether a cert
had been suspended become VALID later again. If you need this in order
to make audit trails of a verifying application that does authentication,
just let them log the ocsp response.

If you have an application that does anything serious with long term
documents, AND if you want detect the suspended case, let the originator
add appropriate information, or never make suspended certs valid again,
etc.   

Which date are you asking for, remember, the 'now' date is the one of
the OCSP server, and the answer of 'now' does not say whether
the cert is valid/invalid at 'now', but only that in case of 'good',
the server doesn't know anything negative at that moment. It
may happen that it receives a CRL a minute later, that has a
revoked cert with a revocation date 2 minutes ago, a new request
would now tell that. Since the two OCSP requests should inconsistent
information which of the two answer would you see for a validAt
send at the 'now' of the first response.     


Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17036 for <[e-mail]>; Tue, 5 Sep 2000 07:45:14 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA02304; Tue, 5 Sep 2000 07:42:46 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <R9H9LPCX>; Tue, 5 Sep 2000 07:45:10 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "Patrick G. Moore" <[e-mail]>, [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspensi on
Date: Tue, 5 Sep 2000 07:45:09 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Pat,

Am I correct in concluding that a single "validAt" date would address your
needs?

Mike



> -----Original Message-----
> From: Patrick G. Moore [mailto:[e-mail]]
> Sent: Friday, September 01, 2000 2:47 PM
> To: [e-mail]; [e-mail]
> Subject: Re: OCSP support for historical reference to certificate
> suspension
> 
> 
> Hi,
> 
> In my case, the signing time is part of the signed data.  We may
> like to re-verify old data from our archives at any time.  Thus,
> we would also like a "VALID AT" type of option.  I agree that 
> an interval
> could be problematic, if a cert was suspended for a period between
> the endpoints, how would you discover that.  Just checking 
> the endpoints
> would not reveal the suspension.  I would say, if the app is uncertain
> of the signing time, let it make as many "VALID AT" queries 
> as it likes
> to make it happy.
> 
> Pat
> 
> Michael Myers wrote:
> > 
> > This is first I've heard of this specific requirement but 
> it seems quite
> > natural once the need is exposed.  We'll take this into 
> account in the
> > 2560bis work.  Thanks also for the OPTIONAL.  That'll make 
> things a little
> > bit easier.
> > 
> > But for discussion purposes, I've been architecting under 
> the presumption
> > that in the instance when signing time was important, the 
> time when the
> > digital signature was created would be integrated somehow 
> into the subject
> > electronic document and thus there exist a well-defined time.
> > 
> > I believe you're implying that it may not be the case that 
> signing time is
> > integrated into a subject document, and so one is led to 
> bracket the signing
> > time.  Could confirm please, or otherwise clarify?  Thanks.
> > 
> > Mike


Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16929 for <[e-mail]>; Tue, 5 Sep 2000 07:44:37 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id HAA02299; Tue, 5 Sep 2000 07:42:43 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <R9H9LPCW>; Tue, 5 Sep 2000 07:45:07 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Khaja Ahmed <[e-mail]>, [e-mail]
Subject: RE: OCSP in S/MIME and IPSEC
Date: Tue, 5 Sep 2000 07:45:06 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Khaja,

I wouldn't hold that including OCSP responses in S/MIME is "widely accepted"
at this point, nor "well understood", but it has been discussed.  Your
proposal into this forum simply raised the visibility of this option beyond
the current casual conversations.

Perhaps it's time to formalize the approach given the field experience to
date with OCSP.  I agree that it's best for other signature format groups
(including our peers in the S/MIME group) to consider this integration.  I'm
not as immediately familiar with CMS as I know others are on this list.

Perhaps Russ Housley, Jim Schaad, Dave Solo et. al. would care to chime in?

Regarding integration with IPSEC as proposed, perhaps someone leading in
Sara's IPSRA WG would equivalently offer themselves as a point of
convergence?

Mike



-----Original Message-----
From: Khaja Ahmed [mailto:[e-mail]]
Sent: Friday, September 01, 2000 2:21 PM
To: 'Michael Myers'; [e-mail]
Subject: RE: OCSP in S/MIME and IPSEC


Michael, 
I was just unaware that this (signature with bundled OCSP response) was a
widely accepted (or at least well understood) "use case."   I was also
unaware that you and others had documented it elsewhere.  As someone else on
this thread pointed out the best way to formalize this is probably not in
the son-of-2560 but perhaps in signature format standards, in s/mime, etc.
I see the wisdom of that view and agree with it.
What you are calling "Asymmetric OCSP" is precisely what is needed in many
applications that I am aware of.  It has also been called "Freshness Proof"
in some applications.  "That which we call a rose by any other name..." etc.
By all means sign me up as a taker for this.  The only question that remains
is:  Where is this use best formalized and documented?  PKCS#7, PEM, S/MIME,
XMLDSIG or application that use these?  I do feel that it is important
enough and of sufficiently wide interest to warrant formalization in
standards.  I will be happy to support this effort in any way I can.
Khaja 
-----Original Message----- 
From: Michael Myers [mailto:[e-mail]] 
Sent: Friday, September 01, 2000 12:51 PM 
To: Khaja Ahmed; [e-mail] 
Subject: OCSP in S/MIME and IPSEC 


Khaja, 
I heartily agree.  In fact, this was one of the leading "use cases" I cited 
very early on for OCSP's utility.  I don't see though that this case 
requires any amendment to OCSP.  Could you elaborate on why you think this 
is so? 
And as long as we're on the subject, I've been off-and-on talking to folks 
about an operational concept I've been calling "Asymmetric OCSP."  (first 
briefed publicly a couple of RSAs ago.) 
The concept applies best to the road warrior using IPSEC to securely reach 
back home, to a customer site on a trouble call, etc..  Basically, during 
the IPSEC setup phase the IPSEC server or gateway first checks the RW's cert

by reference to an enterprise OCSP server.  There you get 
revocation/validation enforcement on the client.  The server or gateway then

turns around and asks the OCSP server for status on it's (the gw's) cert, 
puts this into the handshake and so delivers back to the client 
revocation/validation assurance. 
It's in-band and clean since the client doesn't have to collaterally run 
LDAP etc. to fetch a CRL.  Also, there's no client-side state maintenance 
re: CRLs.  The client gets realtime effects on the revocation of a gw's 
cert.  Finally, all the heavy lifting is done in the back office where 
there's sufficient platform cycles and bandwidth to do this efficiently (vs.

forcing a limited client to go fetch CRLs from wherever using whatever 
protocol.)  
Takers, anyone? 
Mike 


-----Original Message----- 
From: Khaja Ahmed [mailto:[e-mail]] 
Sent: Thursday, August 31, 2000 4:27 PM 
To: 'Karl Scheibelhofer'; Peter Sylvester; [e-mail]; 
[e-mail] 
Subject: RE: RFC 2560 - OCSP - Clarification 


Under some circumstances or for some communities it may be possible for the 
sender of the signed data to send along with the signed data proof that at 
the time of signing (+/- some tolerance limit) the certificate was not 
revoked. In other words, the sender could get an ocsp response from a common

trusted responder and include this with the transmission of the signed data.

This approach offers the advantage that the response can be archived / 
stored along with the signature.  At a later date when the archived / stored

signed data and signature is retrieved it can be readily verified as having 
been valid at creation time (+/- tolerance limit).  
Is this not an ability that we should formalize and add to appropriate 
protocols like OCSP? 
Khaja 
Phone: (+43) [phone] 


Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18333 for <[e-mail]>; Tue, 5 Sep 2000 00:16:12 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <Q8W94V93>; Tue, 5 Sep 2000 03:16:46 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Ray Langford '" <[e-mail]>, Khaja Ahmed <[e-mail]>, "''Michael Myers' '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP in S/MIME and IPSEC
Date: Tue, 5 Sep 2000 03:16:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C01709.3F76A770"

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_01C01709.3F76A770
Content-Type: text/plain;
	charset="iso-8859-1"

Ray,

This has been most helpful.  Thanks much.  Are you, or is anyone else, aware
of efforts to add such validity proofs to PKCS#7 and xmldsig?

Khaja

-----Original Message-----
From: Ray Langford
To: Khaja Ahmed; 'Michael Myers'; [e-mail]
Sent: 9/5/00 12:25 AM
Subject: Re: OCSP in S/MIME and IPSEC

Khaja,
 
Hello. We also agree that bundling validation data (i.e. OCSP responses)
with the signature can be beneficial (eg. for archival and later
verification as you discussed). This capability has been in our Assured
Transaction products for a while now. The storage of the validation data
is managed via Assured Transaction Signature Policies. If you would like
to see this "in action", I would invite you to download our latest
Assured Office product (4.0, which is now in beta). Just send an email
to [e-mail] <mailto:[e-mail]>  to request the URL to the
Assured Office beta website.
 
Also, a draft RFC was recently published
<draft-ietf-smime-esformats-01.txt> as part of the S/MIME working group,
which discusses bundling validation data with the signature. We are
reviewing this draft and hope to help with this effort however we can.
 
Regards,
 
-- Ray


----- Original Message ----- 
From: Khaja  <mailto:[e-mail]> Ahmed 
To: 'Michael Myers' <mailto:[e-mail]>  ; [e-mail]
<mailto:[e-mail]>  
Sent: Friday, September 01, 2000 4:21 PM
Subject: RE: OCSP in S/MIME and IPSEC



Michael, 

I was just unaware that this (signature with bundled OCSP response) was
a widely accepted (or at least well understood) "use case."   I was also
unaware that you and others had documented it elsewhere.  As someone
else on this thread pointed out the best way to formalize this is
probably not in the son-of-2560 but perhaps in signature format
standards, in s/mime, etc.  I see the wisdom of that view and agree with
it.

What you are calling "Asymmetric OCSP" is precisely what is needed in
many applications that I am aware of.  It has also been called
"Freshness Proof" in some applications.  "That which we call a rose by
any other name..." etc.  By all means sign me up as a taker for this.
The only question that remains is:  Where is this use best formalized
and documented?  PKCS#7, PEM, S/MIME, XMLDSIG or application that use
these?  I do feel that it is important enough and of sufficiently wide
interest to warrant formalization in standards.  I will be happy to
support this effort in any way I can.

Khaja 

-----Original Message----- 
From: Michael Myers [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Friday, September 01, 2000 12:51 PM 
To: Khaja Ahmed; [e-mail] 
Subject: OCSP in S/MIME and IPSEC 


Khaja, 

I heartily agree.  In fact, this was one of the leading "use cases" I
cited 
very early on for OCSP's utility.  I don't see though that this case 
requires any amendment to OCSP.  Could you elaborate on why you think
this 
is so? 

And as long as we're on the subject, I've been off-and-on talking to
folks 
about an operational concept I've been calling "Asymmetric OCSP."
(first 
briefed publicly a couple of RSAs ago.) 

The concept applies best to the road warrior using IPSEC to securely
reach 
back home, to a customer site on a trouble call, etc..  Basically,
during 
the IPSEC setup phase the IPSEC server or gateway first checks the RW's
cert 
by reference to an enterprise OCSP server.  There you get 
revocation/validation enforcement on the client.  The server or gateway
then 
turns around and asks the OCSP server for status on it's (the gw's)
cert, 
puts this into the handshake and so delivers back to the client 
revocation/validation assurance. 

It's in-band and clean since the client doesn't have to collaterally run

LDAP etc. to fetch a CRL.  Also, there's no client-side state
maintenance 
re: CRLs.  The client gets realtime effects on the revocation of a gw's 
cert.  Finally, all the heavy lifting is done in the back office where 
there's sufficient platform cycles and bandwidth to do this efficiently
(vs. 
forcing a limited client to go fetch CRLs from wherever using whatever 
protocol.)  

Takers, anyone? 

Mike 


-----Original Message----- 
From: Khaja Ahmed [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, August 31, 2000 4:27 PM 
To: 'Karl Scheibelhofer'; Peter Sylvester; [e-mail]; 
[e-mail] 
Subject: RE: RFC 2560 - OCSP - Clarification 


Under some circumstances or for some communities it may be possible for
the 
sender of the signed data to send along with the signed data proof that
at 
the time of signing (+/- some tolerance limit) the certificate was not 
revoked. In other words, the sender could get an ocsp response from a
common 
trusted responder and include this with the transmission of the signed
data. 
This approach offers the advantage that the response can be archived / 
stored along with the signature.  At a later date when the archived /
stored 
signed data and signature is retrieved it can be readily verified as
having 
been valid at creation time (+/- tolerance limit).  
Is this not an ability that we should formalize and add to appropriate 
protocols like OCSP? 
Khaja 
Phone: (+43) [phone] 


------_=_NextPart_001_01C01709.3F76A770
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: OCSP in S/MIME and IPSEC</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ray,</FONT>
</P>

<P><FONT SIZE=3D2>This has been most helpful.&nbsp; Thanks much.&nbsp; =
Are you, or is anyone else, aware of efforts to add such validity =
proofs to PKCS#7 and xmldsig?</FONT></P>

<P><FONT SIZE=3D2>Khaja</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ray Langford</FONT>
<BR><FONT SIZE=3D2>To: Khaja Ahmed; 'Michael Myers'; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Sent: 9/5/00 12:25 AM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: OCSP in S/MIME and IPSEC</FONT>
</P>

<P><FONT SIZE=3D2>Khaja,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Hello. We also agree that bundling validation data =
(i.e. OCSP responses)</FONT>
<BR><FONT SIZE=3D2>with the signature can be beneficial (eg. for =
archival and later</FONT>
<BR><FONT SIZE=3D2>verification as you discussed). This capability has =
been in our Assured</FONT>
<BR><FONT SIZE=3D2>Transaction products for a while now. The storage of =
the validation data</FONT>
<BR><FONT SIZE=3D2>is managed via Assured Transaction Signature =
Policies. If you would like</FONT>
<BR><FONT SIZE=3D2>to see this &quot;in action&quot;, I would invite =
you to download our latest</FONT>
<BR><FONT SIZE=3D2>Assured Office product (4.0, which is now in beta). =
Just send an email</FONT>
<BR><FONT SIZE=3D2>to [e-mail] &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>&gt;&nbsp; =
to request the URL to the</FONT>
<BR><FONT SIZE=3D2>Assured Office beta website.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Also, a draft RFC was recently published</FONT>
<BR><FONT SIZE=3D2>&lt;draft-ietf-smime-esformats-01.txt&gt; as part of =
the S/MIME working group,</FONT>
<BR><FONT SIZE=3D2>which discusses bundling validation data with the =
signature. We are</FONT>
<BR><FONT SIZE=3D2>reviewing this draft and hope to help with this =
effort however we can.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-- Ray</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2>From: Khaja&nbsp; &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>&gt; Ahmed </FONT>
<BR><FONT SIZE=3D2>To: 'Michael Myers' &lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>&gt;&n=
bsp; ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>&gt;&nbsp;=
 </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, September 01, 2000 4:21 PM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP in S/MIME and IPSEC</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Michael, </FONT>
</P>

<P><FONT SIZE=3D2>I was just unaware that this (signature with bundled =
OCSP response) was</FONT>
<BR><FONT SIZE=3D2>a widely accepted (or at least well understood) =
&quot;use case.&quot;&nbsp;&nbsp; I was also</FONT>
<BR><FONT SIZE=3D2>unaware that you and others had documented it =
elsewhere.&nbsp; As someone</FONT>
<BR><FONT SIZE=3D2>else on this thread pointed out the best way to =
formalize this is</FONT>
<BR><FONT SIZE=3D2>probably not in the son-of-2560 but perhaps in =
signature format</FONT>
<BR><FONT SIZE=3D2>standards, in s/mime, etc.&nbsp; I see the wisdom of =
that view and agree with</FONT>
<BR><FONT SIZE=3D2>it.</FONT>
</P>

<P><FONT SIZE=3D2>What you are calling &quot;Asymmetric OCSP&quot; is =
precisely what is needed in</FONT>
<BR><FONT SIZE=3D2>many applications that I am aware of.&nbsp; It has =
also been called</FONT>
<BR><FONT SIZE=3D2>&quot;Freshness Proof&quot; in some =
applications.&nbsp; &quot;That which we call a rose by</FONT>
<BR><FONT SIZE=3D2>any other name...&quot; etc.&nbsp; By all means sign =
me up as a taker for this.</FONT>
<BR><FONT SIZE=3D2>The only question that remains is:&nbsp; Where is =
this use best formalized</FONT>
<BR><FONT SIZE=3D2>and documented?&nbsp; PKCS#7, PEM, S/MIME, XMLDSIG =
or application that use</FONT>
<BR><FONT SIZE=3D2>these?&nbsp; I do feel that it is important enough =
and of sufficiently wide</FONT>
<BR><FONT SIZE=3D2>interest to warrant formalization in =
standards.&nbsp; I will be happy to</FONT>
<BR><FONT SIZE=3D2>support this effort in any way I can.</FONT>
</P>

<P><FONT SIZE=3D2>Khaja </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Michael Myers [ <A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A></FONT=
>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>&gt; =
] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, September 01, 2000 12:51 PM </FONT>
<BR><FONT SIZE=3D2>To: Khaja Ahmed; [e-mail] </FONT>
<BR><FONT SIZE=3D2>Subject: OCSP in S/MIME and IPSEC </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Khaja, </FONT>
</P>

<P><FONT SIZE=3D2>I heartily agree.&nbsp; In fact, this was one of the =
leading &quot;use cases&quot; I</FONT>
<BR><FONT SIZE=3D2>cited </FONT>
<BR><FONT SIZE=3D2>very early on for OCSP's utility.&nbsp; I don't see =
though that this case </FONT>
<BR><FONT SIZE=3D2>requires any amendment to OCSP.&nbsp; Could you =
elaborate on why you think</FONT>
<BR><FONT SIZE=3D2>this </FONT>
<BR><FONT SIZE=3D2>is so? </FONT>
</P>

<P><FONT SIZE=3D2>And as long as we're on the subject, I've been =
off-and-on talking to</FONT>
<BR><FONT SIZE=3D2>folks </FONT>
<BR><FONT SIZE=3D2>about an operational concept I've been calling =
&quot;Asymmetric OCSP.&quot;</FONT>
<BR><FONT SIZE=3D2>(first </FONT>
<BR><FONT SIZE=3D2>briefed publicly a couple of RSAs ago.) </FONT>
</P>

<P><FONT SIZE=3D2>The concept applies best to the road warrior using =
IPSEC to securely</FONT>
<BR><FONT SIZE=3D2>reach </FONT>
<BR><FONT SIZE=3D2>back home, to a customer site on a trouble call, =
etc..&nbsp; Basically,</FONT>
<BR><FONT SIZE=3D2>during </FONT>
<BR><FONT SIZE=3D2>the IPSEC setup phase the IPSEC server or gateway =
first checks the RW's</FONT>
<BR><FONT SIZE=3D2>cert </FONT>
<BR><FONT SIZE=3D2>by reference to an enterprise OCSP server.&nbsp; =
There you get </FONT>
<BR><FONT SIZE=3D2>revocation/validation enforcement on the =
client.&nbsp; The server or gateway</FONT>
<BR><FONT SIZE=3D2>then </FONT>
<BR><FONT SIZE=3D2>turns around and asks the OCSP server for status on =
it's (the gw's)</FONT>
<BR><FONT SIZE=3D2>cert, </FONT>
<BR><FONT SIZE=3D2>puts this into the handshake and so delivers back to =
the client </FONT>
<BR><FONT SIZE=3D2>revocation/validation assurance. </FONT>
</P>

<P><FONT SIZE=3D2>It's in-band and clean since the client doesn't have =
to collaterally run</FONT>
</P>

<P><FONT SIZE=3D2>LDAP etc. to fetch a CRL.&nbsp; Also, there's no =
client-side state</FONT>
<BR><FONT SIZE=3D2>maintenance </FONT>
<BR><FONT SIZE=3D2>re: CRLs.&nbsp; The client gets realtime effects on =
the revocation of a gw's </FONT>
<BR><FONT SIZE=3D2>cert.&nbsp; Finally, all the heavy lifting is done =
in the back office where </FONT>
<BR><FONT SIZE=3D2>there's sufficient platform cycles and bandwidth to =
do this efficiently</FONT>
<BR><FONT SIZE=3D2>(vs. </FONT>
<BR><FONT SIZE=3D2>forcing a limited client to go fetch CRLs from =
wherever using whatever </FONT>
<BR><FONT SIZE=3D2>protocol.)&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Takers, anyone? </FONT>
</P>

<P><FONT SIZE=3D2>Mike </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Khaja Ahmed [ <A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A></FONT>
<BR><FONT SIZE=3D2>&lt;<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>&gt; ] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, August 31, 2000 4:27 PM </FONT>
<BR><FONT SIZE=3D2>To: 'Karl Scheibelhofer'; Peter Sylvester; =
[e-mail]; </FONT>
<BR><FONT SIZE=3D2>[e-mail] </FONT>
<BR><FONT SIZE=3D2>Subject: RE: RFC 2560 - OCSP - Clarification </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Under some circumstances or for some communities it =
may be possible for</FONT>
<BR><FONT SIZE=3D2>the </FONT>
<BR><FONT SIZE=3D2>sender of the signed data to send along with the =
signed data proof that</FONT>
<BR><FONT SIZE=3D2>at </FONT>
<BR><FONT SIZE=3D2>the time of signing (+/- some tolerance limit) the =
certificate was not </FONT>
<BR><FONT SIZE=3D2>revoked. In other words, the sender could get an =
ocsp response from a</FONT>
<BR><FONT SIZE=3D2>common </FONT>
<BR><FONT SIZE=3D2>trusted responder and include this with the =
transmission of the signed</FONT>
<BR><FONT SIZE=3D2>data. </FONT>
<BR><FONT SIZE=3D2>This approach offers the advantage that the response =
can be archived / </FONT>
<BR><FONT SIZE=3D2>stored along with the signature.&nbsp; At a later =
date when the archived /</FONT>
<BR><FONT SIZE=3D2>stored </FONT>
<BR><FONT SIZE=3D2>signed data and signature is retrieved it can be =
readily verified as</FONT>
<BR><FONT SIZE=3D2>having </FONT>
<BR><FONT SIZE=3D2>been valid at creation time (+/- tolerance =
limit).&nbsp; </FONT>
<BR><FONT SIZE=3D2>Is this not an ability that we should formalize and =
add to appropriate </FONT>
<BR><FONT SIZE=3D2>protocols like OCSP? </FONT>
<BR><FONT SIZE=3D2>Khaja </FONT>
<BR><FONT SIZE=3D2>Phone: (+43) [phone] </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01709.3F76A770--


Received: from pdcmequon.frontiertech.com (PDCMEQUON.frontiertech.com [192.104.32.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06505 for <[e-mail]>; Mon, 4 Sep 2000 21:22:45 -0700 (PDT)
Received: from rock105 (rock105.frontiertech.com [192.104.32.105]) by pdcmequon.frontiertech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SCBAZN8D; Mon, 4 Sep 2000 23:20:51 -0500
Message-ID: <005101c016f1$615eb520$[e-mail]>
From: "Ray Langford" <[e-mail]>
To: "Khaja Ahmed" <[e-mail]>, "'Michael Myers'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: OCSP in S/MIME and IPSEC
Date: Mon, 4 Sep 2000 23:25:53 -0500
Organization: E-Lock Technologies
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C016C7.78671B60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

This is a multi-part message in MIME format.

------=_NextPart_000_004E_01C016C7.78671B60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: OCSP in S/MIME and IPSECKhaja,

Hello. We also agree that bundling validation data (i.e. OCSP responses) =
with the signature can be beneficial (eg. for archival and later =
verification as you discussed). This capability has been in our Assured =
Transaction products for a while now. The storage of the validation data =
is managed via Assured Transaction Signature Policies. If you would like =
to see this "in action", I would invite you to download our latest =
Assured Office product (4.0, which is now in beta). Just send an email =
to [e-mail] to request the URL to the Assured Office beta =
website.

Also, a draft RFC was recently published =
<draft-ietf-smime-esformats-01.txt> as part of the S/MIME working group, =
which discusses bundling validation data with the signature. We are =
reviewing this draft and hope to help with this effort however we can.

Regards,

-- Ray

  ----- Original Message -----=20
  From: Khaja Ahmed=20
  To: 'Michael Myers' ; [e-mail]=20
  Sent: Friday, September 01, 2000 4:21 PM
  Subject: RE: OCSP in S/MIME and IPSEC


  Michael,=20

  I was just unaware that this (signature with bundled OCSP response) =
was a widely accepted (or at least well understood) "use case."   I was =
also unaware that you and others had documented it elsewhere.  As =
someone else on this thread pointed out the best way to formalize this =
is probably not in the son-of-2560 but perhaps in signature format =
standards, in s/mime, etc.  I see the wisdom of that view and agree with =
it.

  What you are calling "Asymmetric OCSP" is precisely what is needed in =
many applications that I am aware of.  It has also been called =
"Freshness Proof" in some applications.  "That which we call a rose by =
any other name..." etc.  By all means sign me up as a taker for this.  =
The only question that remains is:  Where is this use best formalized =
and documented?  PKCS#7, PEM, S/MIME, XMLDSIG or application that use =
these?  I do feel that it is important enough and of sufficiently wide =
interest to warrant formalization in standards.  I will be happy to =
support this effort in any way I can.

  Khaja=20

  -----Original Message-----=20
  From: Michael Myers [mailto:[e-mail]]=20
  Sent: Friday, September 01, 2000 12:51 PM=20
  To: Khaja Ahmed; [e-mail]=20
  Subject: OCSP in S/MIME and IPSEC=20



  Khaja,=20

  I heartily agree.  In fact, this was one of the leading "use cases" I =
cited=20
  very early on for OCSP's utility.  I don't see though that this case=20
  requires any amendment to OCSP.  Could you elaborate on why you think =
this=20
  is so?=20

  And as long as we're on the subject, I've been off-and-on talking to =
folks=20
  about an operational concept I've been calling "Asymmetric OCSP."  =
(first=20
  briefed publicly a couple of RSAs ago.)=20

  The concept applies best to the road warrior using IPSEC to securely =
reach=20
  back home, to a customer site on a trouble call, etc..  Basically, =
during=20
  the IPSEC setup phase the IPSEC server or gateway first checks the =
RW's cert=20
  by reference to an enterprise OCSP server.  There you get=20
  revocation/validation enforcement on the client.  The server or =
gateway then=20
  turns around and asks the OCSP server for status on it's (the gw's) =
cert,=20
  puts this into the handshake and so delivers back to the client=20
  revocation/validation assurance.=20

  It's in-band and clean since the client doesn't have to collaterally =
run=20
  LDAP etc. to fetch a CRL.  Also, there's no client-side state =
maintenance=20
  re: CRLs.  The client gets realtime effects on the revocation of a =
gw's=20
  cert.  Finally, all the heavy lifting is done in the back office where =

  there's sufficient platform cycles and bandwidth to do this =
efficiently (vs.=20
  forcing a limited client to go fetch CRLs from wherever using whatever =

  protocol.) =20

  Takers, anyone?=20

  Mike=20



  -----Original Message-----=20
  From: Khaja Ahmed [mailto:[e-mail]]=20
  Sent: Thursday, August 31, 2000 4:27 PM=20
  To: 'Karl Scheibelhofer'; Peter Sylvester; [e-mail];=20
  [e-mail]=20
  Subject: RE: RFC 2560 - OCSP - Clarification=20



  Under some circumstances or for some communities it may be possible =
for the=20
  sender of the signed data to send along with the signed data proof =
that at=20
  the time of signing (+/- some tolerance limit) the certificate was not =

  revoked. In other words, the sender could get an ocsp response from a =
common=20
  trusted responder and include this with the transmission of the signed =
data.=20
  This approach offers the advantage that the response can be archived / =

  stored along with the signature.  At a later date when the archived / =
stored=20
  signed data and signature is retrieved it can be readily verified as =
having=20
  been valid at creation time (+/- tolerance limit). =20
  Is this not an ability that we should formalize and add to appropriate =

  protocols like OCSP?=20
  Khaja=20
  Phone: (+43) [phone]=20


------=_NextPart_000_004E_01C016C7.78671B60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: OCSP in S/MIME and IPSEC</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Khaja,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Hello. We also agree that bundling validation data =
(i.e. OCSP=20
responses) with the signature can be beneficial (eg. for archival and =
later=20
verification as you discussed). This capability has been in our Assured=20
Transaction products for a while now. The storage of the validation data =
is=20
managed via Assured Transaction Signature Policies. If you would like to =
see=20
this "in action", I would invite you to download our latest Assured =
Office=20
product (4.0, which is now in beta). Just send an email to <A=20
href=3D"mailto:[e-mail]">[e-mail]</A> to request the URL =
to the=20
Assured Office beta website.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Also, a draft RFC was recently published=20
&lt;draft-ietf-smime-esformats-01.txt&gt; as part of the S/MIME working =
group,=20
which discusses bundling validation data with the signature. We are =
reviewing=20
this draft and hope to help with this effort however we =
can.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>-- Ray<BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Khaja=20
  Ahmed</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Michael Myers'</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">[e-mail]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, September 01, =
2000 4:21=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: OCSP in S/MIME and =

  IPSEC</DIV>
  <DIV><FONT size=3D2></FONT><BR></DIV>
  <P><FONT size=3D2>Michael,</FONT> </P>
  <P><FONT size=3D2>I was just unaware that this (signature with bundled =
OCSP=20
  response) was a widely accepted (or at least well understood) "use=20
  case."&nbsp;&nbsp; I was also unaware that you and others had =
documented it=20
  elsewhere.&nbsp; As someone else on this thread pointed out the best =
way to=20
  formalize this is probably not in the son-of-2560 but perhaps in =
signature=20
  format standards, in s/mime, etc.&nbsp; I see the wisdom of that view =
and=20
  agree with it.</FONT></P>
  <P><FONT size=3D2>What you are calling "Asymmetric OCSP" is precisely =
what is=20
  needed in many applications that I am aware of.&nbsp; It has also been =
called=20
  "Freshness Proof" in some applications.&nbsp; "That which we call a =
rose by=20
  any other name..." etc.&nbsp; By all means sign me up as a taker for=20
  this.&nbsp; The only question that remains is:&nbsp; Where is this use =
best=20
  formalized and documented?&nbsp; PKCS#7, PEM, S/MIME, XMLDSIG or =
application=20
  that use these?&nbsp; I do feel that it is important enough and of=20
  sufficiently wide interest to warrant formalization in =
standards.&nbsp; I will=20
  be happy to support this effort in any way I can.</FONT></P>
  <P><FONT size=3D2>Khaja</FONT> </P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Michael Myers [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT=
>=20
  <BR><FONT size=3D2>Sent: Friday, September 01, 2000 12:51 PM</FONT> =
<BR><FONT=20
  size=3D2>To: Khaja Ahmed; [e-mail]</FONT> <BR><FONT =
size=3D2>Subject:=20
  OCSP in S/MIME and IPSEC</FONT> </P><BR>
  <P><FONT size=3D2>Khaja,</FONT> </P>
  <P><FONT size=3D2>I heartily agree.&nbsp; In fact, this was one of the =
leading=20
  "use cases" I cited</FONT> <BR><FONT size=3D2>very early on for OCSP's =

  utility.&nbsp; I don't see though that this case</FONT> <BR><FONT=20
  size=3D2>requires any amendment to OCSP.&nbsp; Could you elaborate on =
why you=20
  think this</FONT> <BR><FONT size=3D2>is so?</FONT> </P>
  <P><FONT size=3D2>And as long as we're on the subject, I've been =
off-and-on=20
  talking to folks</FONT> <BR><FONT size=3D2>about an operational =
concept I've=20
  been calling "Asymmetric OCSP."&nbsp; (first</FONT> <BR><FONT =
size=3D2>briefed=20
  publicly a couple of RSAs ago.)</FONT> </P>
  <P><FONT size=3D2>The concept applies best to the road warrior using =
IPSEC to=20
  securely reach</FONT> <BR><FONT size=3D2>back home, to a customer site =
on a=20
  trouble call, etc..&nbsp; Basically, during</FONT> <BR><FONT =
size=3D2>the IPSEC=20
  setup phase the IPSEC server or gateway first checks the RW's =
cert</FONT>=20
  <BR><FONT size=3D2>by reference to an enterprise OCSP server.&nbsp; =
There you=20
  get</FONT> <BR><FONT size=3D2>revocation/validation enforcement on the =

  client.&nbsp; The server or gateway then</FONT> <BR><FONT =
size=3D2>turns around=20
  and asks the OCSP server for status on it's (the gw's) cert,</FONT> =
<BR><FONT=20
  size=3D2>puts this into the handshake and so delivers back to the =
client</FONT>=20
  <BR><FONT size=3D2>revocation/validation assurance.</FONT> </P>
  <P><FONT size=3D2>It's in-band and clean since the client doesn't have =
to=20
  collaterally run</FONT> <BR><FONT size=3D2>LDAP etc. to fetch a =
CRL.&nbsp; Also,=20
  there's no client-side state maintenance</FONT> <BR><FONT size=3D2>re: =

  CRLs.&nbsp; The client gets realtime effects on the revocation of a=20
  gw's</FONT> <BR><FONT size=3D2>cert.&nbsp; Finally, all the heavy =
lifting is=20
  done in the back office where</FONT> <BR><FONT size=3D2>there's =
sufficient=20
  platform cycles and bandwidth to do this efficiently (vs.</FONT> =
<BR><FONT=20
  size=3D2>forcing a limited client to go fetch CRLs from wherever using =

  whatever</FONT> <BR><FONT size=3D2>protocol.)&nbsp; </FONT></P>
  <P><FONT size=3D2>Takers, anyone?</FONT> </P>
  <P><FONT size=3D2>Mike</FONT> </P><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Khaja=20
  Ahmed [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]<=
/A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, August 31, 2000 4:27 PM</FONT> =
<BR><FONT=20
  size=3D2>To: 'Karl Scheibelhofer'; Peter Sylvester; =
[e-mail];</FONT>=20
  <BR><FONT size=3D2>[e-mail]</FONT> <BR><FONT =
size=3D2>Subject: RE: RFC=20
  2560 - OCSP - Clarification</FONT> </P><BR>
  <P><FONT size=3D2>Under some circumstances or for some communities it =
may be=20
  possible for the</FONT> <BR><FONT size=3D2>sender of the signed data =
to send=20
  along with the signed data proof that at</FONT> <BR><FONT size=3D2>the =
time of=20
  signing (+/- some tolerance limit) the certificate was not</FONT> =
<BR><FONT=20
  size=3D2>revoked. In other words, the sender could get an ocsp =
response from a=20
  common</FONT> <BR><FONT size=3D2>trusted responder and include this =
with the=20
  transmission of the signed data.</FONT> <BR><FONT size=3D2>This =
approach offers=20
  the advantage that the response can be archived /</FONT> <BR><FONT=20
  size=3D2>stored along with the signature.&nbsp; At a later date when =
the=20
  archived / stored</FONT> <BR><FONT size=3D2>signed data and signature =
is=20
  retrieved it can be readily verified as having</FONT> <BR><FONT =
size=3D2>been=20
  valid at creation time (+/- tolerance limit).&nbsp; </FONT><BR><FONT =
size=3D2>Is=20
  this not an ability that we should formalize and add to =
appropriate</FONT>=20
  <BR><FONT size=3D2>protocols like OCSP? </FONT><BR><FONT =
size=3D2>Khaja=20
  </FONT><BR><FONT size=3D2>Phone: (+43) [phone]=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_004E_01C016C7.78671B60--



Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13381 for <[e-mail]>; Mon, 4 Sep 2000 11:49:17 -0700 (PDT)
From: [e-mail]
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e84ImrT20554; Mon, 4 Sep 2000 11:48:54 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e84In7L17068; Mon, 4 Sep 2000 11:49:07 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 88256950.00675C9F ; Mon, 4 Sep 2000 11:48:59 -0700
X-Lotus-FromDomain: 3COM
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 4 Sep 2000 11:48:48 -0700
Subject: Re: Comment on AttributeCertificate draft
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Stephen,

The authors of RFC 2693 went to great lengths to explain why PKCs with
Distinguished Names will not work on global scale and why multiple certificates
per user are inescapable. They specifically address the subject of
authorizations and the mapping of authorizations to key holders, a subject AC
tries to address as well. Their reasoning can be ignored but the then ACs would
suffer from caveats mentioned in the RFC above.

In my opinion, ACs should *allow* adherence to the SPKI model, being a real
global-scale model suited for the internet, not just intra-enterprise but also
inter-enterprise. In particular: local names & global identifiers (a key issue),
reduced security with AA and CA (sec. 3.1).

I do not think allowing SPKI adherence, given the simplicity of SPKI, would not
be too difficult. There is no question in my mind that it is a very powerful
model suited for the inter-net.

Regards,
Ron.





Stephen Farrell <[e-mail]> on 09/04/2000 03:08:59 AM

Please respond to [e-mail]

Sent by:  Stephen Farrell <[e-mail]>


To:   Ron Vered/HQ/3Com
cc:   [e-mail], [e-mail], [e-mail],
      [e-mail]
Subject:  Re: Comment on AttributeCertificate draft




Hi Ron,

I'd have to say that the AC work doesn't have any direct "fit"
with SPKI since its just a profile of X.509 ACs. Having said that
however, a combination of X.509 ACs and PKCs can be used to
achieve the same authorization functionality as SPKI, though
you'd still have anti-ASN.1 reasons to use SPKI if you believe
in those. So basically its another way to do the same thing,
but based on X.509 and not 5-tuples.

I'm not familiar with X9.57, so I can't comment on it.

Regards,
Stephen.

[e-mail] wrote:
>
> Stephen,
>
> How does this proposal fit (or not) with the theoretical work on SPKI (RFC
> 2693)?
> In particular, an AC does not have a public key AND a single PKC may have
> multiple ACs. Also, SPKI suggestion on the use of X9.57 to specify
authorization
> attributes in X.509v3.
>
> Regards,
> Ron.

--
____________________________________________________________
Stephen Farrell
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com






Received: from mx.spiritone.com (mx.spiritone.com [205.139.108.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13183 for <[e-mail]>; Mon, 4 Sep 2000 11:46:12 -0700 (PDT)
Received: (qmail 2816 invoked from network); 4 Sep 2000 18:47:38 -0000
Received: (ofmipd 208.130.242.164); 4 Sep 2000 18:47:16 -0000
Date: 4 Sep 2000 11:47:35 -0700
Message-Id: <[e-mail]>
From: "Carl Ellison" <[e-mail]>
To: "Carl Ellison" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Subject: Re: Comment on AttributeCertificate draft
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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

At 11:44 AM 9/4/00 -0700, Carl Ellison wrote:
>It is true that you can achieve the authorization mapping by a combination 
>of and attribute and ID.
    ^^^

drop that word



-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQA/AwUBObPuRnPxfjyW5ytxEQLzZwCgonMgpfJ5L+uy1Kk3uHrvwmp+mtUAnjWd
LY94ypM0lD5WOsUyZNF5BYTv
=X9d8
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+


Received: from mx.spiritone.com (mx.spiritone.com [205.139.108.5]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA13107 for <[e-mail]>; Mon, 4 Sep 2000 11:43:09 -0700 (PDT)
Received: (qmail 569 invoked from network); 4 Sep 2000 18:44:35 -0000
Received: (ofmipd 208.130.242.164); 4 Sep 2000 18:44:13 -0000
Date: 4 Sep 2000 11:44:27 -0700
Message-Id: <[e-mail]>
From: "Carl Ellison" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Subject: Re: Comment on AttributeCertificate draft
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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

At 11:08 AM 9/4/00 +0100, Stephen Farrell wrote:
>
>Hi Ron,
>
>I'd have to say that the AC work doesn't have any direct "fit" 
>with SPKI since its just a profile of X.509 ACs. Having said that
>however, a combination of X.509 ACs and PKCs can be used to
>achieve the same authorization functionality as SPKI, though
>you'd still have anti-ASN.1 reasons to use SPKI if you believe
>in those. So basically its another way to do the same thing,
>but based on X.509 and not 5-tuples.
>
>I'm not familiar with X9.57, so I can't comment on it.

Hi Stephen,

we should probably sit down for a few hours and go over these details.

My standard triangle diagram of certificates includes

attribute (authorization to name)
ID (name to key)
and
authorization (authorization to key)

It is true that you can achieve the authorization mapping by a combination 
of and attribute and ID.

Aside from ASN.1 vs. S-expression religion, there are some things we did in 
SPKI that X.509 is slow in dealing with.  Most especially here I see a 
lingering temptation in the X.509 community to retain the original X.500 
notion that a DN is an identifier.  In SPKI we knew up front that names were 
local, but that an attribute instrument (whether ACL or attribute 
certificate) needed a global name, so we defined a global name as:

(name <key> <name-spelling>)

where <key> is the public key (or its hash) of the CA and <name-spelling> is 
the text of the name (DN in your case).

For a little more on this topic, see http://world.std.com/~cme/html/web.html

==========

X9.57 is an ANSI standard that defines a key-style ACL.  That is, it defines 
authorization entries in a protected database -- with each entry mapping 
(authorization to key).  This is for the banking system, and the 
authorization is usually access to a particular bank account.  It has the 
advantage that it is more secure than any system using certificates but 
because it uses no certificates, it is less expensive and complex.  It has 
limitations in delegation, but for the purpose it was designed for, it is a 
good solution.


 - Carl

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQA/AwUBObPtinPxfjyW5ytxEQLqdQCg2FhjOvi2AVi4BFpCyisTkQJvS3oAoMHF
1DyXxIb9/rRPyEKvlLNEwy8v
=vTM7
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|Carl M. Ellison         [e-mail]     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+


Received: from balinese.baltimore.ie ([e-mail] [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA27940 for <[e-mail]>; Mon, 4 Sep 2000 03:05:38 -0700 (PDT)
Received: by balinese.baltimore.ie; id LAA09080; Mon, 4 Sep 2000 11:07:01 +0100 (GMT/IST)
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2) id xma009063; Mon, 4 Sep 00 11:06:53 +0100
Received: from baltimore.ie (ip219-221.ie.baltimore.com [192.168.21.219]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA31358; Mon, 4 Sep 2000 11:06:52 +0100
Message-ID: <[e-mail]>
Date: Mon, 04 Sep 2000 11:08:59 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comment on AttributeCertificate draft
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Ron,

I'd have to say that the AC work doesn't have any direct "fit" 
with SPKI since its just a profile of X.509 ACs. Having said that
however, a combination of X.509 ACs and PKCs can be used to
achieve the same authorization functionality as SPKI, though
you'd still have anti-ASN.1 reasons to use SPKI if you believe
in those. So basically its another way to do the same thing,
but based on X.509 and not 5-tuples.

I'm not familiar with X9.57, so I can't comment on it.

Regards,
Stephen.

[e-mail] wrote:
> 
> Stephen,
> 
> How does this proposal fit (or not) with the theoretical work on SPKI (RFC
> 2693)?
> In particular, an AC does not have a public key AND a single PKC may have
> multiple ACs. Also, SPKI suggestion on the use of X9.57 to specify authorization
> attributes in X.509v3.
> 
> Regards,
> Ron.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
61 Fitzwilliam Lane,                    fax: [phone]
Dublin 2.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23913 for <[e-mail]>; Sun, 3 Sep 2000 23:54:33 -0700 (PDT)
Received: from hades [129.27.152.143] by iaik.tu-graz.ac.at (SMTPD32-6.00) id A780460246; Mon, 04 Sep 2000 08:56:00 +0200
Received: from localhost [127.0.0.1] by hades (IAIK S/MIME Mapper 2.0beta1 14/January/2000); Mon, 04 Sep 2000 08:55:16 +0100
From: "Karl Scheibelhofer" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP support for historical reference to certificate suspension
Date: Mon, 4 Sep 2000 08:55:16 +0200
Message-ID: <[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 IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal

> But for discussion purposes, I've been architecting under the presumption
> that in the instance when signing time was important, the time when the
> digital signature was created would be integrated somehow into the subject
> electronic document and thus there exist a well-defined time.
>
> I believe you're implying that it may not be the case that signing time is
> integrated into a subject document, and so one is led to bracket
> the signing
> time.  Could confirm please, or otherwise clarify?  Thanks.

of course, it is desirable that the document is timestamped before it gets
signed. and to fulfill the requirement for non-repudiation, it is necessary
to timestamp the signed document afterwards. but there are cases thinkable,
where there is a longer time between these two timestamps; e.g. if you are
signing on a mobile device, that does not have permanent access to a
timestamping sever. very often, the first time stamp will be replaced by
just a time value that is added before the document gets signed. but if it
is just a value, i can insert any value i like; it is not detectable
afterwards. so you cannot proof that you signed the document not before a
specific time.
only if you are using two timestamps, you can proof later on that the
signature was created between these two timestamps. in case of a dispute, i
think this is very helpful.

regards

  Karl Scheibelhofer

--

Karl Scheibelhofer, <mailto:[e-mail]>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) [phone]



Received: from union.mobiletone.com (IDENT:[e-mail] [205.219.91.37] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA19935 for <[e-mail]>; Sun, 3 Sep 2000 21:00:48 -0700 (PDT)
Received: (qmail 1982 invoked by uid 514); 4 Sep 2000 03:04:03 -0000
Date: 4 Sep 2000 03:04:03 -0000
Message-ID: <[e-mail]>
From: "Traderfirst Webmaster" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Electronics Parts B2B Portal (Celebrating TraderFirst Official Launch with Lucky Draw Campaign)

English: http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=en
Traditional Chinese : http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=big5
Simplified Chinese : http://www.traderfirst.com/traderfirst/msgs/20000903.jsp?lang=gb


Dear Valued Customer, 
  
(New B2B Electronic Asia Portal) 
  
* We are pleased to inform you that TraderFirst.com (www.traderfirst.com) will be officially launched on September 6th, 2000. We dedicate in providing first class services and products to our customers. 
 
* Company Introduction: Traderfirst.com is a leading Internet business-to-business (B2B) exchange and application service provider (ASP) mainly for electronics parts and semiconductor industry in Asia. We are providing a Chinese and English Internet platform for customers to bridge their business worldwide efficiently. TraderFirst.com philosophy is simple: we care the CUSTOMERS, SERVICES, & QUALITY. 
 
* WANNA! HK$20,000.00 CASH Lucky Draw Program: For the first 200 "Gold Members only"
In order to celebrate the official launch, we set up a HK$20,000 cash lucky draw program* for one lucky winner, plus 10 special prizes. Please visit www.traderfirst.com now & get more business opportunities. 
 
* "Gold member" registration site: www.traderfirst.com. Please register today and don't lose the chance to win the HK$ 20,000.00 CASH! 
 
  
Thank you of your kind attention. If you have any question, please feel free to contact at 852-24050498 or e-mail to [e-mail]  
  
Yours faithfully,  
   
Marketing Department,
TraderFirst.com Ltd
(www.traderfirst.com)
 
  
N.B: * All employees of TraderFirst.com and their affiliates are not allowed to participate. This program is for worldwide customers. It is subject to change. All rights are reserved by TraderFirst.com. If you do not wish to receive any promotional materials from us, please send e-mail to [e-mail].  



Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22110 for <[e-mail]>; Sun, 3 Sep 2000 11:42:58 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <Q8W94VT5>; Sun, 3 Sep 2000 14:43:31 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Liaquat Khan'" <[e-mail]>, Denis Pinkas <[e-mail]>, Michael Myers <[e-mail]>
Cc: [e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification
Date: Sun, 3 Sep 2000 14:43:29 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C015D6.DAB2E320"

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_01C015D6.DAB2E320
Content-Type: text/plain;
	charset="iso-8859-1"

It sound to me like the debate is really about good choice of words to
describe something.  Looks like everyone (or most) know exactly what "good"
means in rfc.2560.  After all, it is explained there quite clearly.  The
question then is: Why should "good" or any other word describing a state of
anything "imply" anything?  The precise meaning should be, and in this case
is, described in the standard.  From time to time common English words may
be used to describe precise and narrow technical matter.  As long as the
precise meaning in the context is described in the spec one does not need to
fall back on English dictionaries.  I would argue that "not revoked" isn't
any clearer.  "Not revoked and may not have been issued" is getting close
but is too verbose.  Ultimately there needs to be a handle and some text
explaining what is meant by the handle.  I am not sure it is important to
worry excessively about the choice of handle.

Secondly, a case can be made, that "good" in the context is actually the
right term.  An OCSP query is, after all, not a substitute for basic path
validation.  Someone, somewhere - the relying party or a trusted agent or a
server or X is meant to have done quite a lot of work before checking the
revocation status of a certificate.  OCSP was not meant to do remote path
processing as far as I know.  The relying party is expected to have at least
done the following two things in addition to whatever application specific
checking is required:

1.) Verify the signature.
2.) Do RFC.2459 section 6.1 compliant basic path validation

After these two steps the relying party is checking to see if the
certificate has been revoked.  The certificate in question is a certificate
(chain) which the relying party is in physical possession of and has
cryptographically verified.  

What then is the value of being told at this point that the certificate is
no only not revoked but has been issued?  Unless the CA private key has been
compromised or RSA has been broken this additionally info is of no value.
If one of these two thing have happened, then whatever the riches of the
OCSP "good" semantics - they are of little value.  In this context, as far
as I can see, "good" is good.

...or have I misunderstood the whole thing and neglected to consider some
factors?

Khaja

-----Original Message-----
From: Liaquat Khan [mailto:[e-mail]]
Sent: Sunday, September 03, 2000 1:26 AM
To: Denis Pinkas; Michael Myers
Cc: [e-mail]
Subject: Re: RFC 2560 - OCSP - Clarification


I tend to agree... a certificate status of "good" is a bit misleading, not
only from the viewpoint that the certificate may never been issued in the
first place, but also because it kind of implies that the certificate is
acceptable for a particular purpose.  It might be better to have a status of
"not-revoked", which simply means that the CA has not revoked the
certificate, for what ever reason  (i.e. either it never issued the
certificate in the first place or because the certificate is still valid).
>From a legal point of view this may be better for the CA, than claiming the
certificate is good.

Regards,
Liaquat Khan



----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: Liaquat Khan <[e-mail]>; <[e-mail]>
Sent: Saturday, September 02, 2000 5:34 PM
Subject: Re: RFC 2560 - OCSP - Clarification


> Michael,
>
> > Liaquat,
> >
> > Thanks for taking a careful look at 2560 regarding CRLs.  This thread
will
> > feed productively into 2560bis.
> >
> > But I do need to point out that OCSP does not, nor was ever intended, to
> > require the use of CRLs.
>
> As you said, OSCP does not require, but does allow the use of CRLs
> as the primary information used by the OCSP server to respond.
>
>
> > In fact, here are a few references from 2560 as
> > currently written:
> >
> > Abstract
> > "This document specifies a protocol useful in determining the current
status
> > of a digital certificate without requiring CRLs."
> >             ^^^^^^^^^^^^^^^^^^^^^^
> >
> > 2.  Protocol Overview
> > "OCSP may be used to satisfy some of the operational requirements of
> > providing more timely revocation information than is possible with CRLs
. .
> > . ."
> >                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Now, that said, 2560 does recognize that CRLs are a useful input to OCSP
and
> > so we made certain to accomodate that data source in the event that
> > periodically produced CRLs were the ONLY means by which an OCSP service
> > could be offered.  We enabled the use of CRL extensions to accomodate
> > environments where this feature was useful.
> >
> > But OCSP is and was primarly intended to address immediate timeliness, a
> > feature that is inherently beyond the scope of periodically produced
CRLs.
> >
>
> The problem is that the protocol does not take advantage of this
> feature. So the notion of "immediate timeliness" does not reaaly
> make sense, since anyway there is some delay in the overall process.
> A "good" status does not guarantee in any way that the certificate
> is presently "good", but only that it has not be declared to be
> revoked at some previous *undefined* time which may be a few
> minutes,
> hours (or even days) from the current time.
>
> So let me propose a "clarification" about the meaning of the "good"
> status.
>
>  The "good" state indicates a positive response to the status
>  inquiry. At a minimum, this positive response indicates
>  that the certificate  has not be declared or requested
>  to be revoked at some point  of time prior the current time,
>  and does not necessarily mean  that the certificate was
>  ever issued by the CA or that the time  at which the
>  response was produced is within the certificate's validity
>  interval.
>
> I do know that this definition gives less than the previous one, but
> it provides a better reality of the situation: no assurance that, at
> the time of the response, the private key is not compromised or the
> association between the key value and the content of the certificate
> is still correct.
>
> > 2560bis will clarify this intent.
>
> I think it is important to maintain that the use of CRLs as the
> primary information used by the OCSP server is one of the options to
> provide the real
> time information. So be *very* careful when making the
> "clarification".
>
> Denis
>
> P.S. Since in your message from August 31, you said:
>
> " Given the current work underway regarding 2560bis, I propose to
> include in
> the 2560bis work effort an optional "ValidAt" (or some such) field
> in the
> request syntax to accomodate this requirement."
>
> I do not support your proposal and I fear you are planning to change
> RFC 2560 by adding new functionality. So, here is my question: *In
> addition* to 2560bis, when are you expecting to provide a draft for
> OSCP extensions (i.e. OCSP-X) able to cover additional functionality
> ?
>
>
> > Mike
> >
> > > -----Original Message-----
> > > From: Liaquat Khan [mailto:[e-mail]]
> > > Sent: Wednesday, August 30, 2000 9:02 AM
> > > To: [e-mail]
> > > Subject: Re: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > The problem is linked to the fact that OCSP generally uses
> > > CRLs as the base
> > > information (although of course this doesn't have to be the
> > > case). And CRLs
> > > basically contain identifiers for those certificates that
> > > have been revoked
> > > (or suspended).  Therefore, if a particular certificates
> > > serial number is
> > > not on a CRL, it maybe because it is still valid or maybe
> > > because it was
> > > never issued in the first place.
> > >
> > > Note that the OCSP standard makes a reference that extensions
> > > should be used
> > > for providing additional information.
> > >
> > > Regards,
> > > Liaquat Khan
> > > Technical Manager
> > > Global Trust Authority
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Mathew Butler <[e-mail]>
> > > To: 'Rich Salz' <[e-mail]>; Sam Schaen
> > > <[e-mail]>;
> > > <[e-mail]>
> > > Sent: Monday, August 28, 2000 9:13 PM
> > > Subject: RE: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > > I think that there's a problem with this idea.  If the
> > > responder doesn't
> > > > know about the CA, or have the ability to verify the CA's
> > > signature on the
> > > > certificate versus the CRL, the response should be
> > > "unknown" rather than
> > > > "good".
> > > >
> > > > "Good" should indicate: "The certificate was apparently
> > > issued by a CA
> > > that
> > > > the responder has current revocation information for, and
> > > the certificate
> > > > has not been revoked."
> > > >
> > > > Forgive me for not reading the draft as thoroughly as I
> > > should have; is
> > > > there any call for the responder to cryptographically check the
> > > certificate
> > > > at any point during the request?
> > > >
> > > > -Mat Butler
> > > >
> > > > -----Original Message-----
> > > > From: Rich Salz [mailto:[e-mail]]
> > > > Sent: Monday, August 28, 2000 8:08 AM
> > > > To: Sam Schaen
> > > > Cc: '[e-mail]'
> > > > Subject: Re: RFC 2560 - OCSP - Clarification
> > > >
> > > >
> > > > The text in uppercase is contradicted by the sentence that
> > > immediately
> > > > follows.  If good doesn't mean the certificate was issued,
> > > then there
> > > > need not be a CA that issued it. :)
> > > >
> > > >
> > > > > 'The "good" state indicates that THE RESPONDER HAS
> > > CURRENT REVOCATION
> > > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND
> > > the certificate
> > > > has not
> > > > > been revoked. It
> > > > > does not indicate whether the certificate was ever
> > > issued, is still
> > > valid
> > > > or
> > > > > any other assertion.
> > > >
> > >
>
>
>

------_=_NextPart_001_01C015D6.DAB2E320
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: RFC 2560 - OCSP - Clarification</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>It sound to me like the debate is really about good =
choice of words to describe something.&nbsp; Looks like everyone (or =
most) know exactly what &quot;good&quot; means in rfc.2560.&nbsp; After =
all, it is explained there quite clearly.&nbsp; The question then is: =
Why should &quot;good&quot; or any other word describing a state of =
anything &quot;imply&quot; anything?&nbsp; The precise meaning should =
be, and in this case is, described in the standard.&nbsp; From time to =
time common English words may be used to describe precise and narrow =
technical matter.&nbsp; As long as the precise meaning in the context =
is described in the spec one does not need to fall back on English =
dictionaries.&nbsp; I would argue that &quot;not revoked&quot; isn't =
any clearer.&nbsp; &quot;Not revoked and may not have been issued&quot; =
is getting close but is too verbose.&nbsp; Ultimately there needs to be =
a handle and some text explaining what is meant by the handle.&nbsp; I =
am not sure it is important to worry excessively about the choice of =
handle.</FONT></P>

<P><FONT SIZE=3D2>Secondly, a case can be made, that &quot;good&quot; =
in the context is actually the right term.&nbsp; An OCSP query is, =
after all, not a substitute for basic path validation.&nbsp; Someone, =
somewhere - the relying party or a trusted agent or a server or X is =
meant to have done quite a lot of work before checking the revocation =
status of a certificate.&nbsp; OCSP was not meant to do remote path =
processing as far as I know.&nbsp; The relying party is expected to =
have at least done the following two things in addition to whatever =
application specific checking is required:</FONT></P>

<P><FONT SIZE=3D2>1.) Verify the signature.</FONT>
<BR><FONT SIZE=3D2>2.) Do RFC.2459 section 6.1 compliant basic path =
validation</FONT>
</P>

<P><FONT SIZE=3D2>After these two steps the relying party is checking =
to see if the certificate has been revoked.&nbsp; The certificate in =
question is a certificate (chain) which the relying party is in =
physical possession of and has cryptographically verified.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>What then is the value of being told at this point =
that the certificate is no only not revoked but has been issued?&nbsp; =
Unless the CA private key has been compromised or RSA has been broken =
this additionally info is of no value.&nbsp; If one of these two thing =
have happened, then whatever the riches of the OCSP &quot;good&quot; =
semantics - they are of little value.&nbsp; In this context, as far as =
I can see, &quot;good&quot; is good.</FONT></P>

<P><FONT SIZE=3D2>...or have I misunderstood the whole thing and =
neglected to consider some factors?</FONT>
</P>

<P><FONT SIZE=3D2>Khaja</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Liaquat Khan [<A =
HREF=3D"mailto:[e-mail]">mailto:liaquat.khan@gta.m=
ulticert.org</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, September 03, 2000 1:26 AM</FONT>
<BR><FONT SIZE=3D2>To: Denis Pinkas; Michael Myers</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: RFC 2560 - OCSP - Clarification</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I tend to agree... a certificate status of =
&quot;good&quot; is a bit misleading, not</FONT>
<BR><FONT SIZE=3D2>only from the viewpoint that the certificate may =
never been issued in the</FONT>
<BR><FONT SIZE=3D2>first place, but also because it kind of implies =
that the certificate is</FONT>
<BR><FONT SIZE=3D2>acceptable for a particular purpose.&nbsp; It might =
be better to have a status of</FONT>
<BR><FONT SIZE=3D2>&quot;not-revoked&quot;, which simply means that the =
CA has not revoked the</FONT>
<BR><FONT SIZE=3D2>certificate, for what ever reason&nbsp; (i.e. either =
it never issued the</FONT>
<BR><FONT SIZE=3D2>certificate in the first place or because the =
certificate is still valid).</FONT>
<BR><FONT SIZE=3D2>From a legal point of view this may be better for =
the CA, than claiming the</FONT>
<BR><FONT SIZE=3D2>certificate is good.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Liaquat Khan</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>To: Michael Myers &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Cc: Liaquat Khan =
&lt;[e-mail]&gt;; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Saturday, September 02, 2000 5:34 PM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: RFC 2560 - OCSP - Clarification</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Michael,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Liaquat,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Thanks for taking a careful look at 2560 =
regarding CRLs.&nbsp; This thread</FONT>
<BR><FONT SIZE=3D2>will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; feed productively into 2560bis.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; But I do need to point out that OCSP does =
not, nor was ever intended, to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; require the use of CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; As you said, OSCP does not require, but does =
allow the use of CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; as the primary information used by the OCSP =
server to respond.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In fact, here are a few references from =
2560 as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; currently written:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Abstract</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;This document specifies a protocol =
useful in determining the current</FONT>
<BR><FONT SIZE=3D2>status</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of a digital certificate without requiring =
CRLs.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; ^^^^^^^^^^^^^^^^^^^^^^</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2.&nbsp; Protocol Overview</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;OCSP may be used to satisfy some of =
the operational requirements of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; providing more timely revocation =
information than is possible with CRLs</FONT>
<BR><FONT SIZE=3D2>. .</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; . .&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
^^^^^^^^^^^^^^^^^^^^^^^^^^</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Now, that said, 2560 does recognize that =
CRLs are a useful input to OCSP</FONT>
<BR><FONT SIZE=3D2>and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; so we made certain to accomodate that data =
source in the event that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; periodically produced CRLs were the ONLY =
means by which an OCSP service</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; could be offered.&nbsp; We enabled the use =
of CRL extensions to accomodate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; environments where this feature was =
useful.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; But OCSP is and was primarly intended to =
address immediate timeliness, a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; feature that is inherently beyond the =
scope of periodically produced</FONT>
<BR><FONT SIZE=3D2>CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The problem is that the protocol does not take =
advantage of this</FONT>
<BR><FONT SIZE=3D2>&gt; feature. So the notion of &quot;immediate =
timeliness&quot; does not reaaly</FONT>
<BR><FONT SIZE=3D2>&gt; make sense, since anyway there is some delay in =
the overall process.</FONT>
<BR><FONT SIZE=3D2>&gt; A &quot;good&quot; status does not guarantee in =
any way that the certificate</FONT>
<BR><FONT SIZE=3D2>&gt; is presently &quot;good&quot;, but only that it =
has not be declared to be</FONT>
<BR><FONT SIZE=3D2>&gt; revoked at some previous *undefined* time which =
may be a few</FONT>
<BR><FONT SIZE=3D2>&gt; minutes,</FONT>
<BR><FONT SIZE=3D2>&gt; hours (or even days) from the current =
time.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; So let me propose a &quot;clarification&quot; =
about the meaning of the &quot;good&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; status.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; The &quot;good&quot; state indicates a =
positive response to the status</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; inquiry. At a minimum, this positive =
response indicates</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; that the certificate&nbsp; has not be =
declared or requested</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; to be revoked at some point&nbsp; of time =
prior the current time,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; and does not necessarily mean&nbsp; that =
the certificate was</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; ever issued by the CA or that the =
time&nbsp; at which the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; response was produced is within the =
certificate's validity</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; interval.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I do know that this definition gives less than =
the previous one, but</FONT>
<BR><FONT SIZE=3D2>&gt; it provides a better reality of the situation: =
no assurance that, at</FONT>
<BR><FONT SIZE=3D2>&gt; the time of the response, the private key is =
not compromised or the</FONT>
<BR><FONT SIZE=3D2>&gt; association between the key value and the =
content of the certificate</FONT>
<BR><FONT SIZE=3D2>&gt; is still correct.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2560bis will clarify this intent.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I think it is important to maintain that the =
use of CRLs as the</FONT>
<BR><FONT SIZE=3D2>&gt; primary information used by the OCSP server is =
one of the options to</FONT>
<BR><FONT SIZE=3D2>&gt; provide the real</FONT>
<BR><FONT SIZE=3D2>&gt; time information. So be *very* careful when =
making the</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;clarification&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; P.S. Since in your message from August 31, you =
said:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &quot; Given the current work underway =
regarding 2560bis, I propose to</FONT>
<BR><FONT SIZE=3D2>&gt; include in</FONT>
<BR><FONT SIZE=3D2>&gt; the 2560bis work effort an optional =
&quot;ValidAt&quot; (or some such) field</FONT>
<BR><FONT SIZE=3D2>&gt; in the</FONT>
<BR><FONT SIZE=3D2>&gt; request syntax to accomodate this =
requirement.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I do not support your proposal and I fear you =
are planning to change</FONT>
<BR><FONT SIZE=3D2>&gt; RFC 2560 by adding new functionality. So, here =
is my question: *In</FONT>
<BR><FONT SIZE=3D2>&gt; addition* to 2560bis, when are you expecting to =
provide a draft for</FONT>
<BR><FONT SIZE=3D2>&gt; OSCP extensions (i.e. OCSP-X) able to cover =
additional functionality</FONT>
<BR><FONT SIZE=3D2>&gt; ?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mike</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Liaquat Khan [<A =
HREF=3D"mailto:[e-mail]">mailto:liaquat.khan@gta.m=
ulticert.org</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Wednesday, August 30, 2000 9:02 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Re: RFC 2560 - OCSP - =
Clarification</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The problem is linked to the fact =
that OCSP generally uses</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; CRLs as the base</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; information (although of course this =
doesn't have to be the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; case). And CRLs</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; basically contain identifiers for =
those certificates that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; have been revoked</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (or suspended).&nbsp; Therefore, if a =
particular certificates</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; serial number is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; not on a CRL, it maybe because it is =
still valid or maybe</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; because it was</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; never issued in the first =
place.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Note that the OCSP standard makes a =
reference that extensions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; should be used</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; for providing additional =
information.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Liaquat Khan</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Technical Manager</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Global Trust Authority</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Mathew Butler =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: 'Rich Salz' =
&lt;[e-mail]&gt;; Sam Schaen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &lt;[e-mail]&gt;;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Monday, August 28, 2000 9:13 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: RFC 2560 - OCSP - =
Clarification</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I think that there's a problem =
with this idea.&nbsp; If the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; responder doesn't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; know about the CA, or have the =
ability to verify the CA's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; signature on the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; certificate versus the CRL, the =
response should be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot;unknown&quot; rather =
than</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &quot;good&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &quot;Good&quot; should =
indicate: &quot;The certificate was apparently</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; issued by a CA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; the responder has current =
revocation information for, and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the certificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; has not been =
revoked.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Forgive me for not reading the =
draft as thoroughly as I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; should have; is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; there any call for the responder =
to cryptographically check the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; certificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; at any point during the =
request?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -Mat Butler</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; From: Rich Salz [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sent: Monday, August 28, 2000 =
8:08 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; To: Sam Schaen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cc: '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Subject: Re: RFC 2560 - OCSP - =
Clarification</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; The text in uppercase is =
contradicted by the sentence that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; immediately</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; follows.&nbsp; If good doesn't =
mean the certificate was issued,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; then there</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; need not be a CA that issued it. =
:)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; 'The &quot;good&quot; state =
indicates that THE RESPONDER HAS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; CURRENT REVOCATION</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; INFORMATION FROM THE CA =
THAT ISSUED THE CERTIFICATE AND</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the certificate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; has not</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; been revoked. It</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; does not indicate whether =
the certificate was ever</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; issued, is still</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; valid</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; any other assertion.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C015D6.DAB2E320--


Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA20286 for <[e-mail]>; Sun, 3 Sep 2000 01:22:25 -0700 (PDT)
Received: from [62.6.101.30] (helo=vaio) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 13VV2t-00068A-00; Sun, 03 Sep 2000 09:22:32 +0100
Message-ID: <000f01c01580$94c04680$851efea9@vaio>
Reply-To: "Liaquat Khan" <[e-mail]>
From: "Liaquat Khan" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: RFC 2560 - OCSP - Clarification
Date: Sun, 3 Sep 2000 09:25:54 +0100
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.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

I tend to agree... a certificate status of "good" is a bit misleading, not
only from the viewpoint that the certificate may never been issued in the
first place, but also because it kind of implies that the certificate is
acceptable for a particular purpose.  It might be better to have a status of
"not-revoked", which simply means that the CA has not revoked the
certificate, for what ever reason  (i.e. either it never issued the
certificate in the first place or because the certificate is still valid).
>From a legal point of view this may be better for the CA, than claiming the
certificate is good.

Regards,
Liaquat Khan



----- Original Message -----
From: Denis Pinkas <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: Liaquat Khan <[e-mail]>; <[e-mail]>
Sent: Saturday, September 02, 2000 5:34 PM
Subject: Re: RFC 2560 - OCSP - Clarification


> Michael,
>
> > Liaquat,
> >
> > Thanks for taking a careful look at 2560 regarding CRLs.  This thread
will
> > feed productively into 2560bis.
> >
> > But I do need to point out that OCSP does not, nor was ever intended, to
> > require the use of CRLs.
>
> As you said, OSCP does not require, but does allow the use of CRLs
> as the primary information used by the OCSP server to respond.
>
>
> > In fact, here are a few references from 2560 as
> > currently written:
> >
> > Abstract
> > "This document specifies a protocol useful in determining the current
status
> > of a digital certificate without requiring CRLs."
> >             ^^^^^^^^^^^^^^^^^^^^^^
> >
> > 2.  Protocol Overview
> > "OCSP may be used to satisfy some of the operational requirements of
> > providing more timely revocation information than is possible with CRLs
. .
> > . ."
> >                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Now, that said, 2560 does recognize that CRLs are a useful input to OCSP
and
> > so we made certain to accomodate that data source in the event that
> > periodically produced CRLs were the ONLY means by which an OCSP service
> > could be offered.  We enabled the use of CRL extensions to accomodate
> > environments where this feature was useful.
> >
> > But OCSP is and was primarly intended to address immediate timeliness, a
> > feature that is inherently beyond the scope of periodically produced
CRLs.
> >
>
> The problem is that the protocol does not take advantage of this
> feature. So the notion of "immediate timeliness" does not reaaly
> make sense, since anyway there is some delay in the overall process.
> A "good" status does not guarantee in any way that the certificate
> is presently "good", but only that it has not be declared to be
> revoked at some previous *undefined* time which may be a few
> minutes,
> hours (or even days) from the current time.
>
> So let me propose a "clarification" about the meaning of the "good"
> status.
>
>  The "good" state indicates a positive response to the status
>  inquiry. At a minimum, this positive response indicates
>  that the certificate  has not be declared or requested
>  to be revoked at some point  of time prior the current time,
>  and does not necessarily mean  that the certificate was
>  ever issued by the CA or that the time  at which the
>  response was produced is within the certificate's validity
>  interval.
>
> I do know that this definition gives less than the previous one, but
> it provides a better reality of the situation: no assurance that, at
> the time of the response, the private key is not compromised or the
> association between the key value and the content of the certificate
> is still correct.
>
> > 2560bis will clarify this intent.
>
> I think it is important to maintain that the use of CRLs as the
> primary information used by the OCSP server is one of the options to
> provide the real
> time information. So be *very* careful when making the
> "clarification".
>
> Denis
>
> P.S. Since in your message from August 31, you said:
>
> " Given the current work underway regarding 2560bis, I propose to
> include in
> the 2560bis work effort an optional "ValidAt" (or some such) field
> in the
> request syntax to accomodate this requirement."
>
> I do not support your proposal and I fear you are planning to change
> RFC 2560 by adding new functionality. So, here is my question: *In
> addition* to 2560bis, when are you expecting to provide a draft for
> OSCP extensions (i.e. OCSP-X) able to cover additional functionality
> ?
>
>
> > Mike
> >
> > > -----Original Message-----
> > > From: Liaquat Khan [mailto:[e-mail]]
> > > Sent: Wednesday, August 30, 2000 9:02 AM
> > > To: [e-mail]
> > > Subject: Re: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > The problem is linked to the fact that OCSP generally uses
> > > CRLs as the base
> > > information (although of course this doesn't have to be the
> > > case). And CRLs
> > > basically contain identifiers for those certificates that
> > > have been revoked
> > > (or suspended).  Therefore, if a particular certificates
> > > serial number is
> > > not on a CRL, it maybe because it is still valid or maybe
> > > because it was
> > > never issued in the first place.
> > >
> > > Note that the OCSP standard makes a reference that extensions
> > > should be used
> > > for providing additional information.
> > >
> > > Regards,
> > > Liaquat Khan
> > > Technical Manager
> > > Global Trust Authority
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Mathew Butler <[e-mail]>
> > > To: 'Rich Salz' <[e-mail]>; Sam Schaen
> > > <[e-mail]>;
> > > <[e-mail]>
> > > Sent: Monday, August 28, 2000 9:13 PM
> > > Subject: RE: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > > I think that there's a problem with this idea.  If the
> > > responder doesn't
> > > > know about the CA, or have the ability to verify the CA's
> > > signature on the
> > > > certificate versus the CRL, the response should be
> > > "unknown" rather than
> > > > "good".
> > > >
> > > > "Good" should indicate: "The certificate was apparently
> > > issued by a CA
> > > that
> > > > the responder has current revocation information for, and
> > > the certificate
> > > > has not been revoked."
> > > >
> > > > Forgive me for not reading the draft as thoroughly as I
> > > should have; is
> > > > there any call for the responder to cryptographically check the
> > > certificate
> > > > at any point during the request?
> > > >
> > > > -Mat Butler
> > > >
> > > > -----Original Message-----
> > > > From: Rich Salz [mailto:[e-mail]]
> > > > Sent: Monday, August 28, 2000 8:08 AM
> > > > To: Sam Schaen
> > > > Cc: '[e-mail]'
> > > > Subject: Re: RFC 2560 - OCSP - Clarification
> > > >
> > > >
> > > > The text in uppercase is contradicted by the sentence that
> > > immediately
> > > > follows.  If good doesn't mean the certificate was issued,
> > > then there
> > > > need not be a CA that issued it. :)
> > > >
> > > >
> > > > > 'The "good" state indicates that THE RESPONDER HAS
> > > CURRENT REVOCATION
> > > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND
> > > the certificate
> > > > has not
> > > > > been revoked. It
> > > > > does not indicate whether the certificate was ever
> > > issued, is still
> > > valid
> > > > or
> > > > > any other assertion.
> > > >
> > >
>
>
>



Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA10940 for <[e-mail]>; Sat, 2 Sep 2000 22:31:52 -0700 (PDT)
From: [e-mail]
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e835VMT17947; Sat, 2 Sep 2000 22:31:23 -0700 (PDT)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id e835VTL22594; Sat, 2 Sep 2000 22:31:33 -0700 (PDT)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 8825694F.001E52D5 ; Sat, 2 Sep 2000 22:31:12 -0700
X-Lotus-FromDomain: 3COM
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Message-ID: <[e-mail]>
Date: Sat, 2 Sep 2000 22:31:03 -0700
Subject: Comment on AttributeCertificate draft
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Stephen,

How does this proposal fit (or not) with the theoretical work on SPKI (RFC
2693)?
In particular, an AC does not have a public key AND a single PKC may have
multiple ACs. Also, SPKI suggestion on the use of X9.57 to specify authorization
attributes in X.509v3.

Regards,
Ron.




Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05400 for <[e-mail]>; Sat, 2 Sep 2000 11:52:36 -0700 (PDT)
Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA05462 for <[e-mail]>; Sat, 2 Sep 2000 19:53:43 +0100 (BST)
Received: from jap.ecs.soton.ac.uk (pri19.dialup.ecs.soton.ac.uk [152.78.68.244]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id TAA11697 for <[e-mail]>; Sat, 2 Sep 2000 19:53:40 +0100 (BST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sat, 02 Sep 2000 17:37:43 +0100
To: [e-mail]
From: J Adrian Pickering <[e-mail]>
Subject: TSP Draft - hash enforcement &c
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The following refers to draft-ietf-pkix-time-stamp-09.txt, dated June 2000, 
and is in response to the Final Call posted on 28 August.


My motivation for the use of TSP is for IPR protection support for the 
academic community at large (an extention to the original motivations of 
Haber and Stornetta in their 1991 paper). I recognise that this is not the 
core motivation for the PKIX TSP endeavours, but I am concerned that the 
emerging standard is as generally applicable to Internet users as possible 
(as the Introduction suggests).

Apologies to some who have already heard some of my views directly on this. 
Uniquely, the Draft does not invite comments to this forum in its Abstract 
- the Final Call now does!

1. I rather take the view that a TSA has no business knowing the meaning of 
what it stamps just as it has no business knowing who it is doing its 
stamping for - it must be a truly disinterested automaton.

Thus, my main concern is the implied and mandatory use of a hash in the 
message imprint. This clearly stems from the PKIX motivation. From the 
point of view of the TSA, this is unenforcible. A client can put anything 
they like in this field provided (at the moment) it has the right length. 
Therefore, I would suggest that if a server cannot verify something it 
should not be stipulated as REQUIRED. This affects paras 6, 7, 8 of 2.1 and 
also 'messageImpring field SHALL...' in 2.4.1 - SHOULD could be used.

My ideal would be that the TSA be given a octet string to stamp and that 
the Draft make very strong recommendations on how this should be used by 
the client - but not to MUST or REQUIRE it. Good candidates for the string 
are the imprint, containing a hash, and the nonce. Further, this approach 
would dilute the security problem highlighted in Section 4 para 5.

However, at this late stage, a 'quick fix' would be to allow clients to put 
something of meaning to *them* in the imprint field (e.g. RIPEMD256 hash) 
and that the algorithm identifier allow this. When the server does its 
check then, provided the OID specifies 'algorithm not known', then the 
length will always conform. This will require adjustments to the algorithm 
OIDs. As far as I can tell this will not undermine PKIX intentions.

As far as I can tell, the AlgorithmIdentifier is actually that of the full 
signing algorithm and *not* that of the hash algorithm(s) alone. I would 
recommend that there be a separately defined hashAlgorithm OID. 
Cryptographers have devised many hash algorithms and variants and there 
should be room for their use, even if this just means using the 'algorithm 
not known' opt-out suggested above.

2. If the TSA policy means a log is kept then a client may wish to 
explicitly indicate whether this request be recorded or not. There are 
other ways of communicating this, but a good way might be to have 'logReq 
BOOLEAN DEFAULT FALSE' in TimeStampReq. This may be something left to 
extensions, though.

3. I presume there is no limit to the length of the nonce, though 64 bits 
is given as an example. Bearing in mind what clients might do in the light 
of my comments in 1, they may wish to use very large nonce's. This may 
affect the practicality of logging.

4. (drafting) Page 8, para starting 'gentime is...'. I think the middle 
sentence should read: 'Such syntax, .... to represent time *within* one 
second, may be used here' (omit 'to').

5. Bearing in mind Christian Vogel's experiences, and the format of other 
Drafts, some examples in the appendix would be very helpful.

6. I have made the authors aware of some IPR matters in addition to those 
in Section 5.


Adrian Pickering/
Lecturer, Electronics and Computer Science,
University of Southampton
Southampton, UK



Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03638 for <[e-mail]>; Sat, 2 Sep 2000 10:57:17 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id UAA37566; Sat, 2 Sep 2000 20:03:05 +0200
Received: from bull.net (fradint45.bull.fr [129.181.85.45]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id TAA37650; Sat, 2 Sep 2000 19:57:47 +0200
Message-ID: <[e-mail]>
Date: Sat, 02 Sep 2000 18:34:37 +0200
From: Denis Pinkas <[e-mail]>
X-Mailer: Mozilla 4.5 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: Liaquat Khan <[e-mail]>, [e-mail]
Subject: Re: RFC 2560 - OCSP - Clarification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael,

> Liaquat,
>
> Thanks for taking a careful look at 2560 regarding CRLs.  This thread will
> feed productively into 2560bis.
>
> But I do need to point out that OCSP does not, nor was ever intended, to
> require the use of CRLs.

As you said, OSCP does not require, but does allow the use of CRLs
as the primary information used by the OCSP server to respond.


> In fact, here are a few references from 2560 as
> currently written:
>
> Abstract
> "This document specifies a protocol useful in determining the current status
> of a digital certificate without requiring CRLs."
>             ^^^^^^^^^^^^^^^^^^^^^^
>
> 2.  Protocol Overview
> "OCSP may be used to satisfy some of the operational requirements of
> providing more timely revocation information than is possible with CRLs  . .
> . ."
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Now, that said, 2560 does recognize that CRLs are a useful input to OCSP and
> so we made certain to accomodate that data source in the event that
> periodically produced CRLs were the ONLY means by which an OCSP service
> could be offered.  We enabled the use of CRL extensions to accomodate
> environments where this feature was useful.
>
> But OCSP is and was primarly intended to address immediate timeliness, a
> feature that is inherently beyond the scope of periodically produced CRLs.
>

The problem is that the protocol does not take advantage of this
feature. So the notion of "immediate timeliness" does not reaaly
make sense, since anyway there is some delay in the overall process.
A "good" status does not guarantee in any way that the certificate
is presently "good", but only that it has not be declared to be
revoked at some previous *undefined* time which may be a few
minutes,
hours (or even days) from the current time.

So let me propose a "clarification" about the meaning of the "good"
status.

 The "good" state indicates a positive response to the status
 inquiry. At a minimum, this positive response indicates 
 that the certificate  has not be declared or requested 
 to be revoked at some point  of time prior the current time, 
 and does not necessarily mean  that the certificate was 
 ever issued by the CA or that the time  at which the 
 response was produced is within the certificate's validity
 interval.

I do know that this definition gives less than the previous one, but
it provides a better reality of the situation: no assurance that, at
the time of the response, the private key is not compromised or the
association between the key value and the content of the certificate
is still correct.

> 2560bis will clarify this intent.

I think it is important to maintain that the use of CRLs as the
primary information used by the OCSP server is one of the options to
provide the real
time information. So be *very* careful when making the
"clarification".

Denis

P.S. Since in your message from August 31, you said:

" Given the current work underway regarding 2560bis, I propose to
include in
the 2560bis work effort an optional "ValidAt" (or some such) field
in the
request syntax to accomodate this requirement."

I do not support your proposal and I fear you are planning to change
RFC 2560 by adding new functionality. So, here is my question: *In
addition* to 2560bis, when are you expecting to provide a draft for
OSCP extensions (i.e. OCSP-X) able to cover additional functionality
? 


> Mike
>
> > -----Original Message-----
> > From: Liaquat Khan [mailto:[e-mail]]
> > Sent: Wednesday, August 30, 2000 9:02 AM
> > To: [e-mail]
> > Subject: Re: RFC 2560 - OCSP - Clarification
> >
> >
> > The problem is linked to the fact that OCSP generally uses
> > CRLs as the base
> > information (although of course this doesn't have to be the
> > case). And CRLs
> > basically contain identifiers for those certificates that
> > have been revoked
> > (or suspended).  Therefore, if a particular certificates
> > serial number is
> > not on a CRL, it maybe because it is still valid or maybe
> > because it was
> > never issued in the first place.
> >
> > Note that the OCSP standard makes a reference that extensions
> > should be used
> > for providing additional information.
> >
> > Regards,
> > Liaquat Khan
> > Technical Manager
> > Global Trust Authority
> >
> >
> >
> > ----- Original Message -----
> > From: Mathew Butler <[e-mail]>
> > To: 'Rich Salz' <[e-mail]>; Sam Schaen
> > <[e-mail]>;
> > <[e-mail]>
> > Sent: Monday, August 28, 2000 9:13 PM
> > Subject: RE: RFC 2560 - OCSP - Clarification
> >
> >
> > > I think that there's a problem with this idea.  If the
> > responder doesn't
> > > know about the CA, or have the ability to verify the CA's
> > signature on the
> > > certificate versus the CRL, the response should be
> > "unknown" rather than
> > > "good".
> > >
> > > "Good" should indicate: "The certificate was apparently
> > issued by a CA
> > that
> > > the responder has current revocation information for, and
> > the certificate
> > > has not been revoked."
> > >
> > > Forgive me for not reading the draft as thoroughly as I
> > should have; is
> > > there any call for the responder to cryptographically check the
> > certificate
> > > at any point during the request?
> > >
> > > -Mat Butler
> > >
> > > -----Original Message-----
> > > From: Rich Salz [mailto:[e-mail]]
> > > Sent: Monday, August 28, 2000 8:08 AM
> > > To: Sam Schaen
> > > Cc: '[e-mail]'
> > > Subject: Re: RFC 2560 - OCSP - Clarification
> > >
> > >
> > > The text in uppercase is contradicted by the sentence that
> > immediately
> > > follows.  If good doesn't mean the certificate was issued,
> > then there
> > > need not be a CA that issued it. :)
> > >
> > >
> > > > 'The "good" state indicates that THE RESPONDER HAS
> > CURRENT REVOCATION
> > > > INFORMATION FROM THE CA THAT ISSUED THE CERTIFICATE AND
> > the certificate
> > > has not
> > > > been revoked. It
> > > > does not indicate whether the certificate was ever
> > issued, is still
> > valid
> > > or
> > > > any other assertion.
> > >
> >




Received: from mail01-ewr.pilot.net (mail-ewr-1.pilot.net [206.98.230.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02390 for <[e-mail]>; Sat, 2 Sep 2000 10:26:52 -0700 (PDT)
From: [e-mail]
Received: from mailgw.firstdata.com ([204.48.27.156]) by mail01-ewr.pilot.net with ESMTP id NAA17128; Sat, 2 Sep 2000 13:27:58 -0400 (EDT)
Received: from lnsunr02.firstdata.com (localhost [127.0.0.1]) by mailgw.firstdata.com with SMTP id NAA08157; Sat, 2 Sep 2000 13:27:56 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 8525694E.005F65C2 ; Sat, 2 Sep 2000 13:21:59 -0400
X-Lotus-FromDomain: FDC
To: "David P. Kemp" <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Sat, 2 Sep 2000 11:24:05 -0700
Subject: Re: Client-side revocation checking capability
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

some general comments and three example/scenerios


I have not been commenting at all about how you might want the world of
certificates to behave.

I've only been making observations and assertions about the trivial case that
accounts for 99.9999999999999999999% of the current real world situations where
a client compares some information against something in a server certificate
(namely an SSL session involving a domain name in a server certificate)

While there may be problems with client browsers checking for domain name in a
server certificate for SSL session setup .... then there are problems.

If server certificates can be done some other way, then server certificates can
be done some other way. It doesn't negate the comments, observations and
assertions about the way the specific trivial case operates, namely the trivial
case involving 99.99999999999% of the current activity where clients do
something with a server certificates.

The observation is that for the trivial case outlined ... namely the one in the
real world today which accounts for 99.9999999999% of where a client is doing
something with server certificates (namely SSL and domain names) .... that
adding public key for domain name authentication can make that current use of
server certificates for the specific case outlined (involving 99.999999999999%
of today's activity involving server certificates) redundant and superfulous.

There could be all sorts of non-trivial cases for certificates to which that
observation doesn't apply. It was specifically made as an observation for that
specific case. These other non-trivial cases ..... which possibly accounts in
aggregate for possibly <0.0000000000001% current day server certificate
activity.

I believe that public/private keys are about authentication (at least in the
digital signature case, things like FIPS186). The SSL use of server certificates
(the trivial case that currently accounts for 99.999999999999% of current real
world activity involving clients doing something with server certificates).

DNS is both about availability as well as trust, not only is the information
readily available, but can the information also be trusted. One way of improving
the trust in DNS information is the shortcut that SSL protocol took with SSL
server certificates. Another way in improving the trust in the DNS information
is by adding public keys (and digital signatures) to DNS as part of an
authentication feature.

The issue isn't that the domain name to IP-address operation isn't necessary.
The observation is that when registering a domain name there is already quite a
bit of information that is registered (some people may have forgotten but there
are things like name/address/phone# for technical contact, administrative
contact, billing contact ... don't forget they need to bill somebody for the
registration). The further observation is that there are currently integrity
problems with the current domain name infrastructure and trust is a big issue
here. Adding public keys to the current registration process is actually quite a
small incremental increase (at least for ECC keys) in the amount of data. The
percentage increase in the process for registering public keys isn't large.
Given all the issues about trademarks with respect to domain names .... the
administrative load is increasing totally independant of whether public keys are
being registerred. Furthermore, because of the issues like domain name
hijacking, administrative load is also increasing for better authenticating that
only the domain name owner is allowed to make changes.

The registration and use of public keys for domain name infrastructure
authentication can actually reduce the increases in administrative load.

The domain name infrastructure is very much about authentication and trust ...
not just about mapping a domain name to an ip-address. Some people may only have
limited experience with a small subset of the domain name instructure ... namely
the resolved operation that returns an ip-address for a given domain or host
name. However there are huge issues involving quite a bit of administrative
workload involving who owns domain names and who is allowed to operate on
information associated with domain names.  No realizing that is a very myopic &
narrow view of how the current internet and web environment actually functions
on a day to day basis. The domain name infrastructure very much has to know that
the "domain name" owner is the entity that is allowed to change, update, &/or
delete information associated with a domain name. Nominally such "knowing"
involves some sort of authentication function. Registering passwords &/or PINs
is one way for providing for authentication. I think that many people would
agree that registering public keys and using digital signatures can be a much
better authentication process (than passwords or PINs).

Now, there might be an issue of adding a public key to all current standard DNS
responses (which might just involve a single IP-address). Standard DNS today
allows for queries that return information in additon to host ip-address. I
contend that modifying existing SSL protocol to do a DNS query for both an
IP-address and a public key .... would represent an overall reduction in SSL
protocol web bandwidth used, server processing and client processing (aka server
doesn't transmit one or more certificates, client doesn't validate one or more
certificates in order to decide if it can use the server's public key).

One of the assertion is that while the SSL server certificates were to address a
trust deficiency in the DNS infrastructure ..... those same SSL server
certificates are dependant on trusting the DNS infrastructure as the final
authority on who owns a domain name.; That, in fact (because of issues like
domain name hijacking) that even SSL server certificates would benefit from
improving the trust in the DNS infrastructure. One way of improving trust in the
DNS infrastructure is to add authentication (via public keys) to various DNS
business processes. The assertion is that if public keys are added to that
infrastructure ... then that makes public keys & domain names in SSL server
certificates redundant and superfuloous. Furthermore, if it is no longer
necessary to have SSL server certificates for public keys and domain names, then
the SSL server certificates and also redundant and superfulous.

I've still not commented about any of the non-trivial cases of server
certificates that possibly represent <0.0000000000001% of the total current
activity where a client is checking some information in a server certificate.
I've tried to restrict myself purely to the trivial case which represents
99.999999999999% of all current activity where a client is checking some
information in a server certificate.

I've tried to not comment anything about general application security or PKI or
whatever. I've tried to restrict myself purely to the trivial case which
represents 99.99999999999% of all current activity where a client is check some
information in a server certificate.

For that particular trivial case, I've asserted that adding public keys to DNS
for authentication (within FIPS186), then the trust in the DNS information can
be improved (and make it much more difficult to do things like hijack a domain
name).  Furthermore the server certificates for the trivial case involving
99.9999999999% of all current activity where a client is checking some
information (i.e. domain name in an ssl certificate) are also at risk if domain
name is hijacked (i.e. I can hijack a domain name and then get an SSL
certificate for that domain name).  Therefor these SSL certificate
infrastructures also need the trust in the DNS infrastructure improved. My
observation that addressing the DNS infrastructure trust issue with public keys
and authentication ... in order to remove the risk to the SSL certificate
infrastructure also can make the SSL certificate infrastructure redundant and
superfulous.

Again, I'm not making any general observations about PKIs or PKIXs. I'm not
making any observations about the current non-trivial cases involving server
certificates that account for <0.00000000000001% of the current situations where
clients are currently checking some information in a server certificate. I'm
only making the observations about the trivial case which accounts for
99.9999999999999999% of the current situations wehre clients are currently
checking some information in a server certificate.

I'm not making any suggestions about combining DNS and PKI. I'm making
suggestion that public keys can be added to domain name registration for
authentication purposes (the person that registers the domain name and the
ip-address(es) can operate on the entry). The observation is that the
registration of a public key when the domain name is registered can improve the
trust in the DNS infrastructure by authentication operations. Furthermore, DNS
can provide (in real time) all information registered for domain name entry ...
to whatever decree of trust that DNS information is trusted. If the registered
information includes a public key ... then that public key can be provided to
clients at the same time it provides any other registered information (like
IP-address mapping for a domain name).

To the degree that the domain name can be trusted .... the public key can be
trusted to the same degree.

!!!!!!!!!  To re-iterate, the following discussion applies only to the trivial
case involving 99.9999999999999999% of the current situations where a client is
checking some information in a server certificate  (namely the SSL protocol
involving the domain name SSL server certificate).

!!!!!!!!!   The following discussion does not (necessarily) apply to any
non-trivial cases involving <0.00000000000001% of the current situations where a
client is checking some information in a server certificate (including any
non-SSL server certificate for merchant/company names).

=================
scenerio/example 1

So specifically for the SSL server certificate case, if a public key is needed
for authenticating a server at a specific domain name:

A CA can get a request to issue a domain name SSL server certificate

A CA can contact the domain name registration authority as to the validity of
the domain name ownership

The degree that a domain name SSL server certificate can be trusted is to the
degree that the domain name registration authority can be trusted

Assuming that the domain name registration authority can fix many of its  trust
issues with authentication, digital signatures & public keys

Then the assertion is that the trust in the domain name  SSL server certificate
can be no better than the trust in the domain name registration authority public
keys

If the trust in the domain name SSL server certificate can be no better than the
trust in the domain name registration authority public keys, clients can use
"real-time" domain name registration authority public keys in lieu of domain
name SSL server certificate public keys

If 1) domain name SSL server certificate public keys are at the same trust level
as the domain name registration authority public keys and 2) the domain name
registration public keys are available and updated in real time, while 3) the
domain name SSL server certificates are manufactored at some period in the past
and can be stale or incorrect, then I contend that the domain name registration
public keys actually are actually more trusted because of the real-time
availability and update.

Showing that the domain name registration public keys are more trusted than the
domain name SSL server certificates and the domain name SSL server certificate
public keys also shows that the domain name SSL server certificate public keys
are redundant and superfulous. If the domain name SSL server certificate public
keys are redundant and superfulous then the domain name SSL server certificates
are redudant and superfulous (for the specific trivial case under discussion
which accounts for 99.999999999999% of current real world cases where client is
checking some information in a server certificate).

=================
scenerio/example #2

so now lets look at adding a CA PKI to the domain name  infrastructure to
authenticating domain name owners for domain name transactions. this is going to
be similar to relying-party-only PKI used by various banks (for liability and
privacy reasons.

1) domain name infrastructure sets up a CA PKI that registers domain name owner
public keys as part of domain name registration.

2) the CA PKI is setup to manufactor an sign domain name infrastructure relying
party certificate, basically the name is the domain name bound to the domain
name owner's public key and whatever other domain name related information that
the infrastructure wishes to put in the certificate (possibly ip-address).

3) The CA PKI stores the original of the certificate in the associated domain
name entry in compressed form (i.e. un-encoded, non-unique information removed,
etc)

4) The CA PKI returns a copy of the certificate to the domain name owner.

5) The domain name owner a) generates domain name owner transactions, b) signs
the transactions, c) sends the transaction and signature with a copy of the
certificate appended to the domain name infrastructure

6) For efficiency sakes, the appended certificate is compressed, all fields
known to already be in the possession of the relying party are removed. Since
the relying party already possesses the original manufactored certificate (and
the domain name owner only has a copy of that same certificate), the appended
certificate is compressed to zero bytes.

7) The CA PKI knowing that the domain name owner will alwas compress the
certificate to zero bytes actually sends the domain name owner a pre-compressed
certificate of zero bytes (saving the domain name owner the overhead of having
to do this on every transaction).

8) All domain name transactions are authenticated using standard CA PKI digital
processes and with valid compressed zero-byte certificates appended to every
transaction.

for more discussion on this technique of valid compressed  zero-byte
certificates see:

http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

==================
example/scenerio #3

examining the domain name infrastructure it appears that it has alwas been a
certification authority for binding of information since its inception.

The primary differences

1) OCP ... it has alwas supported an online certificate protocol (as opposed to
an online certificate status protocol) with the ability to return the
certificate of bound information in real time (some modulo regarding the trust
level of these "certificates"). these weren't public key infrastrucutre  or
public key certificates and they were presumed to have extremely short
lifetimes. The protocol did support requesting a variety of bound information,
domain name to ip-address as well as domain name to various other kinds of bound
information

2) SLDDAP ... the super light weight distributed directory protocol. In support
of OCP the domain name infrastructure also supported the super light weight
distributed directory protocol where the bound information for the DNS
"certificates" were distributed in for efficient and scallable real-time access.

In conjunction with scenerio #2 where the domain name infrastructure adds a CA
PKI (with the registration of public keys and relying party only domain name
owner certificates) to use the OCP protocol options to request a real-time
certificate containing the bound information (from the domain name
infrastructure ) containing a) domain name, b) ip-address, c) domain name
owner's public key.

Given that this form of domain name infrastructure certificate contains public
key in the bound information then one could consider it a public key
infrastructure certificate (modulo peoples'  opinion regarding the current
integrity and trust in the domain name infrastructures' bound information and
whether or not this is a pki or a PKI).

So lets return to the scenerio #1 trivial case (the situation that covers
99.9999999999999% of the current clients checking some information in a server
certificate).

For the SSL protocol case which would seem to have the higher integrity:

1) current SSL domain name certificate manufactored at some point way in the
past (and possibly containing stale information) which is dependant on the
domain name infrastructure for the validity of the information.

2) a DNS OCP real-time public key infrastructure from the domain name
infrastructure and is dependant on the domain name infrastructure for the
validity of the information.

Both certificates have their fundamental integrity and trust built on the same
domain name infrastructure:

a) one certificate is manufactored way in the past and has increasing
probability of containing stale information.

b) the other certificate is manufactored in real-time in response to an
immediate request for bound information.








"David P. Kemp" <[e-mail]> on 09/01/2000 09:53:20 AM

Please respond to "David P. Kemp" <[e-mail]>

To:   [e-mail]
cc:    (bcc: Lynn Wheeler/CA/FDMS/FDC)
Subject:  Re: Client-side revocation checking capability




What is the threat that the PKI is addressing?   My assumption is that
in 99.99999999% of the cases the company hosting the web server is interested
in preventing the following:

1) user sees "www.companyA.com" on an advertisement and types it in, or
   clicks a link.

2) DNS has been hijacked, the user connects to a bogus server, and the
   user gives up his personal info to the bad guy.  Or the user sees a
   parody of www.companyA.com, or worse.

A server certificate issued by a CA to the company binds a company name
(real world and/or DNS) to the company's private key.  If DNS has been
hijacked, the bad guy still can't impersonate the company web site.
I'd say that 99.999999% of the relying party checking involves seeing
the company's legitimate content; the DNS name is largely irrelevant
for the user's purposes.  The user could type an IP address, or any one
of a number of DNS names, and as long as he gets to the company's
information he couldn't care less how he got it.

In fact, including DNSnames in relying party (browser) checking causes
unnecessary problems with virtual hosting. "www.CompanyA.com" should be
a DNS *Name*, something the user types when he wants to see CompanyA's
information.  It shouldn't be any problem if CompanyA's information is
actually being served from https://www.hosting-service.com/account51/;
the only thing that matters is that the user can be referred from what
he types to where the information resides, and that the legitimate
information provider has CompanyA's private key.

 * DNS security should be about binding DNS names to IP addresses, and
   should have nothing to do with EE keys.
 * PKI security should be about binding names (DNS, rfc822, or a real
   world brand name - "Ford Motor Company") to keys.  The CA's responsibility
   is to ensure that the brand owner and the key are properly matched -
   this is far beyond the scope of a DNS administrator's duties.
 * application security should be about protecting whatever is meaningful
   about the user with the user's private key.  In the case of web servers,
   what is meaningful is the company's content, not a DNSname.

If you try to take shortcuts (by combining DNS and PKI, for example),
you prevent useful things from happening.  DNS security supports
infrastructure availability; PKI supports application security.
Unnecessarily sacrificing web server functionality for security just
gives security a bad name.  And increasing the DNS administrator's
workload hinders the adoption of simple yet valuable name-to-IP
security.














Received: from harry.cmr.gov (harry.cmr.gov [140.162.6.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA26002 for <[e-mail]>; Fri, 1 Sep 2000 14:47:01 -0700 (PDT)
Received: from dolphin.cmr.gov (dolphin [140.162.3.135]) by harry.cmr.gov (8.9.3/8.9.3) with ESMTP id RAA08559; Fri, 1 Sep 2000 17:46:42 -0400 (EDT)
Received: from cais.com (localhost [127.0.0.1]) by dolphin.cmr.gov (8.9.1b+Sun/8.9.1) with ESMTP id RAA02112; Fri, 1 Sep 2000 17:46:41 -0400 (EDT)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 01 Sep 2000 17:46:41 -0400
From: "Patrick G. Moore" <[e-mail]>
Organization: Center for Monitoring Research
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: OCSP support for historical reference to certificate suspension
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

In my case, the signing time is part of the signed data.  We may
like to re-verify old data from our archives at any time.  Thus,
we would also like a "VALID AT" type of option.  I agree that an interval
could be problematic, if a cert was suspended for a period between
the endpoints, how would you discover that.  Just checking the endpoints
would not reveal the suspension.  I would say, if the app is uncertain
of the signing time, let it make as many "VALID AT" queries as it likes
to make it happy.

Pat

Michael Myers wrote:
> 
> This is first I've heard of this specific requirement but it seems quite
> natural once the need is exposed.  We'll take this into account in the
> 2560bis work.  Thanks also for the OPTIONAL.  That'll make things a little
> bit easier.
> 
> But for discussion purposes, I've been architecting under the presumption
> that in the instance when signing time was important, the time when the
> digital signature was created would be integrated somehow into the subject
> electronic document and thus there exist a well-defined time.
> 
> I believe you're implying that it may not be the case that signing time is
> integrated into a subject document, and so one is led to bracket the signing
> time.  Could confirm please, or otherwise clarify?  Thanks.
> 
> Mike
> 
> > -----Original Message-----
> > From: Karl Scheibelhofer [mailto:[e-mail]]
> >
> > > -----Original Message-----
> > > From: Michael Myers [mailto:[e-mail]]
> > > Given the current work underway regarding 2560bis, I
> > propose to include in
> > > the 2560bis work effort an optional "ValidAt" (or some
> > such) field in the
> > > request syntax to accomodate this requirement.
> >
> > normally, it will not be possible to determine the signature
> > creation time
> > exactly. the best i can reliable determine is, that the signature was
> > created in a time intervall (between two time stamps). so if
> > you plan to
> > include a time field, i think it would be nice to consider taking an
> > interval. you can make the second value optional.


Received: from blue.identrus.com ([216.213.93.121]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25481 for <[e-mail]>; Fri, 1 Sep 2000 14:20:39 -0700 (PDT)
Received: by blue.identrus.com with Internet Mail Service (5.5.2650.21) id <Q8W94VPV>; Fri, 1 Sep 2000 17:21:06 -0400
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, [e-mail]
Subject: RE: OCSP in S/MIME and IPSEC
Date: Fri, 1 Sep 2000 17:21:05 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0145A.89A75E70"

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_01C0145A.89A75E70
Content-Type: text/plain;
	charset="iso-8859-1"

Michael,

I was just unaware that this (signature with bundled OCSP response) was a
widely accepted (or at least well understood) "use case."   I was also
unaware that you and others had documented it elsewhere.  As someone else on
this thread pointed out the best way to formalize this is probably not in
the son-of-2560 but perhaps in signature format standards, in s/mime, etc.
I see the wisdom of that view and agree with it.

What you are calling "Asymmetric OCSP" is precisely what is needed in many
applications that I am aware of.  It has also been called "Freshness Proof"
in some applications.  "That which we call a rose by any other name..." etc.
By all means sign me up as a taker for this.  The only question that remains
is:  Where is this use best formalized and documented?  PKCS#7, PEM, S/MIME,
XMLDSIG or application that use these?  I do feel that it is important
enough and of sufficiently wide interest to warrant formalization in
standards.  I will be happy to support this effort in any way I can.

Khaja

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Friday, September 01, 2000 12:51 PM
To: Khaja Ahmed; [e-mail]
Subject: OCSP in S/MIME and IPSEC


Khaja,

I heartily agree.  In fact, this was one of the leading "use cases" I cited
very early on for OCSP's utility.  I don't see though that this case
requires any amendment to OCSP.  Could you elaborate on why you think this
is so?

And as long as we're on the subject, I've been off-and-on talking to folks
about an operational concept I've been calling "Asymmetric OCSP."  (first
briefed publicly a couple of RSAs ago.)

The concept applies best to the road warrior using IPSEC to securely reach
back home, to a customer site on a trouble call, etc..  Basically, during
the IPSEC setup phase the IPSEC server or gateway first checks the RW's cert
by reference to an enterprise OCSP server.  There you get
revocation/validation enforcement on the client.  The server or gateway then
turns around and asks the OCSP server for status on it's (the gw's) cert,
puts this into the handshake and so delivers back to the client
revocation/validation assurance.

It's in-band and clean since the client doesn't have to collaterally run
LDAP etc. to fetch a CRL.  Also, there's no client-side state maintenance
re: CRLs.  The client gets realtime effects on the revocation of a gw's
cert.  Finally, all the heavy lifting is done in the back office where
there's sufficient platform cycles and bandwidth to do this efficiently (vs.
forcing a limited client to go fetch CRLs from wherever using whatever
protocol.)  

Takers, anyone?

Mike


-----Original Message-----
From: Khaja Ahmed [mailto:[e-mail]]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; [e-mail];
[e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification


Under some circumstances or for some communities it may be possible for the
sender of the signed data to send along with the signed data proof that at
the time of signing (+/- some tolerance limit) the certificate was not
revoked. In other words, the sender could get an ocsp response from a common
trusted responder and include this with the transmission of the signed data.
This approach offers the advantage that the response can be archived /
stored along with the signature.  At a later date when the archived / stored
signed data and signature is retrieved it can be readily verified as having
been valid at creation time (+/- tolerance limit).  
Is this not an ability that we should formalize and add to appropriate
protocols like OCSP? 
Khaja 
Phone: (+43) [phone] 

------_=_NextPart_001_01C0145A.89A75E70
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: OCSP in S/MIME and IPSEC</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Michael,</FONT>
</P>

<P><FONT SIZE=3D2>I was just unaware that this (signature with bundled =
OCSP response) was a widely accepted (or at least well understood) =
&quot;use case.&quot;&nbsp;&nbsp; I was also unaware that you and =
others had documented it elsewhere.&nbsp; As someone else on this =
thread pointed out the best way to formalize this is probably not in =
the son-of-2560 but perhaps in signature format standards, in s/mime, =
etc.&nbsp; I see the wisdom of that view and agree with it.</FONT></P>

<P><FONT SIZE=3D2>What you are calling &quot;Asymmetric OCSP&quot; is =
precisely what is needed in many applications that I am aware of.&nbsp; =
It has also been called &quot;Freshness Proof&quot; in some =
applications.&nbsp; &quot;That which we call a rose by any other =
name...&quot; etc.&nbsp; By all means sign me up as a taker for =
this.&nbsp; The only question that remains is:&nbsp; Where is this use =
best formalized and documented?&nbsp; PKCS#7, PEM, S/MIME, XMLDSIG or =
application that use these?&nbsp; I do feel that it is important enough =
and of sufficiently wide interest to warrant formalization in =
standards.&nbsp; I will be happy to support this effort in any way I =
can.</FONT></P>

<P><FONT SIZE=3D2>Khaja</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Myers [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>Sent: Friday, September 01, 2000 12:51 PM</FONT>
<BR><FONT SIZE=3D2>To: Khaja Ahmed; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: OCSP in S/MIME and IPSEC</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Khaja,</FONT>
</P>

<P><FONT SIZE=3D2>I heartily agree.&nbsp; In fact, this was one of the =
leading &quot;use cases&quot; I cited</FONT>
<BR><FONT SIZE=3D2>very early on for OCSP's utility.&nbsp; I don't see =
though that this case</FONT>
<BR><FONT SIZE=3D2>requires any amendment to OCSP.&nbsp; Could you =
elaborate on why you think this</FONT>
<BR><FONT SIZE=3D2>is so?</FONT>
</P>

<P><FONT SIZE=3D2>And as long as we're on the subject, I've been =
off-and-on talking to folks</FONT>
<BR><FONT SIZE=3D2>about an operational concept I've been calling =
&quot;Asymmetric OCSP.&quot;&nbsp; (first</FONT>
<BR><FONT SIZE=3D2>briefed publicly a couple of RSAs ago.)</FONT>
</P>

<P><FONT SIZE=3D2>The concept applies best to the road warrior using =
IPSEC to securely reach</FONT>
<BR><FONT SIZE=3D2>back home, to a customer site on a trouble call, =
etc..&nbsp; Basically, during</FONT>
<BR><FONT SIZE=3D2>the IPSEC setup phase the IPSEC server or gateway =
first checks the RW's cert</FONT>
<BR><FONT SIZE=3D2>by reference to an enterprise OCSP server.&nbsp; =
There you get</FONT>
<BR><FONT SIZE=3D2>revocation/validation enforcement on the =
client.&nbsp; The server or gateway then</FONT>
<BR><FONT SIZE=3D2>turns around and asks the OCSP server for status on =
it's (the gw's) cert,</FONT>
<BR><FONT SIZE=3D2>puts this into the handshake and so delivers back to =
the client</FONT>
<BR><FONT SIZE=3D2>revocation/validation assurance.</FONT>
</P>

<P><FONT SIZE=3D2>It's in-band and clean since the client doesn't have =
to collaterally run</FONT>
<BR><FONT SIZE=3D2>LDAP etc. to fetch a CRL.&nbsp; Also, there's no =
client-side state maintenance</FONT>
<BR><FONT SIZE=3D2>re: CRLs.&nbsp; The client gets realtime effects on =
the revocation of a gw's</FONT>
<BR><FONT SIZE=3D2>cert.&nbsp; Finally, all the heavy lifting is done =
in the back office where</FONT>
<BR><FONT SIZE=3D2>there's sufficient platform cycles and bandwidth to =
do this efficiently (vs.</FONT>
<BR><FONT SIZE=3D2>forcing a limited client to go fetch CRLs from =
wherever using whatever</FONT>
<BR><FONT SIZE=3D2>protocol.)&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Takers, anyone?</FONT>
</P>

<P><FONT SIZE=3D2>Mike</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Khaja Ahmed [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, August 31, 2000 4:27 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Karl Scheibelhofer'; Peter Sylvester; =
[e-mail];</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: RFC 2560 - OCSP - Clarification</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Under some circumstances or for some communities it =
may be possible for the</FONT>
<BR><FONT SIZE=3D2>sender of the signed data to send along with the =
signed data proof that at</FONT>
<BR><FONT SIZE=3D2>the time of signing (+/- some tolerance limit) the =
certificate was not</FONT>
<BR><FONT SIZE=3D2>revoked. In other words, the sender could get an =
ocsp response from a common</FONT>
<BR><FONT SIZE=3D2>trusted responder and include this with the =
transmission of the signed data.</FONT>
<BR><FONT SIZE=3D2>This approach offers the advantage that the response =
can be archived /</FONT>
<BR><FONT SIZE=3D2>stored along with the signature.&nbsp; At a later =
date when the archived / stored</FONT>
<BR><FONT SIZE=3D2>signed data and signature is retrieved it can be =
readily verified as having</FONT>
<BR><FONT SIZE=3D2>been valid at creation time (+/- tolerance =
limit).&nbsp; </FONT>
<BR><FONT SIZE=3D2>Is this not an ability that we should formalize and =
add to appropriate</FONT>
<BR><FONT SIZE=3D2>protocols like OCSP? </FONT>
<BR><FONT SIZE=3D2>Khaja </FONT>
<BR><FONT SIZE=3D2>Phone: (+43) [phone] </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0145A.89A75E70--


Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24835 for <[e-mail]>; Fri, 1 Sep 2000 13:54:43 -0700 (PDT)
Received: from rgm.htt-consult.com ([63.82.18.195]) by htt-consult.com ; Fri, 01 Sep 2000 16:55:54 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 01 Sep 2000 16:53:20 -0400
To: Michael Myers <[e-mail]>, Khaja Ahmed <[e-mail]>, [e-mail]
From: Robert Moskowitz <[e-mail]>
Subject: Re: OCSP in S/MIME and IPSEC
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:51 PM 9/1/2000 -0700, Michael Myers wrote:

>The concept applies best to the road warrior using IPSEC to securely reach
>back home, to a customer site on a trouble call, etc..  Basically, during
>the IPSEC setup phase the IPSEC server or gateway first checks the RW's cert
>by reference to an enterprise OCSP server.  There you get
>revocation/validation enforcement on the client.  The server or gateway then
>turns around and asks the OCSP server for status on it's (the gw's) cert,
>puts this into the handshake and so delivers back to the client
>revocation/validation assurance.
>
>It's in-band and clean since the client doesn't have to collaterally run
>LDAP etc. to fetch a CRL.  Also, there's no client-side state maintenance
>re: CRLs.  The client gets realtime effects on the revocation of a gw's
>cert.  Finally, all the heavy lifting is done in the back office where
>there's sufficient platform cycles and bandwidth to do this efficiently (vs.
>forcing a limited client to go fetch CRLs from wherever using whatever
>protocol.)
>
>Takers, anyone?

ISAKMP can easily send info like this in the Main Mode payload.  I think it 
is the 4th packet.

But just as easily, the GW can send the CRL to the gateway.  And if the CA 
has partitioned its CRLs, all of the gateways could be in one CRL with the 
road warriors using a different CRL.  So the CRL in the GW can can be nice 
and small too.

Either way it would work well.  Anyone with a two-headed coin?



Robert Moskowitz
ICSA
Security Interest EMail: [e-mail]



Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24429 for <[e-mail]>; Fri, 1 Sep 2000 13:42:41 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 1 Sep 2000 13:43:44 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 01 Sep 2000 13:43:44 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <RMQWMHQF>; Fri, 01 Sep 2000 13:33:05 -0700
Content-return: allowed
Date: Fri, 01 Sep 2000 13:33:03 -0700
From: Peter Williams <[e-mail]>
Subject: RE: OCSP in S/MIME and IPSEC
To: Khaja Ahmed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/signed;	protocol="application/x-pkcs7-signature"; micalg=SHA1;	boundary="----=_NextPart_000_0000_01C01419.EB6C86F0"

This is a multi-part message in MIME format.

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

Policy management and roaming protocols
are already a core part of  products
like SecureRemote/Client from Checkpoint.

http://www.checkpoint.com/products/vpn1/secureclient.html

Plugging OCSP into the backend of the policy
server seems an obvious thing to do.

If that policy server was then transactionally-aware,
it could also offload some legal obligations from
the client when dealing with one or other CA in
the various trust networks. I think Mike is
re-validating the 4-corner model; wherein
reliance for a particular purpose is controlled by parties 
other than the  CA. CAs just do key and authentication management,
an increasing commodity available everywhere, even
comes for free with Windows. The network or such infrastructure 
as transaction/policy servers enforce the business 
and/or legal reliance logic.

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Friday, September 01, 2000 12:51 PM
To: Khaja Ahmed; [e-mail]
Subject: OCSP in S/MIME and IPSEC


Khaja,

I heartily agree.  In fact, this was one of the leading "use cases" I
cited
very early on for OCSP's utility.  I don't see though that this case
requires any amendment to OCSP.  Could you elaborate on why you think
this
is so?

And as long as we're on the subject, I've been off-and-on talking to
folks
about an operational concept I've been calling "Asymmetric OCSP."
(first
briefed publicly a couple of RSAs ago.)

The concept applies best to the road warrior using IPSEC to securely
reach
back home, to a customer site on a trouble call, etc..  Basically,
during
the IPSEC setup phase the IPSEC server or gateway first checks the RW's
cert
by reference to an enterprise OCSP server.  There you get
revocation/validation enforcement on the client.  The server or gateway
then
turns around and asks the OCSP server for status on it's (the gw's)
cert,
puts this into the handshake and so delivers back to the client
revocation/validation assurance.

It's in-band and clean since the client doesn't have to collaterally run
LDAP etc. to fetch a CRL.  Also, there's no client-side state
maintenance
re: CRLs.  The client gets realtime effects on the revocation of a gw's
cert.  Finally, all the heavy lifting is done in the back office where
there's sufficient platform cycles and bandwidth to do this efficiently
(vs.
forcing a limited client to go fetch CRLs from wherever using whatever
protocol.)  

Takers, anyone?

Mike


-----Original Message-----
From: Khaja Ahmed [mailto:[e-mail]]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; [e-mail];
[e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification


Under some circumstances or for some communities it may be possible for
the
sender of the signed data to send along with the signed data proof that
at
the time of signing (+/- some tolerance limit) the certificate was not
revoked. In other words, the sender could get an ocsp response from a
common
trusted responder and include this with the transmission of the signed
data.
This approach offers the advantage that the response can be archived /
stored along with the signature.  At a later date when the archived /
stored
signed data and signature is retrieved it can be readily verified as
having
been valid at creation time (+/- tolerance limit).  
Is this not an ability that we should formalize and add to appropriate
protocols like OCSP? 
Khaja 
Phone: (+43) [phone] 

------=_NextPart_000_0000_01C01419.EB6C86F0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE4TCCBN0w
ggSHoAMCAQICCmFGnFQAAAAABDAwDQYJKoZIhvcNAQEFBQAwgZsxIDAeBgkqhkiG9w0BCQEWEXdp
bGRpZEB3aWxkaWQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEPMA0GA1UE
BxMGVmVuaWNlMQ8wDQYDVQQKEwZXaWxkSUQxIjAgBgNVBAsTGVRvdGFsbHkgRnJlZSBEaWdpdGFs
IEkuRC4xDzANBgNVBAMTBldpbGRJRDAeFw0wMDA4MzAwMTQ4MzZaFw0wMDA5MjkwMTU4MzZaMGAx
IjAgBgkqhkiG9w0BCQEWE3BldGVyd0B2YWxpY2VydC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTEQMA4GA1UEBxMHRnJlbW9udDEOMAwGA1UEAxMFUGV0ZXIwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAMW8EUTQVXAVF9IVzKUUd8qetmKkvqT9/Dxnp1E0lIvdogzbS4Jh8bvROju4C6gG
Ep/pBHHX+2i7JoDhisXTXXy0PEqW3yg0hQyEOQiOlAFqs+DAOizlR9RVOWsNgMtWAOLUVlt69ZGi
2aUWMpqpKCwZo/zIpnofu5CQPujOBvXRAgMBAAGjggKhMIICnTAOBgNVHQ8BAf8EBAMCBPAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR0Yezt69JX/BHQFUJcfE8nuFvm
xTCB1wYDVR0jBIHPMIHMgBQVLSR/WI70zcWFy2Vw0MyXTdFFP6GBoaSBnjCBmzEgMB4GCSqGSIb3
DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVl
IERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEghBYYc07qTXLu0dEUcR2pp/pMIGRBgNVHR8E
gYkwgYYwQKA+oDyGOmh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5y
b2xsL1dpbGRJRC5jcmwwQqBAoD6GPGZpbGU6Ly9cXGRhbDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4u
Y29tXENlcnRFbnJvbGxcV2lsZElELmNybDCB3gYIKwYBBQUHAQEEgdEwgc4wZAYIKwYBBQUHMAKG
WGh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5yb2xsL2RhbDAwMjA4
MDN3MDAxLmRhdGFyZXR1cm4uY29tX1dpbGRJRC5jcnQwZgYIKwYBBQUHMAKGWmZpbGU6Ly9cXGRh
bDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4uY29tXENlcnRFbnJvbGxcZGFsMDAyMDgwM3cwMDEuZGF0
YXJldHVybi5jb21fV2lsZElELmNydDANBgkqhkiG9w0BAQUFAANBAAtW+yr27kv/q5QxjuQgPtJ7
r/8S5HnBAma0qADwKk3As4Z6xi7Kj4ajN3nqr/sZnNHL2g5nxsyue2Oslzy5+04xggKuMIICqgIB
ATCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMw
EQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAG
A1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEAgphRpxUAAAA
AAQwMAkGBSsOAwIaBQCgggFZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDkwMTIwMzgzMlowIwYJKoZIhvcNAQkEMRYEFNBsQBqX7iXa3ct/VXTvvsre+mgyMDwG
CSqGSIb3DQEJDzEvMC0wBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcN
AgUwgbsGCSsGAQQBgjcQBDGBrTCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5j
b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzAN
BgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UE
AxMGV2lsZElEAgphRpxUAAAAAAQwMA0GCSqGSIb3DQEBAQUABIGAUbfLYfqGjvbnYXRQPL1cQ2+V
agmeU0jnhm47fPx0e0HOXLRU008oKeIEiY/VD10Hffp1geHBcQKsrVSBQTSy7y8tQt09lvwL25QQ
xSKm65pLhalRyRroMlAcNWb0DCVHEVJH1BerHS8i2i3vs8vug16PS2UhDLM3yLyEBydCM2QAAAAA
AAA=

------=_NextPart_000_0000_01C01419.EB6C86F0--



Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23381 for <[e-mail]>; Fri, 1 Sep 2000 12:51:25 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA09489; Fri, 1 Sep 2000 12:48:44 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <R9H9KJDH>; Fri, 1 Sep 2000 12:51:05 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Karl Scheibelhofer <[e-mail]>, [e-mail]
Subject: RE: OCSP support for historical reference to certificate suspensi on
Date: Fri, 1 Sep 2000 12:51:02 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

This is first I've heard of this specific requirement but it seems quite
natural once the need is exposed.  We'll take this into account in the
2560bis work.  Thanks also for the OPTIONAL.  That'll make things a little
bit easier.

But for discussion purposes, I've been architecting under the presumption
that in the instance when signing time was important, the time when the
digital signature was created would be integrated somehow into the subject
electronic document and thus there exist a well-defined time.

I believe you're implying that it may not be the case that signing time is
integrated into a subject document, and so one is led to bracket the signing
time.  Could confirm please, or otherwise clarify?  Thanks.

Mike


> -----Original Message-----
> From: Karl Scheibelhofer [mailto:[e-mail]]
> 
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Given the current work underway regarding 2560bis, I 
> propose to include in
> > the 2560bis work effort an optional "ValidAt" (or some 
> such) field in the
> > request syntax to accomodate this requirement.
> 
> normally, it will not be possible to determine the signature 
> creation time
> exactly. the best i can reliable determine is, that the signature was
> created in a time intervall (between two time stamps). so if 
> you plan to
> include a time field, i think it would be nice to consider taking an
> interval. you can make the second value optional.


Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23252 for <[e-mail]>; Fri, 1 Sep 2000 12:50:51 -0700 (PDT)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id MAA09483; Fri, 1 Sep 2000 12:48:41 -0700 (PDT)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <R9H9KJDF>; Fri, 1 Sep 2000 12:51:02 -0700
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: Khaja Ahmed <[e-mail]>, [e-mail]
Subject: OCSP in S/MIME and IPSEC
Date: Fri, 1 Sep 2000 12:51:02 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Khaja,

I heartily agree.  In fact, this was one of the leading "use cases" I cited
very early on for OCSP's utility.  I don't see though that this case
requires any amendment to OCSP.  Could you elaborate on why you think this
is so?

And as long as we're on the subject, I've been off-and-on talking to folks
about an operational concept I've been calling "Asymmetric OCSP."  (first
briefed publicly a couple of RSAs ago.)

The concept applies best to the road warrior using IPSEC to securely reach
back home, to a customer site on a trouble call, etc..  Basically, during
the IPSEC setup phase the IPSEC server or gateway first checks the RW's cert
by reference to an enterprise OCSP server.  There you get
revocation/validation enforcement on the client.  The server or gateway then
turns around and asks the OCSP server for status on it's (the gw's) cert,
puts this into the handshake and so delivers back to the client
revocation/validation assurance.

It's in-band and clean since the client doesn't have to collaterally run
LDAP etc. to fetch a CRL.  Also, there's no client-side state maintenance
re: CRLs.  The client gets realtime effects on the revocation of a gw's
cert.  Finally, all the heavy lifting is done in the back office where
there's sufficient platform cycles and bandwidth to do this efficiently (vs.
forcing a limited client to go fetch CRLs from wherever using whatever
protocol.)  

Takers, anyone?

Mike


-----Original Message-----
From: Khaja Ahmed [mailto:[e-mail]]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; [e-mail];
[e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification


Under some circumstances or for some communities it may be possible for the
sender of the signed data to send along with the signed data proof that at
the time of signing (+/- some tolerance limit) the certificate was not
revoked. In other words, the sender could get an ocsp response from a common
trusted responder and include this with the transmission of the signed data.
This approach offers the advantage that the response can be archived /
stored along with the signature.  At a later date when the archived / stored
signed data and signature is retrieved it can be readily verified as having
been valid at creation time (+/- tolerance limit).  
Is this not an ability that we should formalize and add to appropriate
protocols like OCSP? 
Khaja 
Phone: (+43) [phone] 


Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21888 for <[e-mail]>; Fri, 1 Sep 2000 12:08:08 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 1 Sep 2000 12:09:20 -0700 (PDT)
Received: from seine.valicert.com ([192.168.2.23]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 01 Sep 2000 12:09:20 -0700 (PDT)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <RMQWMH1S>; Fri, 01 Sep 2000 11:58:41 -0700
Content-return: allowed
Date: Fri, 01 Sep 2000 11:58:40 -0700
From: Peter Williams <[e-mail]>
Subject: RE: RFC 2560 - OCSP - Clarification
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: multipart/signed;	protocol="application/x-pkcs7-signature"; micalg=SHA1;	boundary="----=_NextPart_000_0000_01C0140C.BBBC8070"

This is a multi-part message in MIME format.

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


David,

In our "Digital Certificates"
book, we reported on a simple java experiment using 
simple multicast to distribute CRL information 
on a schedule. One can easily use the same
multicast transport to handle request/responses
for OCSP messages. The multicast security
architecture can control who relies on
an OCSP response, even when that response
is intended for a particular recipient.

The component is invoked using a (secure) DCOM/RPC request.
(Java RMI could presumably do the same, once one
adds the java wrapper to COM). It went to the Microsoft CA's  
database, and sent the CRL  value over a (secure) multicast 
channel. The security I  envisaged (not discussed in the book)  
was based on the IETF and DARPA's secure multicast work, which 
leveraged secure DNS, IPSEC AH, and IGMP to enforce access control,
distribution of, and reliance on the value to authorized 
relying parties.
  
(The source code is included on the disk if you want
to play with it on NT's java.)

Security and Use of multicast in secure reliance protocols is 
orthogonal to the syntax and access protocol design of CRLs and 
OCSP, in my view.

Peter.
 

-----Original Message-----
From: David P. Kemp [mailto:[e-mail]]
Sent: Friday, September 01, 2000 11:09 AM
To: [e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification


Mike,

There is no need to justify the existence of OCSP with false statements
concerning CRLs - OCSP will stand on its own merits in some locations,
and CRLs will excel in others.

"Immediate timeliness" is not "inherently" beyond the scope of CRLs
(which can be issued immediately upon every revocation event), and not
beyond the scope of periodically-produced CRLs, which can be produced
as frequently as anyone's definition of "immediate" requires.  Is 60
seconds "immediate"?  Is one second?  If 10 million RPs absolutely need
revocation information three seconds after it is entered into a CA
database, then have the CA generate a delta CRL every second and stick
it on a web page or broadcast it as TV vertical interval data or FM
subcarrier data.

OCSP doesn't work in multicast/broadcast (IP or broadband) environments,
and web caches can be considered a broadcast medium if you demand the
absolute minimum delay between the CA's knowledge and a number of
clients' knowledge of revocation events.

I would say that OCSP is not primarily suited to address immediate
timeliness, but is instead primarily suited to minimize the complexity
of clients by pushing CRL processing logic and memory requirements onto
distributed (LAN-based) servers.  And I would challenge any claim that
OCSP from the RP to the CA is more timely than using local CRL-fed OCSP
servers, for any configuration of client population, CA processing
capacity, CA bandwidth, OCSP server capacity, and OCSP server
bandwidth.

Regards,
Dave


> From: Michael Myers <[e-mail]>
> To: Liaquat Khan <[e-mail]>, [e-mail]
>
> But OCSP is and was primarly intended to address immediate timeliness,
a
> feature that is inherently beyond the scope of periodically produced
CRLs.
> 
> 2560bis will clarify this intent.
> 
> Mike

------=_NextPart_000_0000_01C0140C.BBBC8070
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE4TCCBN0w
ggSHoAMCAQICCmFGnFQAAAAABDAwDQYJKoZIhvcNAQEFBQAwgZsxIDAeBgkqhkiG9w0BCQEWEXdp
bGRpZEB3aWxkaWQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEPMA0GA1UE
BxMGVmVuaWNlMQ8wDQYDVQQKEwZXaWxkSUQxIjAgBgNVBAsTGVRvdGFsbHkgRnJlZSBEaWdpdGFs
IEkuRC4xDzANBgNVBAMTBldpbGRJRDAeFw0wMDA4MzAwMTQ4MzZaFw0wMDA5MjkwMTU4MzZaMGAx
IjAgBgkqhkiG9w0BCQEWE3BldGVyd0B2YWxpY2VydC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTEQMA4GA1UEBxMHRnJlbW9udDEOMAwGA1UEAxMFUGV0ZXIwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAMW8EUTQVXAVF9IVzKUUd8qetmKkvqT9/Dxnp1E0lIvdogzbS4Jh8bvROju4C6gG
Ep/pBHHX+2i7JoDhisXTXXy0PEqW3yg0hQyEOQiOlAFqs+DAOizlR9RVOWsNgMtWAOLUVlt69ZGi
2aUWMpqpKCwZo/zIpnofu5CQPujOBvXRAgMBAAGjggKhMIICnTAOBgNVHQ8BAf8EBAMCBPAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBR0Yezt69JX/BHQFUJcfE8nuFvm
xTCB1wYDVR0jBIHPMIHMgBQVLSR/WI70zcWFy2Vw0MyXTdFFP6GBoaSBnjCBmzEgMB4GCSqGSIb3
DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVl
IERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEghBYYc07qTXLu0dEUcR2pp/pMIGRBgNVHR8E
gYkwgYYwQKA+oDyGOmh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5y
b2xsL1dpbGRJRC5jcmwwQqBAoD6GPGZpbGU6Ly9cXGRhbDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4u
Y29tXENlcnRFbnJvbGxcV2lsZElELmNybDCB3gYIKwYBBQUHAQEEgdEwgc4wZAYIKwYBBQUHMAKG
WGh0dHA6Ly9kYWwwMDIwODAzdzAwMS5kYXRhcmV0dXJuLmNvbS9DZXJ0RW5yb2xsL2RhbDAwMjA4
MDN3MDAxLmRhdGFyZXR1cm4uY29tX1dpbGRJRC5jcnQwZgYIKwYBBQUHMAKGWmZpbGU6Ly9cXGRh
bDAwMjA4MDN3MDAxLmRhdGFyZXR1cm4uY29tXENlcnRFbnJvbGxcZGFsMDAyMDgwM3cwMDEuZGF0
YXJldHVybi5jb21fV2lsZElELmNydDANBgkqhkiG9w0BAQUFAANBAAtW+yr27kv/q5QxjuQgPtJ7
r/8S5HnBAma0qADwKk3As4Z6xi7Kj4ajN3nqr/sZnNHL2g5nxsyue2Oslzy5+04xggKuMIICqgIB
ATCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5jb20xCzAJBgNVBAYTAlVTMRMw
EQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzANBgNVBAoTBldpbGRJRDEiMCAG
A1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UEAxMGV2lsZElEAgphRpxUAAAA
AAQwMAkGBSsOAwIaBQCgggFZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTAwMDkwMTE5MDQwOFowIwYJKoZIhvcNAQkEMRYEFAJDGdEEVeWCmr5NH6ipcqTYgBw1MDwG
CSqGSIb3DQEJDzEvMC0wBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcN
AgUwgbsGCSsGAQQBgjcQBDGBrTCBqjCBmzEgMB4GCSqGSIb3DQEJARYRd2lsZGlkQHdpbGRpZC5j
b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZWZW5pY2UxDzAN
BgNVBAoTBldpbGRJRDEiMCAGA1UECxMZVG90YWxseSBGcmVlIERpZ2l0YWwgSS5ELjEPMA0GA1UE
AxMGV2lsZElEAgphRpxUAAAAAAQwMA0GCSqGSIb3DQEBAQUABIGAvP3+3YlbIHTES3w9s3WvDUHN
GlzHOesthUoZnP4UsF4cOJDYgYtTESf2U09o0+cbOvpVk5BPpua+uRFtm48+VWtBTYrNPpnkCl3P
X2XGlo99b1Q5rfqCdrBahlT5rKJXaT0XNxftduRNS2zkBZ2dQ4RqSbwA7cB9z2XkgNoiqYoAAAAA
AAA=

------=_NextPart_000_0000_01C0140C.BBBC8070--



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20419 for <[e-mail]>; Fri, 1 Sep 2000 11:13:15 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id NAA11346 for <[e-mail]>; Fri, 1 Sep 2000 13:57:55 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 1 Sep 2000 14:09:09 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: RFC 2560 - OCSP - Clarification
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ySPVWo/EeeWbm4z5i+4fYw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

Mike,

There is no need to justify the existence of OCSP with false statements
concerning CRLs - OCSP will stand on its own merits in some locations,
and CRLs will excel in others.

"Immediate timeliness" is not "inherently" beyond the scope of CRLs
(which can be issued immediately upon every revocation event), and not
beyond the scope of periodically-produced CRLs, which can be produced
as frequently as anyone's definition of "immediate" requires.  Is 60
seconds "immediate"?  Is one second?  If 10 million RPs absolutely need
revocation information three seconds after it is entered into a CA
database, then have the CA generate a delta CRL every second and stick
it on a web page or broadcast it as TV vertical interval data or FM
subcarrier data.

OCSP doesn't work in multicast/broadcast (IP or broadband) environments,
and web caches can be considered a broadcast medium if you demand the
absolute minimum delay between the CA's knowledge and a number of
clients' knowledge of revocation events.

I would say that OCSP is not primarily suited to address immediate
timeliness, but is instead primarily suited to minimize the complexity
of clients by pushing CRL processing logic and memory requirements onto
distributed (LAN-based) servers.  And I would challenge any claim that
OCSP from the RP to the CA is more timely than using local CRL-fed OCSP
servers, for any configuration of client population, CA processing
capacity, CA bandwidth, OCSP server capacity, and OCSP server
bandwidth.

Regards,
Dave


> From: Michael Myers <[e-mail]>
> To: Liaquat Khan <[e-mail]>, [e-mail]
>
> But OCSP is and was primarly intended to address immediate timeliness, a
> feature that is inherently beyond the scope of periodically produced CRLs.
> 
> 2560bis will clarify this intent.
> 
> Mike



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18783 for <[e-mail]>; Fri, 1 Sep 2000 09:59:02 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA24683; Fri, 1 Sep 2000 19:00:11 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Sep 2000 19:00:11 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA19185; Fri, 1 Sep 2000 19:00:10 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA13335; Fri, 1 Sep 2000 19:00:10 +0200 (MET DST)
Date: Fri, 1 Sep 2000 19:00:10 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification
Cc: [e-mail]

> 
> Under some circumstances or for some communities it may be possible for the
> sender of the signed data to send along with the signed data proof that at
> the time of signing (+/- some tolerance limit) the certificate was not
> revoked. In other words, the sender could get an ocsp response from a common
> trusted responder and include this with the transmission of the signed data.
> This approach offers the advantage that the response can be archived /
> stored along with the signature.  At a later date when the archived / stored
> signed data and signature is retrieved it can be readily verified as having
> been valid at creation time (+/- tolerance limit).  
> 
> Is this not an ability that we should formalize and add to appropriate
> protocols like OCSP?

You can also add at any time a CRL in S/MIME for example.  

At least the time stamping protocol and dvcs provide for adding the
results in a PKCS9 attribute. And also the draft for electronic signature formats
to include OCSP responses.

But the question was whether OCSP (and/or other bricks handled by pkix) need
enhancements so that applications can benefit from that without creating
an unimplementable protocol.  

You don't add the actual usage rules to ocsp. The 'electronic signature
format' text is an example containing some explicit rules for verification
of documents. This is above certificate, and S/MIME. 



Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18578 for <[e-mail]>; Fri, 1 Sep 2000 09:57:07 -0700 (PDT)
Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id MAA13098 for <[e-mail]>; Fri, 1 Sep 2000 12:42:06 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 1 Sep 2000 12:53:20 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Client-side revocation checking capability
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: nxRTFFbnW8FIKRS5MrhpFA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: [e-mail]
>
> Now looking at possibly a trivial occurance of relying party checking ... 
maybe
> only a trivial 99.99999999999999% of all relying party "checking" currently
> going on ... it would appear that the most common occurance of a relying party
> checking something is a SSL relying party checking a domain name.
> 99.999999999999% of all such checking might not seem like a valid situation to
> consider.


What is the threat that the PKI is addressing?   My assumption is that
in 99.99999999% of the cases the company hosting the web server is interested
in preventing the following:

1) user sees "www.companyA.com" on an advertisement and types it in, or
   clicks a link.

2) DNS has been hijacked, the user connects to a bogus server, and the
   user gives up his personal info to the bad guy.  Or the user sees a
   parody of www.companyA.com, or worse.

A server certificate issued by a CA to the company binds a company name
(real world and/or DNS) to the company's private key.  If DNS has been
hijacked, the bad guy still can't impersonate the company web site.
I'd say that 99.999999% of the relying party checking involves seeing
the company's legitimate content; the DNS name is largely irrelevant
for the user's purposes.  The user could type an IP address, or any one
of a number of DNS names, and as long as he gets to the company's
information he couldn't care less how he got it.

In fact, including DNSnames in relying party (browser) checking causes
unnecessary problems with virtual hosting. "www.CompanyA.com" should be
a DNS *Name*, something the user types when he wants to see CompanyA's
information.  It shouldn't be any problem if CompanyA's information is
actually being served from https://www.hosting-service.com/account51/;
the only thing that matters is that the user can be referred from what
he types to where the information resides, and that the legitimate
information provider has CompanyA's private key.

 * DNS security should be about binding DNS names to IP addresses, and 
   should have nothing to do with EE keys.
 * PKI security should be about binding names (DNS, rfc822, or a real
   world brand name - "Ford Motor Company") to keys.  The CA's responsibility
   is to ensure that the brand owner and the key are properly matched -
   this is far beyond the scope of a DNS administrator's duties.
 * application security should be about protecting whatever is meaningful
   about the user with the user's private key.  In the case of web servers,
   what is meaningful is the company's content, not a DNSname.

If you try to take shortcuts (by combining DNS and PKI, for example),
you prevent useful things from happening.  DNS security supports
infrastructure availability; PKI supports application security.
Unnecessarily sacrificing web server functionality for security just
gives security a bad name.  And increasing the DNS administrator's
workload hinders the adoption of simple yet valuable name-to-IP
security.








Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17023 for <[e-mail]>; Fri, 1 Sep 2000 09:14:02 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA23960; Fri, 1 Sep 2000 18:15:12 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Sep 2000 18:15:12 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA18913; Fri, 1 Sep 2000 18:15:11 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA13315; Fri, 1 Sep 2000 18:15:11 +0200 (MET DST)
Date: Fri, 1 Sep 2000 18:15:11 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: RFC 2560 - OCSP - Clarification
Cc: [e-mail]

> 
> Hmmmmm.
Ohhhh :-)

> I don't like the word Document for this process. I will talk more about that
> below.
> Would this mandate that the "user" of this trust process would be
> responsible to tell the RA or issuing CA service that the "trust Instrument"
> in question had been used?
> 
> if so this might be a workable method of answering the "Which One" issue in
> a digital context.
I am not sure that we are in phase here? A CA/RA is not a 'notary' ?


> > "Is this signed document a valid one in this particular application
> context?"
> 
> As I said above - I don't like the term DOCUMENT here. There is too much
> confusion as to what a document contains and is to be used for. Lets call
> these trust process element's "Instruments" just like in the Financial
> World.
what about XYZZY or Y2 ? :-)

> 
> >
> > Depending on the answer, continue with the workflow this way or the other
> > *AND* you might want to add the answer as a verifiable element to the
> 'dossier'.
> 
> OK so the "instrument" is validated for its current viability (meets all the
> app's standards for validity, applicability, and potentially capability as
> well), what next? how do you create a process for terminating the usability
> of any of the potentially remaining digital copies of this that are still in
> circulation? and what is the overhead of that process - these are the next
> germain questions I think.

Hold on, that was not the question at all, we are not talking about copies of
money, or whatever, it is certainly not my problem if you pay me twice,
I may have a slight problem of space, if you send me 100 copies of a motocycle, 
I would certainly not ack the receipt of your delivery or invoice. 
If I send you twice exactly the same order (signed the same date, etc) to me,
I would treat this as a duplicate (within some limits).  

> 
> >
> > You have reduced the problem space to something that seems to be close to
> > what OCSP could respond.
> >
> >
> Exactly - And if OCSP can be used to tell the App that all is well then it
> can also be used to tell the OCSP Source or RA that this instrument has been
> used.
I am lost, what instrument? The certificate, or the signed data? 

I should have said: Since in the space full of fog of possible solutions OCSP
seems to be the closest real one, you try to shake and stretch it so it
might get broken. With a little bit of imaginary one might be able to
solve the complex problem much easier ;-)

PS


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14664 for <[e-mail]>; Fri, 1 Sep 2000 08:45:32 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA23555; Fri, 1 Sep 2000 17:46:43 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Sep 2000 17:46:43 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA18791; Fri, 1 Sep 2000 17:46:41 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA13297; Fri, 1 Sep 2000 17:46:41 +0200 (MET DST)
Date: Fri, 1 Sep 2000 17:46:41 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification

> I agree that some communities may want to know that the signature
> certificate was valid at the
> time that data was signed.  However, many communities might also want to
> know that no event 
> has occurred later that would cast doubt on the validity of the signature.
> For instance, the subject
> of the signature certificate might have belatedly discovered that his
> private key had been compromised.
> It seems inconvenient to send two OSCP requests, one asking "was this
> certificate good in this interval?"
> and a second asking "is this certificate good (but perhaps now expired) at
> the current time?"  It seems 
> like an mechanism that purports to answer the first question is obligated to
> implicitly answer the second.
> 

Unless one assumes that it should be possible to detect 
a suspended and later become valid certificate, and that this situation
should lead to a rejection of the signature, the current OCSP question
seems sufficient to give the anwser to both questions. 

Who would suspend a certificate? The owner? Someone else? If so, 
what stops you of suspending it, and NEVER remake it valid but just
issue a new certificate.  Also, the information about the transition
from suspended to good has a propagation delay, 

What if a signer falls on a slow verifier who has not received the
latest update of CRLs or else, can this verifier immediately execute
a death penalty? :-)
  


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02790 for <[e-mail]>; Fri, 1 Sep 2000 07:35:20 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA22776; Fri, 1 Sep 2000 16:36:29 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Sep 2000 16:36:29 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA18597; Fri, 1 Sep 2000 16:36:28 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA13284; Fri, 1 Sep 2000 16:36:28 +0200 (MET DST)
Date: Fri, 1 Sep 2000 16:36:28 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification
Cc: [e-mail]

> 
> it is the goal of our current project to create/verify legally valid
> signatures (following the european signature directive).
> 

You proably mean that you want to follow one the laws of the
member countries that are supposed to be conformant with
the directive.  

The only thing that the directive requires is that
a provider has to offer an efficient revocation service
without saying what that would mean in detail. 

The laws may still say many things about the issue, they need
to be accompagnied by decrets that explain the current
state of art technical requirements for certification
authorities. 

Do these rules require that you have more than two states
(good and revoked), and can there be more than at most
one change from good to bad? The fact of using X.509 and its
revocation, doesn't mean that you implement all possible
theoretical values.

Also, the directive handle at all the situations
of complex b2b relationships because this are closed groups,
the directive handles 'individuals'. 




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA26616 for <[e-mail]>; Fri, 1 Sep 2000 05:34:08 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA21595; Fri, 1 Sep 2000 14:35:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 1 Sep 2000 14:35:16 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA18286; Fri, 1 Sep 2000 14:35:15 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA13244; Fri, 1 Sep 2000 14:35:15 +0200 (MET DST)
Date: Fri, 1 Sep 2000 14:35:15 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: RFC 2560 - OCSP - Clarification
Cc: [e-mail]

> > A verifier can also simply ask some server (of the other company or a
> > local company centralized server)
> >
> > "Is this signed document a valid one in this particular
> > application context?"
> 
> sorry, but i don't want to send my documents for verification to other
> companies. and i think most managers won't allow that. moreover, you have
> the to anser the same question at this server.
A slight misunderstanding: 

The verifier sends the document to the originating company or a notary. 

In some circumstances you are even required to send a signed document
to a third party, otherwise the business cannot be done, try to buy a house
without a notary. 

> no matter where you process it, for a serious validation you need to answer
> this question.

But it doesn't mean that one could not require that if an answer must be producable
at any time in the future the creator should make some additional effort to
make this possible.  

> 
> you may not be allowed to sign anything because of legal issues.
Who do you want to protect and when? The signer or the verifier? 

> >
> > Why do you start with the second step of validating the cert? you
> > can also ask
> > some server to validate the whole document.
> 
> yes, implementing a server for document validation makes sense. but this
> server also needs an answer for this question.

Such a server is not necessarily in the same situation as a CA or OCSP responder.
A server could for example base its decision on the existance of the document
in an archive of all validly signed documents, the procedure could require that all
documents that leave a company must be archived, similar to the 'company stamp'
a document would only be considered valid if the archive server has added a 'stamp'
on the document saying 'valid for this purpose, correctly signed by, and archived'.

Or if the server validates certificates as part of that process, this is the
only place where historic CA information may be required. 

 

 


Received: from mail0.sibs.pt (mail0.sibs.pt [195.138.0.101]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA21438 for <[e-mail]>; Fri, 1 Sep 2000 04:23:22 -0700 (PDT)
Received: (qmail 15881 invoked from network); 1 Sep 2000 11:14:24 -0000
Received: from unknown (HELO sibs.pt) (195.138.0.90) by mail0.sibs.pt with SMTP; 1 Sep 2000 11:14:24 -0000
Message-ID: <[e-mail]>
Date: Fri, 01 Sep 2000 12:25:34 +0100
From: Bruno Salgueiro <[e-mail]>
Organization: SIBS
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: pt,en
MIME-Version: 1.0
To: Khaja Ahmed <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 2560 - OCSP - Clarification
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB74902A285C097E5CA1C1E2A"

This is a cryptographically signed message in MIME format.

--------------msB74902A285C097E5CA1C1E2A
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi Khaja. Just few comments.

The Bloomingdale's example would use the OCSP request at the time where
Lee's Shirts receive the signed order. As this is a contract that ends
when the goods are delivered, i.e., it isn't lenghty over time, it is
not
required to ask for the validity for a time interval.

Assuming that the answer for the OCSP protocol could be semantically
accurate,
and your examples demonstrate that probably the request would need an
extra
information to desambiguate the answer, my opinion is that with DVCS
draft
we may be solving the issue of knowing if at a particular time the
certi-
ficate's state and more (assuming that DVCS also verifies signatures,
certificate's validity and after that signs the OK/not OK answer), which
is
far more useful.

Finally, answering whether a certificate was valid at interval [t1, t2]
may
disclose some information that relying parties don't really need and/or
end
users don't want CAs to disclose... I guess that these problems should
be
tackled by DVCS but the authors can surely give their opinion about
this.

Regards,

> Khaja Ahmed wrote:
> 
> It is certainly conceivable that validity through a period could be
> important to know in some circumstances.  I wonder, however, if the
> complexity of such a dialogue requires more effort than is justified
> by the reward.
> 
> Let us consider how this might be handled in the world of manual
> signatures.  When a purchase officer at Bloomingdale's sends a
> manually signed P.O. to Lee's Shirts let us assume that an
> acknowledgement is immediately sent out.  After a lapse of time (to
> build to order) the 5,000 pink shirts that were ordered are ready to
> be shipped.  The PO is being referenced to make sure that the goods
> being dispatched are consistent with the PO.  Would Lee's shirts want
> to confirm that the purchase officer is still at Bloomingdale's and
> that signature is still valid?  I suspect not.  But then for whatever
> application you are considering it may be necessary.  If so...
> 
> How does one automate the decision of a relying party when it gets the
> answer to the question, "was this certificate good in this interval?"
> It is a potentially burdensome to process the answer in an automated
> fashion.  The answer could be:
> 
> a.) that the certificate was suspended from time tx to ty, where t1 <=
> tx <= ty <= t2, or
> b.) that the certificate was revoked at tx, where t1 <= tx <= t2, or
> c.) that the certificate expired at tx, where t1 <= tx <= t2
> 
> If (a), is it important to know why the certificate was suspended?
> Does it matter if ty is in fact equal to t2 or equal to the expiry
> date of the certificate.  It could be that the person was on
> administrative leave until the certificate expired after which he/she
> was fired.
> 
> If (b) or (c), what would the relying party do?
> 
> Furthermore, this requires that the CA maintain in an online database
> every state transition and that the OCSP responder process this
> information before responding.  This also makes it challenging to now
> have a set of distributed OCSP responders because you have to
> distribute/replicate the database.
> 
> The biggest obstacle, I think, is that the logic to process such
> responses at a relying party is likely to require much more decision
> making logic and other input than is realistically going to be
> provided to most applications.
> 
> None of the foregoing is to say that the requirement is not legitimate
> or such capability is not needed or even important.  I am just
> wondering if current realities warrant that we settle for something
> more modest.  i.e. the ability have a dialogue like
> 
> Questions.) "Is the certificate good now?" or, "Was the certificate
> good at time t?"
> 
> Answers.) "Yes" or "No" or "Don't know."
> 
> This would still require maintenance of detailed state transition
> information at the CA/VA end but at least the relying party doesn't
> have very complex decision making logic to go through.
> 
> 
> 
> Khaja
> 
> -----Original Message-----
> From: Covey Carlin-P21262 [mailto:[e-mail]]
> Sent: Thursday, August 31, 2000 5:14 PM
> To: 'Khaja Ahmed'; 'Karl Scheibelhofer'; Peter Sylvester;
> [e-mail]; [e-mail]
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> I agree that some communities may want to know that the signature
> certificate was valid at the
> time that data was signed.  However, many communities might also want
> to
> know that no event
> has occurred later that would cast doubt on the validity of the
> signature.
> For instance, the subject
> of the signature certificate might have belatedly discovered that his
> private key had been compromised.
> It seems inconvenient to send two OSCP requests, one asking "was this
> certificate good in this interval?"
> and a second asking "is this certificate good (but perhaps now
> expired) at
> the current time?"  It seems
> like an mechanism that purports to answer the first question is
> obligated to
> implicitly answer the second.
> 
> -----Original Message-----
> From: Khaja Ahmed [mailto:[e-mail]]
> Sent: Thursday, August 31, 2000 4:27 PM
> To: 'Karl Scheibelhofer'; Peter Sylvester; [e-mail];
> [e-mail]
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> Under some circumstances or for some communities it may be possible
> for the
> sender of the signed data to send along with the signed data proof
> that at
> the time of signing (+/- some tolerance limit) the certificate was not
> 
> revoked. In other words, the sender could get an ocsp response from a
> common
> trusted responder and include this with the transmission of the signed
> data.
> This approach offers the advantage that the response can be archived /
> 
> stored along with the signature.  At a later date when the archived /
> stored
> signed data and signature is retrieved it can be readily verified as
> having
> been valid at creation time (+/- tolerance limit).
> 
> Is this not an ability that we should formalize and add to appropriate
> 
> protocols like OCSP?
> 
> Khaja
> 
> -----Original Message-----
> From: Karl Scheibelhofer [ mailto:[e-mail]
> <mailto:[e-mail]> ]
> Sent: Thursday, August 31, 2000 6:26 AM
> To: Peter Sylvester; [e-mail]; [e-mail]
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> > -----Original Message-----
> > From: Peter Sylvester [ mailto:[e-mail]
> <mailto:[e-mail]> ]
> > Sent: Thursday, August 31, 2000 2:27 PM
> > To: [e-mail]; [e-mail];
> [e-mail]
> > Subject: RE: RFC 2560 - OCSP - Clarification
> >
> >
> > >
> > > the current status of a certificate is very often not so
> > important. when i
> > > verify a signature that was created using a specific
> > certificate, i want to
> > > know, if the certificate was vaild, when the signature was
> created. to
> > > detemine the time the signature was created, one would ideally use
> 
> > > timestamps. using timestamps, it is possible to determine the
> signature
> > > creation time to be in an intervall [t1,t2]. here t1 and t2 are
> > the times of
> > > two timestamp (taking time base errors into consideration).
> > > what i would like to see in OCSP is a request with the
> > following meaning:
> > > "what was the state of certificate XYZ in the time interval
> [t1,t2]?"
> >
> > I do not think that you really want to ask this question, see below.
> 
> i do not simply want, in fact i must(!) have a answer to this question
> to
> decide whether the signature is valid. for me a certificate status
> service
> it is the most obvious place to get the answer for this question.
> 
> > > the answers could be:
> > > 1) the state of certificate XYZ was A (e.g. valid, suspended,
> > revoked,...)
> > > throughout the time intervall [t1,t2]
> > > 3) certificate XYZ changed its state from state A (e.g. valid)
> > to state B
> > > (e.g. suspended) at tx, where t1 <= tx <= t2
> > >
> > > if i get the first answer with 'valid', i can definitely say:
> > "the signature
> > > it was used for is valid".
> > > moreover, this request-response supports any history model for
> > certificate.
> > > by now OCSP assumes that a certificate can never become valid
> > again once it
> > > became invalid.
> > Hm,
> >
> > If a certificate was 'invalid' (suspended) and if it becomes
> > valid later, then
> > why would you want to get a 'suspended' status?
> 
> simply to temporarily take away the rigths that a valid certificate
> brings
> with for a entity. consider a employee gets suspended for any reason,
> the
> company may not want to revoke the certificate before the reason for
> this
> suspension have been verified. and if the company finds out that the
> reason
> is unjustified, it may want to make the certificate valid again.
> during the
> period the employee is suspended, the company may not want him do any
> business.
> 
> > If it becomes definetely revoked, you get a bad answer,
> > if the the current status is still 'pending', you get that.
> > And for those cases you get a date, so you can compare.
> >
> > It is assumed that either by using a cut-off date or by external
> knowledge
> 
> > you know that for which time frame you get an answer.
> 
> collecting facts from serveral sources to get an answer is what i want
> to
> avoid. i would like to have a single point where is get a definitive
> answer
> to the question stated above. by now i have to do serveral parts of
> this
> processing at the client side. i think the server side would be the
> better
> place for this.
> 
> > If you want to have more detailed information about the history, you
> can
> > also require that the signer, a cosigner, a notary, or whoever you
> want,
> > produce an OCSP response near the moment of the signature and add
> > this to the document, or you other protocols to enable validity
> checking
> > of the document.
> 
> if you sign a lot of documents and always attach all necessary
> verification
> data, you produce a lot of redundant information. this can be avoided
> and i
> think this should be avoided.
> nevertheless it works.
> 
> > I am not talking about the effects of a CA key compromise that might
> allow
> 
> > you to create 'good' responses for a non-existing cert, and then
> > you estimate
> > to be able to fake one in the future.
> 
> i also do not consider a CA key compromise here.
> 
> > > of course, implementing this based on CRLs will be hard, but if
> > the server
> > > has access to the history of the certificates, it should not be
> > a big deal.
> > >
> > > what do you and others think of this requirement for future OCSP
> > Some general thoughts:
> >
> > So far, OCSP without extensions has been made in such a way that you
> can
> > create a conforming implementation if you have a repository of CRLs.
> 
> yes i know about this requirement for supporting CRLs. but this is a
> implementation issue.
> for me as a developer of a signature/verification terminal software my
> 
> stated question is the one that i need an answer for.
> 
> > As far as I remember all requests to give different answers are
> handled by
> 
> > the magic 'do it by an extension'. OCSP adds an archive-cut off
> extension
> > for example, this seems to me a simple thing to support, knowing the
> 
> > the history of the CRLs that you have isn't that difficult.
> 
> just getting my idea in there in any non-standard extension is not a
> very
> disirable solution. because if i am the only one supporting it, it is
> not
> better than any ad-hoc protocol.
> i posted my idea here to hear the opinion of other people that use
> OCSP.
> 
> regards
> 
>   Karl Scheibelhofer
> 
> --
> 
> Karl Scheibelhofer, < mailto:[e-mail]
> <mailto:[e-mail]> >
> Institute for Applied Information Processing and Communications (IAIK)
> 
> at Technical University of Graz, Austria, http://www.iaik.at
> <http://www.iaik.at>
> Phone: (+43) [phone]

-- 
=======================================================
Bruno Salgueiro       (mailto:[e-mail])
                   
Grupo de Trabalho de Certificação Digital
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

This message was digitally signed with a MULTICERT cer-
tificate to give an identity assurance. In order to
download the root MULTICERT certificate please go to :
             http://www.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================
--------------msB74902A285C097E5CA1C1E2A
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

MIIFjwYJKoZIhvcNAQcCoIIFgDCCBXwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
A80wggPJMIIDMqADAgECAgQ3TuB5MA0GCSqGSIb3DQEBBQUAMCgxCzAJBgNVBAYTAlBUMRkw
FwYDVQQKExBQSUxPVE8gTVVMVEljZXJ0MB4XDTAwMDYyNjExMDM0MVoXDTAxMDYyNjExMzM0
MVowYDELMAkGA1UEBhMCUFQxGTAXBgNVBAoTEFBJTE9UTyBNVUxUSWNlcnQxDTALBgNVBAsT
BFNJQlMxDTALBgNVBAsTBEdUQ0QxGDAWBgNVBAMTD0JydW5vIFNhbGd1ZWlybzCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA3qTimm/D/EzITGUcMQMaTxFpO1EvnQVN9te/6aGOz0B0
erA5D23/GZ8zd2WRefZoIjBBgZiYK90b1y7bcAbDp06iVhZcN6HtBfQvlgYij9q2+zBkfCG4
bmNQKsJK2RxGCd/YbJ2XeYU0n/A6SAmPOLX3+aPIjpAx2O+SYzqKdfkCAwEAAaOCAcYwggHC
MAsGA1UdDwQEAwIFoDArBgNVHRAEJDAigA8yMDAwMDYyNjExMzM0MVqBDzIwMDEwMzA4MjMz
MzQxWjARBglghkgBhvhCAQEEBAMCBaAwgakGCWCGSAGG+EIBDQSBmxaBmENlcnRpZmljYWRv
IFBJTE9UTyBNVUxUSWNlcnQuIEVzdGVzIGNlcnRpZmljYWRvcyBzYW8gZW1pdGlkb3MgYW8g
YWJyaWdvIGRvIENQUyBxdWUgc2UgZW5jb250cmEgbm8gc2VndWludGUgVVJMIC0gaHR0cHM6
Ly93d3cuc2licy5tdWx0aWNlcnQuY29tL2Nwcy5odG1sMBUGA1UdEQQOMAyBCmJzQHNpYnMu
cHQwSgYDVR0fBEMwQTA/oD2gO6Q5MDcxCzAJBgNVBAYTAlBUMRkwFwYDVQQKExBQSUxPVE8g
TVVMVEljZXJ0MQ0wCwYDVQQDEwRDUkwxMB8GA1UdIwQYMBaAFLiWIG3WTfGiSQxdd4FPSyQI
oi/lMB0GA1UdDgQWBBSNxWQEKMGcvdwOWLszw/uocQ+4NjAJBgNVHRMEAjAAMBkGCSqGSIb2
fQdBAAQMMAobBFY0LjADAgOoMA0GCSqGSIb3DQEBBQUAA4GBAGicAO4sFZ2fO7bR5ANwp9zQ
6EiIcmU+AbNCKGuK5tHQE3HPDRpoUPtjLRmVMhnxKtfBUVClZ6lxYdONh3TpHiEYex1bKOlg
h7fVHXprtEz1vKpl//afvGCHaocfDrNEtmLfarSKCx3vETSLiEiDOMjL+3QCx82kSiJeG+3f
wjQ7MYIBijCCAYYCAQEwMDAoMQswCQYDVQQGEwJQVDEZMBcGA1UEChMQUElMT1RPIE1VTFRJ
Y2VydAIEN07geTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTAwMDkwMTExMjUzNFowIwYJKoZIhvcNAQkEMRYEFIlIcX8numJkjAaS
7a/N5++IdcEAMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA
BIGADnjLmSPpxgvdhMw/NEsNrRZpyjo8Is+bTbmD9ngwNbaYX1NVC0Behp1pJI78JdjaGX/f
uAFBkKlr+a2bhCF+6u1Gig/8WEV1+Y3WsaYhtJ8LJIcLeX2mNMS0L0n6M+5IwyPH8wO1lMc2
KiTjpSaZdP7+8jGiHqvWpq/6hPLvwg4=
--------------msB74902A285C097E5CA1C1E2A--