RE: IETF and ISO alignment on Time Stamping

["pat cain" <[e-mail]>]

Roland,
Since I'm only one of the four authors of the time-stamp draft you may get
different responses from the other authors, but here's my cut:  (portions
that I am not replying to were snipped out)

> -----Original Message-----
> From: Roland Mueller [mailto:[e-mail]]
> Sent: Wednesday, January 26, 2000 2:52 PM
> To: IETF-PKIX
> Cc: Zuccherato, Robert; Manas, Jose A.; Matyas, Mike; Quisquater,
> Jean-Jaques; Haber, Stuart; Doonan, Wes; Lai, Xuejia; Chawrun, Mike
> Subject: IETF and ISO alignment on Time Stamping
>
> I write to the PKIX working group as the editor of the ISO working draft
> on time stamping. ISO SC27 has begun work on an International Standard
> on time stamping (ISO Working Draft 18014) in 1998.  The ISO SC27 WG2
> adhoc group on time stamping met recently and discussed the differences
...

pc> I always worry when an "ad hoc" group sends in comments....

>
> IETF - ISO Interoperability
> ---------------------------
> Detail
> ------
>
> 1. TimeStampReq, TSTInfo
>
> The ISO has adjusted its timestamp request message and timestamp info
> structures to be compatible with the corresponding IETF structures,
> with the addition of a single "mechanism" field.  This field
> identifies which mechanism is used to form the timestamp token, either
> the IETF mechanism or any of the proposed ISO mechanisms.  In the IETF
> standard, only the IETF mechanism would need be recognized.  The field
> contains an OID identifying the timestamping mechanism, and is added
> to the structures as follows:
>
> MechanismIdentifier ::= OBJECT IDENTIFIER
>
> TimeStampReq ::= SEQUENCE {
> 	...
> 	messageImprint	MessageImprint,
> 	mechanism	MechanismIdentifier,  -- addition
> 	...
> }
>
> TSTInfo ::= SEQUENCE {
> 	...
> 	policy		PolicyInformtion,
> 	mechanism 	MechanismIdentifier,  -- addition
> 	...
> }
>
> An OID would also be allocated for use in identifying the IETF
> mechanism.
>

pc> The current messageImprint object is an AlgorithmIdentifier followed by
a value. The messageImprint object is included within the TimeStampReq and
the TimeInfo. In many cases we expect that this will be a hash-OID followed
by a hash value. In some cases it may be a cryptographically different
combination (we may have erred in the use of the word hash, but it's only an
identifier so anything we pick will be wrong to someone). I expect that you
would use the existing AlgorithmIdentifier to state your "mechanism", no? We
spent a good chunk of time trying not to cryptographically specify how one
would have to "timestamp" as we all expect that the mechanisms used to
securely perform the "stamping" will change over time. (And some of the good
mechanisms are patented/encumbered.)

> 2. PKIFailureInfo
>
> If the TSA does not support the requested mechanism it returns an
> error code in the "status" field of the TimeStampResp message.  A new
> error code is added to PKIFailureInfo to support this, as follows:
>
> PKIFailureInfo ::= BITSTRING {
> 	...
> 	mechanismNotSupported (18),  -- addition
> 	-- the TSA does not support the requested mechanism.
> }
>

pc> I was expecting the use of "0 {Bad Alg}" myself. Maybe we should make
this more clear.

> 3. TimeStampToken
>
> The ISO has modified its timestamp token structure to interoperate
> with the IETF token, with an adjustment to the specified
> encapsulation.  The ISO supports alternate token encapsulations and
> hence defines the token more abstractly.  The IETF mechanism will
> continue to use the specified SignedData construct [CMS], encoded as
> an external signature (RFC 2630 pp. 9) in the signatureInfo field
> below:
>
> TSTSignature ::= OCTET STRING
>
> TimeStampToken ::= SEQUENCE {
>         tokenInfo       TSTInfo,
>         signatureInfo   TSTSignature OPTIONAL  -- SignedData,
> DER-encoded as
>                                                -- external signature
> }
>
> The signature is computed on the TSTInfo structure as before, and the
> signature data is inserted in a SignedData construct.  The construct
> is then encoded in the signatureInfo field as an external signature
> (RFC 2630, pp. 9).  The existing content type identifier is retained.
>

pc> I'm lost on two points, here. 1. Although we currently require the use
of a CMS object as the TimeStampToken, we have not seen any requests for
other formats* in the three years of development of the draft. ( *= we
debated the CMP vs CMS encapsulation at one point). At this late stage I'm
not interested in adding a new format unless a specific problem is
identified. The IETF historically has not left a hole to be filled in later,
as this wrecks interoperability.
2. If the ISO and the IETF standards are expecting to interoperate totally,
why do we need the ISO one?

Pat




Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08307 for <[e-mail]>; Mon, 31 Jan 2000 21:53:24 -0800 (PST)
Received: from cbljrtorrent (CBL-jrtorrent.hs.earthlink.net [208.233.117.109]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id VAA23306; Mon, 31 Jan 2000 21:55:35 -0800 (PST)
Message-ID: <007601bf6c78$e0c2c780$[e-mail]>
Reply-To: "Juan Rodriguez-Torrent" <[e-mail]>
From: "Juan Rodriguez-Torrent" <[e-mail]>
To: <[e-mail]>, "Russ Housley" <[e-mail]>
References: <[e-mail]>
Subject: Re: OCSP and CSL
Date: Tue, 1 Feb 2000 00:54:57 -0500
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

Russ, I cannot agree more. I'm just trying to figure out if these are real
customer requirements or some folks in a glass house tinkering with
possibilities.

JRT
----- Original Message -----
From: Russ Housley <[e-mail]>
To: <[e-mail]>
Sent: Monday, January 31, 2000 11:22 AM
Subject: RE: OCSP and CSL


>
>  >>>I cannot find my smartcard... I suppose I left it at my friend's
>  >>>house, but I am not sure... So I ask for a suspesion of the service.
>  >>>Then I go to my friend's house and I find my smartcard... so the
>  >>> certificate have never been in danger, I can ask the
>  >>>CA Org not to revoke it and from the suspended state it returns to the
>  >L> lid state.
>  >>
>  >> Revoking certificates and reissue sounds like an excellent solution to
>  >> is problem. The encryption key can be rolled over in the re-issued
card,
>  >> miniting new signing keys is never a problem.
>  >>
>  >> I don't think that the change of the cert status back to
>  >> valid has much hope of being acurately and reliably tracked.
>  >> Re-certificatrion is a slam dunk.
>  >
>  >I don't quite agree. Reissuing a certificate for a smart card will
always be
>  >more of hassle than suspending/unsuspending. Not so much for the CA, but
for
>  >the user who needs to put his card into a reader capable of updating the
>  >certificate on the smart card (assuming that the certificate is stored
>  >together with the keys). Given that suspension/unsuspensions usually are
>  >requested over phone, I don't think people would be happy with this.
>
> I cannot agree.  The use of suspend adds considerable complexity to both
> the infrastructure and the relying parties, regardless of the revocation
> mechanism used (OCSP, CRLs, whatever).  The provision of non-repudiation
is
> also made much more complex.
>
> If a user forgets their smartcard at a friends house, then the
PIN/password
> for that smartcard should prevent misuse.  If the user stored her
> PIN/password with the smartcard, then the certificate should be revoke
> permanently.
>
> Russ
>




Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07960 for <[e-mail]>; Mon, 31 Jan 2000 21:46:40 -0800 (PST)
Received: from cbljrtorrent (CBL-jrtorrent.hs.earthlink.net [208.233.117.109]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id VAA11290; Mon, 31 Jan 2000 21:48:43 -0800 (PST)
Message-ID: <006901bf6c77$ebe93320$[e-mail]>
Reply-To: "Juan Rodriguez-Torrent" <[e-mail]>
From: "Juan Rodriguez-Torrent" <[e-mail]>
To: "Antonio Lioy" <[e-mail]>, <[e-mail]>
Cc: "'Massimiliano Pala'" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: OCSP and CSL
Date: Tue, 1 Feb 2000 00:48:06 -0500
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

So on Friday I "suspend" my cert ... how do I do that? signing with the cert
I want to suspend? calling a help desk ($$)? ... and then on Monday how do I
activate my cert? Another phone call ($$)? signing a request with the
suspended cert? Oh! I forgot the one time token! But who would trust that
"one time token" left on an insecure office next to the vacationing certs? I
claim it would have no trust associated... unless I carry it with me and
then why not carry the original cert that I'm trying to suspend and avoid
all the hassle? Maybe I should get an additional cert so I can suspend and
activate the one cert I want to leave in my office during the weekend? Does
any of this makes any business sense?

The smart card example is another example on how we are so desperately
trying to change business processes that actually work. Does anyone leave
their passport, driver license, credit card or checkbook in and untrusted
area for a weekend?

Have you considered the costs of involved in this "let's give our certs the
week-end off"? In a large office hiring certsitting personnel could be much
cheaper than all those convoluted motions I see proposed for trivial
reasons. No one in their right state of mind leaves the ATM card, credit
card or any financial relevant document seating in an insecure office over
the weekend for the pleasure of it.


WOW!

----- Original Message -----
From: Antonio Lioy <[e-mail]>
To: <[e-mail]>
Cc: 'Massimiliano Pala' <[e-mail]>
Sent: Thursday, January 27, 2000 12:32 PM
Subject: Re: OCSP and CSL


> I think that CSL is a real need in several cases and that it
> cannot be easily substituted with CRL or OCSP.
>
> First of all OCSP is out of question is it is not a trust
> source but rather a delivery channel for fast trust
> information. For non-repudiation service, it needs to be
> backed up by long-term data such as those of a CRL.
>
> CRL is not good either due to revokation costs, that are
> among the highest ones in the PKI world. So I would like to
> minimize the number of revokations, especially if followed
> by a re-issue of the same certificate with a different key
> pair (especially difficult to work with those remote friends
> that have stored remotely my cert to send me encrypted
> e-mail while off-line)
>
> Finally, I'd like to give my users the autonomous ability to
> suspend and then re-activate their certificates. Let's
> imagine the following scenario:
> - I don't want to take my smart-card with me and I leave it
> at the office (or I use a software PSE installed on my PC at
> work)
> - as I don't trust the company in charge of cleaning up the
> office (or may be my co-workers), I'd like to suspend the
> cert validity during week-ends, vacation, or even during
> night hours
> - I'd like to do this by just clicking on a button on a
> secure Web page (with client authentication) or sending a
> signed S/MIME message to an automatic responder
> - the responder (or the Web server) could in turn provide me
> with a one-time token to re-activate the cert at my will
>
> There are other similar scenarios (like I forgot where I put
> my smart-card, and later I find it) where I don't want to
> have the burden of revoking and reissuing certs.
>
> So I'd like to see this scenario supported by the following
> technical details:
> - a status code returned by an OCSP server to tell that a
> cert is SUSPENDED
> - a long term memory that a cert was suspended during a
> certain period of time; this should be provided by a CSL,
> which closely resembles the format (but not the meaning) of
> a CRL
>
> Opinions?
>
> Antonio Lioy




Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA04775 for <[e-mail]>; Mon, 31 Jan 2000 21:00:52 -0800 (PST)
Received: from cbljrtorrent (CBL-jrtorrent.hs.earthlink.net [208.233.117.109]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id VAA09022; Mon, 31 Jan 2000 21:01:38 -0800 (PST)
Message-ID: <003101bf6c71$61a571c0$[e-mail]>
Reply-To: "Juan Rodriguez-Torrent" <[e-mail]>
From: "Juan Rodriguez-Torrent" <[e-mail]>
To: "Ben Laurie" <[e-mail]>, "Brian Ford" <[e-mail]>
Cc: "Massimiliano Pala" <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>
References: <[e-mail]><v04220806b4b3c9cb3dd3@[128.33.238.94]><[e-mail]> <[e-mail]>
Subject: Re: OCSP and CSL
Date: Tue, 1 Feb 2000 00:01:07 -0500
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

In this case I interpret your "suspend" as the relying party will stop
accepting certs until the he/she can verify the certs for that specific CA.
This is far from Massimo's inquiry.
----- Original Message -----
From: Brian Ford <[e-mail]>
To: Ben Laurie <[e-mail]>
Cc: Massimiliano Pala <[e-mail]>; Stephen Kent
<[e-mail]>; <[e-mail]>
Sent: Wednesday, January 26, 2000 1:19 PM
Subject: Re: OCSP and CSL


> Ben,
>
> It comes down to your interpretation of suspend versus revoke.  If the
> network between a client and the CA goes bad and you cannot reach a CA for
> a period of time an argument could be made to "suspend" certs from that
CA.
>  If the user leaves the employ of a company one would hope that their cert
> would be "revoked".  No?
>
> Regards,
>
> Brian
>
> At 05:27 PM 01/26/00, Ben Laurie wrote:
> >Massimiliano Pala wrote:
> >>
> >> Stephen Kent wrote:
> >> >
> >> > Massimiliano,
> >> >
> >> > Would not a CRL DP that holds only suspended certs achieve the effect
> >> > you attribute to a CSL?
> >> >
> >> > Steve
> >>
> >> Yes, I think this is what we definetly need. What I was wondering is if
> >available
> >> software can disitinguish CSLs from CRLs ... As far as I know, actually
> >Netscape
> >> does not support CRLs with extentions. Am I wrong ???
> >>
> >> Do you know of some software supporting extentions in CRLs (widely
> >available) ???
> >>
> >> To issue a CRL, you'd need the CA certificate/key, but in environment
> >where you
> >> have (for security reasons) a network-less CA how to accomplish this
???
> >Can you
> >> sign CRLs with a certificate that is not the CA Cert ???
> >
> >Since a suspended certificate is as unusable as a revoked one, it makes
> >no sense to me to permit _any_ differences between the creation of a
> >suspension and the creation of a revocation. Which means that there's
> >little point in supporting suspension at all.
> >
> >Cheers,
> >
> >Ben.
> >
> >--
> >SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
> >
> >http://www.apache-ssl.org/ben.html
> >
> >Y19100 no-prize winner!
> >http://www.ntk.net/index.cgi?back=2000/now0121.txt
> >
>
>
> Brian Ford
> Consulting Engineer, CCIE #2106
> Cisco Systems Inc.
>
>




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 PAA21661 for <[e-mail]>; Mon, 31 Jan 2000 15:23:41 -0800 (PST)
Received: from pcain (burl-dhcp151-228.bbn.com [171.78.151.228]) by po1.bbn.com (8.9.1/8.9.1) with SMTP id SAA08254; Mon, 31 Jan 2000 18:25:37 -0500 (EST)
From: "pat cain" <[e-mail]>
To: "Roland Mueller" <[e-mail]>, "IETF-PKIX" <[e-mail]>
Cc: "Zuccherato, Robert" <[e-mail]>, "Manas, Jose A." <[e-mail]>, "Matyas, Mike" <[e-mail]>, "Quisquater, Jean-Jaques" <[e-mail]>, "Haber, Stuart" <[e-mail]>, "Doonan, Wes" <[e-mail]>, "Lai, Xuejia" <[e-mail]>, "Chawrun, Mike" <[e-mail]>
Subject: RE: IETF and ISO alignment on Time Stamping
Date: Mon, 31 Jan 2000 18:24:34 -0500
Message-ID: <000001bf6c42$552d0b80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Roland,
Since I'm only one of the four authors of the time-stamp draft you may get
different responses from the other authors, but here's my cut:  (portions
that I am not replying to were snipped out)

> -----Original Message-----
> From: Roland Mueller [mailto:[e-mail]]
> Sent: Wednesday, January 26, 2000 2:52 PM
> To: IETF-PKIX
> Cc: Zuccherato, Robert; Manas, Jose A.; Matyas, Mike; Quisquater,
> Jean-Jaques; Haber, Stuart; Doonan, Wes; Lai, Xuejia; Chawrun, Mike
> Subject: IETF and ISO alignment on Time Stamping
>
> I write to the PKIX working group as the editor of the ISO working draft
> on time stamping. ISO SC27 has begun work on an International Standard
> on time stamping (ISO Working Draft 18014) in 1998.  The ISO SC27 WG2
> adhoc group on time stamping met recently and discussed the differences
...

pc> I always worry when an "ad hoc" group sends in comments....

>
> IETF - ISO Interoperability
> ---------------------------
> Detail
> ------
>
> 1. TimeStampReq, TSTInfo
>
> The ISO has adjusted its timestamp request message and timestamp info
> structures to be compatible with the corresponding IETF structures,
> with the addition of a single "mechanism" field.  This field
> identifies which mechanism is used to form the timestamp token, either
> the IETF mechanism or any of the proposed ISO mechanisms.  In the IETF
> standard, only the IETF mechanism would need be recognized.  The field
> contains an OID identifying the timestamping mechanism, and is added
> to the structures as follows:
>
> MechanismIdentifier ::= OBJECT IDENTIFIER
>
> TimeStampReq ::= SEQUENCE {
> 	...
> 	messageImprint	MessageImprint,
> 	mechanism	MechanismIdentifier,  -- addition
> 	...
> }
>
> TSTInfo ::= SEQUENCE {
> 	...
> 	policy		PolicyInformtion,
> 	mechanism 	MechanismIdentifier,  -- addition
> 	...
> }
>
> An OID would also be allocated for use in identifying the IETF
> mechanism.
>

pc> The current messageImprint object is an AlgorithmIdentifier followed by
a value. The messageImprint object is included within the TimeStampReq and
the TimeInfo. In many cases we expect that this will be a hash-OID followed
by a hash value. In some cases it may be a cryptographically different
combination (we may have erred in the use of the word hash, but it's only an
identifier so anything we pick will be wrong to someone). I expect that you
would use the existing AlgorithmIdentifier to state your "mechanism", no? We
spent a good chunk of time trying not to cryptographically specify how one
would have to "timestamp" as we all expect that the mechanisms used to
securely perform the "stamping" will change over time. (And some of the good
mechanisms are patented/encumbered.)

> 2. PKIFailureInfo
>
> If the TSA does not support the requested mechanism it returns an
> error code in the "status" field of the TimeStampResp message.  A new
> error code is added to PKIFailureInfo to support this, as follows:
>
> PKIFailureInfo ::= BITSTRING {
> 	...
> 	mechanismNotSupported (18),  -- addition
> 	-- the TSA does not support the requested mechanism.
> }
>

pc> I was expecting the use of "0 {Bad Alg}" myself. Maybe we should make
this more clear.

> 3. TimeStampToken
>
> The ISO has modified its timestamp token structure to interoperate
> with the IETF token, with an adjustment to the specified
> encapsulation.  The ISO supports alternate token encapsulations and
> hence defines the token more abstractly.  The IETF mechanism will
> continue to use the specified SignedData construct [CMS], encoded as
> an external signature (RFC 2630 pp. 9) in the signatureInfo field
> below:
>
> TSTSignature ::= OCTET STRING
>
> TimeStampToken ::= SEQUENCE {
>         tokenInfo       TSTInfo,
>         signatureInfo   TSTSignature OPTIONAL  -- SignedData,
> DER-encoded as
>                                                -- external signature
> }
>
> The signature is computed on the TSTInfo structure as before, and the
> signature data is inserted in a SignedData construct.  The construct
> is then encoded in the signatureInfo field as an external signature
> (RFC 2630, pp. 9).  The existing content type identifier is retained.
>

pc> I'm lost on two points, here. 1. Although we currently require the use
of a CMS object as the TimeStampToken, we have not seen any requests for
other formats* in the three years of development of the draft. ( *= we
debated the CMP vs CMS encapsulation at one point). At this late stage I'm
not interested in adding a new format unless a specific problem is
identified. The IETF historically has not left a hole to be filled in later,
as this wrecks interoperability.
2. If the ISO and the IETF standards are expecting to interoperate totally,
why do we need the ISO one?

Pat



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 NAA20082 for <[e-mail]>; Mon, 31 Jan 2000 13:33:38 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (rhousley-pc.spyrus.com [207.212.34.221]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id NAA06761 for <[e-mail]>; Mon, 31 Jan 2000 13:31:59 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 31 Jan 2000 11:22:57 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: OCSP and CSL
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

 >>>I cannot find my smartcard... I suppose I left it at my friend's
 >>>house, but I am not sure... So I ask for a suspesion of the service.
 >>>Then I go to my friend's house and I find my smartcard... so the
 >>> certificate have never been in danger, I can ask the
 >>>CA Org not to revoke it and from the suspended state it returns to the
 >L> lid state.
 >>
 >> Revoking certificates and reissue sounds like an excellent solution to
 >> is problem. The encryption key can be rolled over in the re-issued card,
 >> miniting new signing keys is never a problem.
 >>
 >> I don't think that the change of the cert status back to
 >> valid has much hope of being acurately and reliably tracked.
 >> Re-certificatrion is a slam dunk.
 >
 >I don't quite agree. Reissuing a certificate for a smart card will always be
 >more of hassle than suspending/unsuspending. Not so much for the CA, but for
 >the user who needs to put his card into a reader capable of updating the
 >certificate on the smart card (assuming that the certificate is stored
 >together with the keys). Given that suspension/unsuspensions usually are
 >requested over phone, I don't think people would be happy with this.

I cannot agree.  The use of suspend adds considerable complexity to both 
the infrastructure and the relying parties, regardless of the revocation 
mechanism used (OCSP, CRLs, whatever).  The provision of non-repudiation is 
also made much more complex.

If a user forgets their smartcard at a friends house, then the PIN/password 
for that smartcard should prevent misuse.  If the user stored her 
PIN/password with the smartcard, then the certificate should be revoke 
permanently.

Russ


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 MAA19221 for <[e-mail]>; Mon, 31 Jan 2000 12:55:02 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Jan 2000 20:54:28 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA11866 for <[e-mail]>; Mon, 31 Jan 2000 15:55:47 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id <D6374V6A>; Mon, 31 Jan 2000 15:58:32 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Date: Mon, 31 Jan 2000 16:05:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

I've a few comments on this specification.

If different entities obtain timestamps on the same data object using the
same hash algorithm, or a single entity obtains multiple timestamps on the
same object, the generated timestamp tokens will include identical message
imprints; as a result, an observer could determine that the timestamps refer
to the same underlying data.  It might be worth a note in Security
Considerations stating that, in contexts where this potential exposure is a
concern, some unique value could be generated by the requester and combined
with a data object before hashing the combination in order to produce
MessageImprint's hashedMessage. 

The second paragraph of Sec. 2.2 bears a number of SHALLs for verification
steps which are to be performed by the requesting entity once the
TimeStampToken is received.  What's the recommended or required action if
any of these verifications fail? 

In the Accuracy structure, is no more than one of the seconds, millis, or
micros OPTIONALs to occur, or may more than one of these elements occur in
combination? 

In References, [ESS] is now RFC-2634.

Editorially, there's an odd character which seems to recur instead of the
apostrophe in the phrase "TSA's", and in other places where an apostrophe or
closing single quote is intended; on my display, it appears as a ligature
"AE".

Other, minor editorial points:

p. 8, 1st line, "may to be used" -> "may be used".

Later on p. 8, "subtracting the accuracy to" -> "subtracting the accuracy
from". 

Appendix A, 4th line, "allows to know" -> "allows a verifier to know".

--jl


Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12550; Mon, 31 Jan 2000 06:49:00 -0800 (PST)
Date: Mon, 31 Jan 2000 06:49:00 -0800 (PST)
From: [e-mail]
Message-Id: <[e-mail]>


Received: from hpheger0.nm.informatik.uni-muenchen.de ([e-mail] [129.187.214.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12145 for <[e-mail]>; Mon, 31 Jan 2000 06:36:26 -0800 (PST)
Received: from hpheger3.nm.informatik.uni-muenchen.de ([e-mail] [129.187.214.23]) by hpheger0.nm.informatik.uni-muenchen.de (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id PAA29376; Mon, 31 Jan 2000 15:34:41 +0100 (MET)
Date: Mon, 31 Jan 2000 15:34:41 +0100 (MET)
From: Gerald Vogt <[e-mail]>
Reply-To: [e-mail]
To: Undisclosed recipients: ;
Subject: USM 2000 Submission deadline extended
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

USM 2000: DEADLINE EXTENDED

3rd IFIP/GI International Conference on
Trends towards a Universal Service Market

Munich, Germany
September 12-14, 2000 

After we received several requests to extend the deadline for submissions
to the USM 2000 conference, we offically announce that the new deadline
for submissions is Monday, February 14, 2000. Papers are to be submitted
on http://usm2000.informatik.uni-muenchen.de/submission.shtml 
There you will find all necessary information. We would like to ask all
authors that intend to submit a paper to USM 2000 to register their paper
as soon as possible for organisational purposes. Afterwards you can upload
your paper until the new deadline, February 14.

We are looking forward to your submissions.


Regards,

USM 2000 Organisation Committee

[e-mail]
http://usm2000.informatik.uni-muenchen.de









Received: from webserver.gloclub2.net ([206.104.28.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10920; Mon, 31 Jan 2000 05:25:41 -0800 (PST)
Received: from 206.104.28.4 [171.211.231.234] by webserver.gloclub2.net (SMTPD32-5.01) id A9C267E01C6; Sun, 30 Jan 2000 23:12:34 CST
Received: from [e-mail] by [e-mail] (8.8.5/8.6.5) with SMTP id GAA04152 for <[e-mail]>; Sun, 30 Jan 2000 21:54:09 -0600 (EST)
Date: Sun, 30 Jan 00 21:54:09 EST
From: [e-mail]
To: [e-mail]
Subject:  New USA and INTERNATIONAL Merchant Accounts
Message-ID: <>
Reply-To: [e-mail]
Comments: Authenticated sender is <[e-mail]>

NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW
U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD.

Click below to Apply
http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D

ARE YOU REALLY AN E-COMMERCE MERCHANT?
Increase your revenues by up to 1500% by accepting credit cards and
electronic
checks.
Increase your customer base 200- 400% with instant access to the World.

ARE YOU PAYING TOO MUCH?
Discount rates start at 2.1%
Transaction fees start at 25 cents.

DO YOU WAIT TOO LONG FOR YOUR MONEY?
Funds available in 24-48 hours anywhere in the world

DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS
99% of all applications are approved.

ARE YOU LIMITED BY WHAT YOU CAN ACCEPT?
Mastercard, Visa, Discover, Amex and Checks (USA checks only)
All cards from ALL COUNTRIES - Including Eastern Europe and Asia

- - - - - - - - - -
-
Click HERE to APPLY.

http://angelfire.com@3462929566/%74%68%65%73%65%72%76%69%63%65%34%38/%64%65%66%61%75%6C%74.%68%74m#@3626198025/%74%68%65%73%65%72%76%69c%65%348/de%66a%75l%74.%68%74%6D


NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A
MERCHANT
ACCOUNT.

- - - - - - - - - -




-
 To be removed from our mailing list, call [phone] Clearly spell your
email address
and you will be removed.












***


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10570 for <[e-mail]>; Mon, 31 Jan 2000 05:18:03 -0800 (PST)
Received: from darmstadt.gmd.de (aberger@pc-venedig [141.12.33.63]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id OAA02700; Mon, 31 Jan 2000 14:18:49 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 31 Jan 2000 14:18:48 +0100
From: Andreas Berger <[e-mail]>
Organization: GMD SIT.SICA Darmstadt
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: German Law and OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ambarish Malpani wrote:
> 
> Hi Guys,
>     I recently read a document that seemed to indicate that
> the German Digital Signature Law or some related documents
> specified that you can use OCSP to check the revocation status
> of a cert, but they allowed you to send over all 0's as the
> hash of the CA's public key.

This is true. We introduced this option to enable the end-system to make
queries about certificates when the CA certificate is not (at least at
the point of this check) known. Therefore, we allowed to "omit" the CA
public key (resp. the hash) in the query. The hash is, of course,
required in the reply.

>     Does anybody know more about whether the statement above
> is true or not? If it is, I am concened that they might not be
> using OCSP correctly.

We had to extend the functionality (it was mid 1998 if I remember
correctly). OCSP supports (supported) only the CRL-like "CRL on-line"
design. We needed (as Hans has written)

1. Certificate was created, is in the service since T, and is not
revoked
2. Certificate was created, is in the service since T, and is revoked
3. Certificate is unknown

which was not possible with then the OCSP.

Andreas Berger
GMD Darmstadt
-- 
Keine Zeit haben wir genug!


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 FAA10506 for <[e-mail]>; Mon, 31 Jan 2000 05:16:43 -0800 (PST)
Received: from roger (JackRabbit.cost.se [195.100.88.69]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DXK25Y7R; Mon, 31 Jan 2000 05:25:26 -0800
Message-Id: <3.0.5.32.20000131141812.00c3a390@127.0.0.1>
X-Sender: martin@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 31 Jan 2000 14:18:12 +0100
To: Oliver Pfaff <[e-mail]>
From: Martin Lindström <[e-mail]>
Subject: Re: CRMF support
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

>I'm trying to get an overview on vendors/systems that support CRMF as
>certificate request format. According to a quick Internet search,
>Netscape (CMS - Certificate Management System) and Baltimore (UniCERT)
>are supporting CRMF. Are there other vendors/systems supporting CRMF?

Entegrity Solutions supports CRMF through its SDP platform. See
further www.entegrity.com.

/Martin Lindström

 
______________________________________
         Entegrity Solutions

  Martin Lindström
  Systems Designer 

  Finlandsgatan 60 
  S-164 74 Kista, Sweden
  Direct: [phone]
  Fax:    [phone]
  Cell:   [phone]
______________________________________



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 OAA14420 for <[e-mail]>; Sun, 30 Jan 2000 14:09:03 -0800 (PST)
Received: from cbljrtorrent (CBL-jrtorrent.hs.earthlink.net [208.233.117.109]) by scaup.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id OAA01499; Sun, 30 Jan 2000 14:10:40 -0800 (PST)
Message-ID: <001901bf6b6e$db9653e0$[e-mail]>
Reply-To: "Juan Rodriguez-Torrent" <[e-mail]>
From: "Juan Rodriguez-Torrent" <[e-mail]>
To: "Massimiliano Pala" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: OCSP and CSL
Date: Sun, 30 Jan 2000 17:10:40 -0500
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

Massimiliano, the issue of suspension was discussed several times during the
last few years and the bottom line is that nobody was able to show a
reasonable business case for it. In other words, there is not enough
interest in suspension mechanisms to generate income or help sales of a
specific PKI because of that feature. I'm sure the additional complexity
that Russ brings to our attention would be less of a deterrent if someone
was willing to make suspension mechanisms attractive to the vendors. Let's
not forget the ISVs (Independent Software Vendors) that have to add yet
another level of complexity to their products to enable suspension and they
also have to be convinced. Also, let's not forget the additional complexity
to be stated on the policies with the corresponding legal issues arising
from that added feature.  I could go on for a while on that subject but I
think you got my point.

Let me add that the reason you stated for having a certificate suspension
list is trivial and raises fundamental questions:

1. If the CA is offline WHO WOULD create the suspension list?

2. Since without a trusted authority a suspension list will be worthless,
why bother? It appears that the only reason for having a suspension list is
because the CA is offline and want to avoid bringing the CA online to issue
a CRL but the suspension lists needs to be issued by the CA ... (?)

3. Also why do you think that offline CAs are any different than CAs that
only issue CRLs at fixed time intervals (i.e. every 8 hours, every hour or
every minute). There will always be a time gap between CRL instances,
independently if the CA is online or not, and that's were policies -of
relaying parties, CAs, etc.- have a role.

If your environment needs a high level of responsiveness, a more reasonable
approach is to solve the problems you did not state (e.g. why the CA has to
be offline?) and bring your CA on-line using mechanisms and protocols
appropriate for the application. Trying to develop new protocols to solve an
apparently trivial environment/operations issue adds, as stated above,
complexity and also interoperability issues to an already complex and less
that interoperable environment.


Juan Rodriguez-Torrent
[e-mail]

"It is better to sleep on things beforehand than lie awake about them
afterwards." Baltasar Gracian



----- Original Message -----
From: Massimiliano Pala <[e-mail]>
To: Russ Housley <[e-mail]>
Sent: Tuesday, January 25, 2000 7:38 PM
Subject: Re: OCSP and CSL


> Russ Housley wrote:
> >
> > Massimiliano:
> >
> > I do not think that we should do anything to encourage CAs to suspend
> > certificates.  This feature adds significant complexity to the whole
> > system, and we should discourage it's use.
> >
> > Russ
> >
>
> You are right saying that adding complexity should be discouraged, by the
> way I suggested them because we need something like that (I am from the
> OpenCA project). Let me explain in more details why I think something
> similar could come in handy.
>
> The CSLs, let's call them CSL to distinguish from CRLs, have sense in env
> where there is a time gap between the 'request for cert revoking' by the
> user and the effective revoking by the CA: this is obvious if you consider
> structures where the main CA computer is disconnected from any network.
>
> Would you allow a certificate to be used when a user says it could have
> been compromised ? You can not either say it is revoked because it is not
> (CRLs do not report it) and there is no way to verify it till the new
> CRL is issued.
>
> With some instrument like the proposed CSLs (that is only a proposal, I am
> not saying it is the best or the only solution to the problem, I am
obviously
> open to EVERY comment... :-D and hopefully to some better solutions) you
can
> say, from the moment the user signals a danger the usage of the
certificate
> is compromised and that itself is to be considered in a 'freezed' state.
>
> Am I completely out of the target ? What do you think about this problem ?
> Thanks for the comments you sent.
>
> C'you,
>
> Massimiliano Pala ([e-mail])




Received: from casbah.gatech.edu ([e-mail] [130.207.165.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA12826 for <[e-mail]>; Sun, 30 Jan 2000 11:03:35 -0800 (PST)
Received: from jfwlap (gtri102.remote.gatech.edu [130.207.161.102]) by casbah.gatech.edu (8.9.2/8.9.2) with SMTP id OAA00241 for <[e-mail]>; Sun, 30 Jan 2000 14:05:25 -0500 (EST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 30 Jan 2000 13:15:10 -0500
To: [e-mail]
From: "John F. Wandelt" <[e-mail]>
Subject: subscribe
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

=====================================================================
John F. Wandelt
Senior Research Scientist
Information Technology Laboratory
Georgia Tech Research Institute
347 Ferst Drive, Atlanta GA 30332

Voice: 404-894-8956
Fax: [phone]
Internet: [e-mail]


Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06461 for <[e-mail]>; Sun, 30 Jan 2000 01:27:21 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBYG1VJ>; Sun, 30 Jan 2000 10:28:47 +0100
Message-ID: <[e-mail]>
From: Hans Nilsson <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: German Law and OCSP
Date: Sun, 30 Jan 2000 10:28:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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 BAA06462

Ambarish,

I agree with you, that no legislation should get into that level of
technology. And I dont think they do that, not even in Germany and Italy.
IMHO I think prof Lioy is overinterpreing the German and Italian
legislations, stating what they require and not require at a very technical
detail. Based on our experience in the German market, the regulations in
SigG and SigV are very fuzzy and open to interpretations. The reply on what
is needed sometimes depends on what authority in Germany you are talking to.

Your question regarding German Law and OCSP may be related to the following.
As you may know, the Germans have specified their own flavour of OCSP, with
somewhat different semantics:

Der Zustand good sagt aus, daß das Zertifikat von der zugehörigen
Zertifizierungsstelle
ausgestellt wurde, dem Verzeichnisdienst bekannt ist und zum Zeitpunkt
thisUpdate nicht
gesperrt ist.

(For non-German speakers: "Good" means that the certificate is issued by the
CA, known in the Directory and not revoked)

This is quite a different interpretation of "good" from RFC 2560, where
"good" not necessarily means that the certificate has been issued!!!

Maybe this should not even be called OCSP any longer. The Germans themselves
also call this a "Verification Service".

On the other hand, the recently adopted European Directive on Electronic
Signatures does not specify any binding requirements for signature
verification, only some general recommendations in Annex IV. This means,
quite correctly, that this level of technical detail for court evidence
should not be laid down in laws or regulations, but develop through "market
best practices". In the CEN Workshop on Electronic Signatures, we are now
going to try to interpret these recommendations and write them down in a
standard called "guideline for signature verification". THERE we can specify
details for a specific technology like X.509 certificates, CRL and OCSP.

Regards
Hans

> -----Original Message-----
> From:	Ambarish Malpani [SMTP:[e-mail]]
> Sent:	Saturday, January 29, 2000 6:35 PM
> To:	'[e-mail]'
> Subject:	German Law and OCSP
> 
> 
> Hi Guys,
>     I recently read a document that seemed to indicate that
> the German Digital Signature Law or some related documents
> specified that you can use OCSP to check the revocation status
> of a cert, but they allowed you to send over all 0's as the
> hash of the CA's public key.
> 
>     Does anybody know more about whether the statement above
> is true or not? If it is, I am concened that they might not be
> using OCSP correctly.
> 
>     Anybody with more information?
> 
> Regards,
> Ambarish


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18120 for <[e-mail]>; Sat, 29 Jan 2000 09:41:01 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLVWYM>; Sat, 29 Jan 2000 09:35:26 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: German Law and OCSP
Date: Sat, 29 Jan 2000 09:35:23 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Guys,
    I recently read a document that seemed to indicate that
the German Digital Signature Law or some related documents
specified that you can use OCSP to check the revocation status
of a cert, but they allowed you to send over all 0's as the
hash of the CA's public key.

    Does anybody know more about whether the statement above
is true or not? If it is, I am concened that they might not be
using OCSP correctly.

    Anybody with more information?

Regards,
Ambarish


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17854 for <[e-mail]>; Sat, 29 Jan 2000 09:35:21 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLVWY1>; Sat, 29 Jan 2000 09:29:46 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Antonio Lioy'" <[e-mail]>, [e-mail]
Subject: RE: OCSP and CSL
Date: Sat, 29 Jan 2000 09:29:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Antonio,
    Another minor nit-pick:

A CRL is not necessarily a "monotonically non-decreasing
list of revoked certificates". Nothing says that the list
needs to be sorted by serial number. There is work going on
in X.509, to define a CRL extension that can indicate that,
but this is not necessarily true about all CRLs.

Regards,
Ambarish

P.S. Whether a particular countries legislation allows you
to use an OCSP response as legal proof or not, would depend on
the legislators of that nation, but I would hope that legislators
would not get into the specifics of technologies used to do
things given the rapid change of technology.

A

> -----Original Message-----
> From: Antonio Lioy [mailto:[e-mail]]
> Sent: Friday, January 28, 2000 9:48 AM
> To: [e-mail]
> Subject: Re: OCSP and CSL
> 
> 
> Brian Tvedt wrote:
> > 
> > If I was that concerned about misuse of my private key, I 
> would password protect
> > it.  This seems much superior to relying on a complicated 
> mechanism (CSL) being
> > correctly implemented in every security application out there.
> 
> My private key IS password-protected, and nonetheless I
> could fear its misuse should I forget it around. This fear
> is even greater in Public Administrations with automatic
> signature servers. Since the law explicitly states that such
> servers sign on behalf of a real person, this guy has a real
> fear to be held responsible for signatures emitted during
> non-working hours. And as these servers typically use a
> crypto board, it is not that easy to disable it (could be
> used for SSL support too).
> 
> Revoking and issuing new certs is a real trouble, especially
> when a smart-card (Or crypto board) with one-time on-board
> private-key generation is involved.
> 
> Perhaps I have the wrong understanding of the Hold code in a
> RFC-2459 conformant CRL. I could not find a clear definition
> of how is a certificate "temporarily suspended" and yet
> placed in a CRL. In my understanding, a CRL is a
> monotonically non-decreasing list of revoked certificates.
> There is no way to state that a cert is valid again. Issuing
> another cert for the same key is simply not possible in
> certain environments.
> Either a CRL is augmented in meaning to be a list of invalid
> certs within specific timeframes (i.e. invalidity start -
> invalidity end, the latter being infinite for truly revoked
> certs), or a separate concept has to be created: CSL.
> 
> OCSP can then be the vehicle to convey punctual information
> about a cert status, but given teh current legislation in
> several countries, CRLs (and may be CSLs) have to be
> produced and archived for legal use.
> 
> Antonio Lioy
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17661 for <[e-mail]>; Sat, 29 Jan 2000 09:28:42 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLVWYA>; Sat, 29 Jan 2000 09:23:06 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Antonio Lioy'" <[e-mail]>, Mike Young <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Sat, 29 Jan 2000 09:22:59 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Antonio,
    In an OCSP response, you can indicate that the status
of the certificate specified is valid as long as the certificate
has not expired before a particular date (check the ArchiveCutoff
extension).

If a server does has information going back 2 years, it can indicate
that in the response.

Hope this helps,
Regards,
Ambarish

> -----Original Message-----
> From: Antonio Lioy [mailto:[e-mail]]
> Sent: Friday, January 28, 2000 10:20 AM
> To: Mike Young
> Cc: [e-mail]
> Subject: Re: OCSP and CSL
> 
> 
> Mike Young wrote:
> > 
> > >First of all OCSP is out of question is it is not a trust
> > >source but rather a delivery channel for fast trust
> > >information. For non-repudiation service, it needs to be
> > >backed up by long-term data such as those of a CRL.
> > 
> > Please elaborate
> 
> Done in another mail.
> 
> > >Finally, I'd like to give my users the autonomous ability to
> > >suspend and then re-activate their certificates. Let's
> > >imagine the following scenario:
> > >- I don't want to take my smart-card with me and I leave it
> > >at the office (or I use a software PSE installed on my PC at
> > >work)
> > >- as I don't trust the company in charge of cleaning up the
> > >office (or may be my co-workers), I'd like to suspend the
> > >cert validity during week-ends, vacation, or even during
> > >night hours
> > >- I'd like to do this by just clicking on a button on a
> > >secure Web page (with client authentication) or sending a
> > >signed S/MIME message to an automatic responder
> > >- the responder (or the Web server) could in turn provide me
> > >with a one-time token to re-activate the cert at my will
> >
> > You can do that with OCSP, xcert has a vacation program.
> 
> Great! but for legal use you need to put that in a long term
> archive.
>  
> > So every time a cert is Suspended, you want to add that to 
> the CSL? and I
> > assume you want this file issued frequently and signed by 
> the CA? What if
> > you have a CA with several million certs, the managment of 
> a CSL will be a
> > nightmare.
> > The only way to create a scalable PKI that can last 10-15 
> years is with
> > OCSP. CRL/CSLs are so 1980's :^)
> 
> May be CRL/CSL are so 80's, but OCSP is at most 90's  :-)
> not 2000, in the sense that it is complete deregulation. But
> how can I use OCSP to ask if a cert was valid 2 years ago?
> in the request there is no way to specify the time for which
> the check should be performed, so if I don't continuously
> ask to the OCSP server the status of all certs (building my
> personal CRL :-) I will never be able to prove revokation
> status in the future.
> OCSP is very much oriented to on-line short-lived
> transactions, while CRL/CSL are more useful in an off-line
> legal long-lived environment.
> 
> Best regards,
> 
> Antonio Lioy
> 


Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA14722 for <[e-mail]>; Fri, 28 Jan 2000 16:25:57 -0800 (PST)
Received: from phaos.com ([207.51.38.134]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id XAA55412 for <[e-mail]>; Fri, 28 Jan 2000 23:50:23 -0500 (EST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 19:28:53 -0500
From: Brian Tvedt <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Antonio Lioy wrote:
> 
> Brian Tvedt wrote:
> >
> > If I was that concerned about misuse of my private key, I would password protect
> > it.  This seems much superior to relying on a complicated mechanism (CSL) being
> > correctly implemented in every security application out there.
> 
> My private key IS password-protected, and nonetheless I
> could fear its misuse should I forget it around. This fear
> is even greater in Public Administrations with automatic
> signature servers. Since the law explicitly states that such
> servers sign on behalf of a real person, this guy has a real
> fear to be held responsible for signatures emitted during
> non-working hours. And as these servers typically use a
> crypto board, it is not that easy to disable it (could be
> used for SSL support too).

If you're that worried that one of your coworkers may have stolen your password
and is going to sneak into your office when you're gone and use your smartcard,
I don't think CSL's are going to help you much.  Won't you have to suspend your
certificate every time you go to the bathroom?

> Revoking and issuing new certs is a real trouble, especially
> when a smart-card (Or crypto board) with one-time on-board
> private-key generation is involved.
> 
> Perhaps I have the wrong understanding of the Hold code in a
> RFC-2459 conformant CRL. I could not find a clear definition
> of how is a certificate "temporarily suspended" and yet
> placed in a CRL. In my understanding, a CRL is a
> monotonically non-decreasing list of revoked certificates.
> There is no way to state that a cert is valid again. Issuing
> another cert for the same key is simply not possible in
> certain environments.
> Either a CRL is augmented in meaning to be a list of invalid
> certs within specific timeframes (i.e. invalidity start -
> invalidity end, the latter being infinite for truly revoked
> certs), or a separate concept has to be created: CSL.
> 
> OCSP can then be the vehicle to convey punctual information
> about a cert status, but given teh current legislation in
> several countries, CRLs (and may be CSLs) have to be
> produced and archived for legal use.

I don't know if there's anything in PKIX which says that if the set of revoked
certificates in a CRL must be a superset of every previously-issued (lower
serial number) CRL from the same CA.  In other words, it's legal (I think) for a
certificate listed on a CRL to "disappear" on the next update.  Then there's the
mysterious business of the certificateHold reason code, which is presumably
intended for this sort of thing.

In sum, I'm not sold that suspension of certificates is really necessary, but if
you're convinced that it is, it seems to me it could be done with CRLs as
currently defined.


--
Brian Tvedt
Phaos Technology Corp.


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 MAA12165 for <[e-mail]>; Fri, 28 Jan 2000 12:56:28 -0800 (PST)
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 PAA23498; Fri, 28 Jan 2000 15:58:16 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <v04220800b4b7ae6b9a28@[171.78.30.107]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 28 Jan 2000 15:50:38 -0500
To: Massimiliano Pala <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: More on OCSP and CSL
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Massimiliano,

I think we've established that, syntactically, we can represent the 
CSL concept using a CRL, with appropriate reason codes.  Thus there 
is no motivation to create another syntactic construct.  A CA can 
choose to issues a CDP just for suspended certs if appropriate.

One might choose to propose a new work item, a protocol for 
suspension and reinstantiation of certificates, based on the 
motivations that you are describing here.  Personally, I don't find 
them compelling in most instances. For example, the user who leaves 
his smart card at work before going on vacation.  However, some in 
the financial community have suggested such scenarios to justify the 
existence of suspension in the first place, so I know that you are 
not alone in thinking this way!


Steve


Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA10041 for <[e-mail]>; Fri, 28 Jan 2000 10:18:17 -0800 (PST)
Received: (qmail 18911 invoked from network); 28 Jan 2000 18:21:07 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 28 Jan 2000 18:21:07 -0000
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 19:20:19 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Young <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <001a01bf68fa$d6378a20$[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6B21F5776FBF6D741900F93F"

This is a cryptographically signed message in MIME format.

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

Mike Young wrote:
> 
> >First of all OCSP is out of question is it is not a trust
> >source but rather a delivery channel for fast trust
> >information. For non-repudiation service, it needs to be
> >backed up by long-term data such as those of a CRL.
> 
> Please elaborate

Done in another mail.

> >Finally, I'd like to give my users the autonomous ability to
> >suspend and then re-activate their certificates. Let's
> >imagine the following scenario:
> >- I don't want to take my smart-card with me and I leave it
> >at the office (or I use a software PSE installed on my PC at
> >work)
> >- as I don't trust the company in charge of cleaning up the
> >office (or may be my co-workers), I'd like to suspend the
> >cert validity during week-ends, vacation, or even during
> >night hours
> >- I'd like to do this by just clicking on a button on a
> >secure Web page (with client authentication) or sending a
> >signed S/MIME message to an automatic responder
> >- the responder (or the Web server) could in turn provide me
> >with a one-time token to re-activate the cert at my will
>
> You can do that with OCSP, xcert has a vacation program.

Great! but for legal use you need to put that in a long term
archive.
 
> So every time a cert is Suspended, you want to add that to the CSL? and I
> assume you want this file issued frequently and signed by the CA? What if
> you have a CA with several million certs, the managment of a CSL will be a
> nightmare.
> The only way to create a scalable PKI that can last 10-15 years is with
> OCSP. CRL/CSLs are so 1980's :^)

May be CRL/CSL are so 80's, but OCSP is at most 90's  :-)
not 2000, in the sense that it is complete deregulation. But
how can I use OCSP to ask if a cert was valid 2 years ago?
in the request there is no way to specify the time for which
the check should be performed, so if I don't continuously
ask to the OCSP server the status of all certs (building my
personal CRL :-) I will never be able to prove revokation
status in the future.
OCSP is very much oriented to on-line short-lived
transactions, while CRL/CSL are more useful in an off-line
legal long-lived environment.

Best regards,

Antonio Lioy
--------------ms6B21F5776FBF6D741900F93F
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

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwMTI4MTgyMDE5WjAjBgkqhkiG9w0BCQQxFgQUP/PlgO7Owr5sCoVTJRFYXZIr
HJEwDQYJKoZIhvcNAQEBBQAEgYDFfMhCAx9QCwJXDJG224COHjxr4iFUvlJefqzBqornOrSu
k5s6EXt0VLRJt/gYPdzIZG0jXX6YmXgQkpNI83CKvYH85Xb7xowjiHfe+c7tV8TxdADhFMvT
lZSyrGVopBVcd5QgAuavc5KF1Q4QwpEFLXradR9vrOUoAauKA/8lGQ==
--------------ms6B21F5776FBF6D741900F93F--



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 KAA09944 for <[e-mail]>; Fri, 28 Jan 2000 10:17:49 -0800 (PST)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id E7DE415531; Fri, 28 Jan 2000 13:19:15 -0500 (EST)
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 762D37C052; Fri, 28 Jan 2000 13:19:15 -0500 (EST)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2650.21) id <Z8F82KBR>; Fri, 28 Jan 2000 13:22:41 -0500
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Antonio Lioy'" <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Fri, 28 Jan 2000 13:22:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

>Sorry but there are several legislation in place (Italy and
>Germany at least) where it is clearly stated the only
>legally binding way to prove that a cert was not valid at a
>certain date is to provide a CRL (or a CSL!!!) that includes
>it.

This brings up two questions. The first is is there really any legislation
that talks about CSL's?

The second is really a set of them: what if the CA uses a different key to
sign CRL's?  What if the CA designates another entity to sign its CRL's?
What is special about a CRL that makes it the only valid proof? Suppose I
run a service bureau, acting as a CA for many companies. Suppose I partition
the CRL using CRLDP so that each company could only see their own revoked
certificates?  That wouldn't be legal?  If things were contested in a court
of law the CA would have to turn over its entire and complete CRL?

Yech. :)



Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA09688 for <[e-mail]>; Fri, 28 Jan 2000 10:09:27 -0800 (PST)
Received: (qmail 18907 invoked from network); 28 Jan 2000 18:12:16 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 28 Jan 2000 18:12:16 -0000
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 19:11:29 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE7E49EABFA1408E9C7D9B6D4"

This is a cryptographically signed message in MIME format.

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

Ambarish Malpani wrote:
> 
> Hi Antonio,
>     Comments inline.
> 
> > -----Original Message-----
> > From: Antonio Lioy [mailto:[e-mail]]
> > Sent: Thursday, January 27, 2000 9:32 AM
> > To: [e-mail]
> > Cc: 'Massimiliano Pala'
> > Subject: Re: OCSP and CSL
> >
> > First of all OCSP is out of question is it is not a trust
> > source but rather a delivery channel for fast trust
> > information. For non-repudiation service, it needs to be
> > backed up by long-term data such as those of a CRL.
> 
> I hope not! OCSP responses are signed and can very much be used for
> non-repudiation.

Sorry but there are several legislation in place (Italy and
Germany at least) where it is clearly stated the only
legally binding way to prove that a cert was not valid at a
certain date is to provide a CRL (or a CSL!!!) that includes
it.

There are not trusted 3-parties that can substitute it.

> The benefit of a CRL over OCSP, is that you have all the revoked certs
> in a single list, which is better for storage, IF YOU ARE INTERESTED
> IN THE STATUS OF ALL THE CERTS. However, it isn't any more non-repudiable
> than an OCSP response.

In these legal schemes, OCSP only buys you benefits in that
a client has not to process the whole CRL, but it can go to
court based only on the signed OCSP-response: it will need
to provide evidence of the CRL used by the OCSP server.
That's way in several cases it would be sufficient to have
non-signed OCSP responses over a trusted channel (e.g. SSL
with pure server authentication).
 
> > So I'd like to see this scenario supported by the following
> > technical details:
> > - a status code returned by an OCSP server to tell that a
> > cert is SUSPENDED
> 
> This is already possible in OCSP - see my previous mail on this
> topic.

I don't understand: OCSP primaty status is REVOKED (even if
reason is OnHold) and therefore that cert could never become
valid again. Or perhaps the word REVOKED is used with a
different meaning (i.e. not valid at this point in time)
from the one used in the CRL definition?
 
> Not quite sure what the CSL bought you - keeping track of all these
> suspensions - particularly if every user is going to suspend their
> cert on an average once a week will get pretty expensive very soon.

I agree that CSL doesn't look attractive, but I'm here
expressing a real need collected from some users (see
another mail of mine), and trying to understand what's the
correct technical solution with legal value.

Best regards,

Antonio Lioy
--------------msE7E49EABFA1408E9C7D9B6D4
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

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwMTI4MTgxMTI5WjAjBgkqhkiG9w0BCQQxFgQUzt8WU2vvGKXuaHYagIkh+hwi
kngwDQYJKoZIhvcNAQEBBQAEgYCykw3yYRDqYPkrO9rmICuOzoT2BOLjI3blhYcIdBnuFvqv
9QoXdmqCErLnLt72BSU01lW47eyZUBp7x7PRcPUVxC0erskQw9JB0Vh7wWsQwhOQWKif/i3U
svhMrQoxSgzl/IOXsJY7iNrFAjEItpWLe/S2diICN/JaMn1VTVGj9A==
--------------msE7E49EABFA1408E9C7D9B6D4--



Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA09435 for <[e-mail]>; Fri, 28 Jan 2000 09:59:13 -0800 (PST)
Received: (qmail 18899 invoked from network); 28 Jan 2000 18:02:02 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 28 Jan 2000 18:02:02 -0000
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 19:01:15 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: [e-mail]
Subject: Re: More on OCSP and CSL
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA3A061C6E90E08E944AAC22F"

This is a cryptographically signed message in MIME format.

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

Massimiliano Pala wrote:
> 
> Hi Antonio Lioy,
> 
> good in reading you again.

Hi Max :-)

> > - a long term memory that a cert was suspended during a
> > certain period of time; this should be provided by a CSL,
> > which closely resembles the format (but not the meaning) of
> > a CRL
> 
> Here I do have to point out this: I think it is not required
> to keep track of the suspension time of a certificate if it
> has not been revoked, if you have doubt about possible misusages
> of it, then it should be revoked, otherwise it has never been
> in 'danger' and it should be trusted so we don't have to keep
> track for suspension time.
> 
> To clarify:
> 
>         o CSL should keep track of suspension periods for
>           (afterwards) revoked certificates;
> 
>         o CSL should not keep track of suspension periods
>           for not (afterwards) revoked certificates;

This is another view: the CSL is being used as a waiting
list for possibly revoked certs. If it is later revoked,
then you'll put it in the CRL, otherwise you'll remove it
from the CSL.

But I disagree with this view: if I temporarily lost control
of my smart-card, I can never know what has happened during
that period of time.
May be two years later someone claims money from me, based
on a digital signature produced during that exact period of
time. If you removed the entry from the CSL, you'll not be
able to prove that it was not you that signed that document.

Do you agree?


Antonio Lioy
--------------msA3A061C6E90E08E944AAC22F
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

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwMTI4MTgwMTE1WjAjBgkqhkiG9w0BCQQxFgQUySLUkn356Nxf7BqqJK0/OdLb
TLYwDQYJKoZIhvcNAQEBBQAEgYAqLPwkkSHMTeCGz7f9Ve61U6t33FUteVE6Y6vGW/0f6Mlz
mJzgrhKRZoeObCXOy0MXaThb7RZvMlBMWEZ5BY1ScX5ZqP1R/3x1azjZyuqIrbqN5tpDYarV
4VOtDEQudkIVV7OCjfmKuze/FuI3rLo9KFqXlfI0GQYby6UmkG2KVg==
--------------msA3A061C6E90E08E944AAC22F--



Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09180 for <[e-mail]>; Fri, 28 Jan 2000 09:52:02 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21525; Fri, 28 Jan 2000 12:53:49 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Certificate Management Messages over CMS to Proposed Standard
Date: Fri, 28 Jan 2000 12:53:49 -0500
Sender: [e-mail]

The IESG has approved the Internet-Draft 'Certificate Management
Messages over CMS' <draft-ietf-pkix-cmc-05.txt> as a Proposed
Standard.  This document is the product of the Public-Key
Infrastructure (X.509) Working Group.  The IESG contact persons are
Jeffrey Schiller and Marcus Leech.

 
Technical Summary
 
This document describes how to use the Cryptographic Message Syntax
(CMS) (used by S/MIME) as the basis for a Certificate Management
Protocol (CMP). A CMP is used by entities who have created a
public/private key pair to communicate with a Certificate Authority (CA)
and arrange for the issuance and communication of a X.509
Certificate. This protocol must provide security services to ensure that
the correct public key is provided to the CA and that the entity is in
fact communicating with the CA it intends. CMC (this document) makes use
of CMS as a substrate to build these services.


Working Group Summary

The working group supports these documents.

Protocol Quality

Jeff Schiller has reviewed these documents for the IESG.

Note to RFC Editor:

Please change the last paragraph in the Abstract section from:

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in [RFC 2119].

To:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC 2119].


Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA08956 for <[e-mail]>; Fri, 28 Jan 2000 09:46:02 -0800 (PST)
Received: (qmail 18892 invoked from network); 28 Jan 2000 17:48:48 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 28 Jan 2000 17:48:48 -0000
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 18:47:55 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6780E801D9ACF791D8BFD51D"

This is a cryptographically signed message in MIME format.

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

Brian Tvedt wrote:
> 
> If I was that concerned about misuse of my private key, I would password protect
> it.  This seems much superior to relying on a complicated mechanism (CSL) being
> correctly implemented in every security application out there.

My private key IS password-protected, and nonetheless I
could fear its misuse should I forget it around. This fear
is even greater in Public Administrations with automatic
signature servers. Since the law explicitly states that such
servers sign on behalf of a real person, this guy has a real
fear to be held responsible for signatures emitted during
non-working hours. And as these servers typically use a
crypto board, it is not that easy to disable it (could be
used for SSL support too).

Revoking and issuing new certs is a real trouble, especially
when a smart-card (Or crypto board) with one-time on-board
private-key generation is involved.

Perhaps I have the wrong understanding of the Hold code in a
RFC-2459 conformant CRL. I could not find a clear definition
of how is a certificate "temporarily suspended" and yet
placed in a CRL. In my understanding, a CRL is a
monotonically non-decreasing list of revoked certificates.
There is no way to state that a cert is valid again. Issuing
another cert for the same key is simply not possible in
certain environments.
Either a CRL is augmented in meaning to be a list of invalid
certs within specific timeframes (i.e. invalidity start -
invalidity end, the latter being infinite for truly revoked
certs), or a separate concept has to be created: CSL.

OCSP can then be the vehicle to convey punctual information
about a cert status, but given teh current legislation in
several countries, CRLs (and may be CSLs) have to be
produced and archived for legal use.

Antonio Lioy
--------------ms6780E801D9ACF791D8BFD51D
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

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwMTI4MTc0NzU1WjAjBgkqhkiG9w0BCQQxFgQUZsPF1lnYi4vTb4LnwHwSuy/l
LbswDQYJKoZIhvcNAQEBBQAEgYCYkXfYrSVJ51rFSB4OeHxSQ56CdaHA++H1sNKqHO0wGpDZ
pAorL6oCJXqIAU7eAf7Gpr/qxzexM5wJ0N30d8+LXrsc9LGiEwVpyK0qNrMVOkpdUNMed5M2
vZI9+2zYO3UxYhFBtnqLlQORlqwRYem2/Ay5M/gOOd2HN+8KzQs1Zg==
--------------ms6780E801D9ACF791D8BFD51D--



Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08079 for <[e-mail]>; Fri, 28 Jan 2000 08:47:38 -0800 (PST)
Received: from phaos.com ([207.51.38.134]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id QAA53492 for <[e-mail]>; Fri, 28 Jan 2000 16:12:07 -0500 (EST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 11:50:41 -0500
From: Brian Tvedt <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Antonio Lioy wrote:
> 
> I think that CSL is a real need in several cases and that it
> cannot be easily substituted with CRL or OCSP.
...
> Finally, I'd like to give my users the autonomous ability to
> suspend and then re-activate their certificates. Let's
> imagine the following scenario:
> - I don't want to take my smart-card with me and I leave it
> at the office (or I use a software PSE installed on my PC at
> work)
> - as I don't trust the company in charge of cleaning up the
> office (or may be my co-workers), I'd like to suspend the
> cert validity during week-ends, vacation, or even during
> night hours
> - I'd like to do this by just clicking on a button on a
> secure Web page (with client authentication) or sending a
> signed S/MIME message to an automatic responder
> - the responder (or the Web server) could in turn provide me
> with a one-time token to re-activate the cert at my will
> 
> There are other similar scenarios (like I forgot where I put
> my smart-card, and later I find it) where I don't want to
> have the burden of revoking and reissuing certs.

If I was that concerned about misuse of my private key, I would password protect
it.  This seems much superior to relying on a complicated mechanism (CSL) being
correctly implemented in every security application out there.

--
Brian Tvedt
Phaos Technology Corp.


Received: from aunt15.ausys.se (void1.ausys.se [62.20.78.253]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07570 for <[e-mail]>; Fri, 28 Jan 2000 08:24:53 -0800 (PST)
Received: by aunt15.ausys.se with Internet Mail Service (5.5.2650.21) id <WCBYGAZD>; Fri, 28 Jan 2000 17:26:10 +0100
Message-ID: <[e-mail]>
From: Simon Tardell <[e-mail]>
To: [e-mail]
Cc: "'Philip Hallam-Baker'" <[e-mail]>
Subject: RE: OCSP and CSL
Date: Fri, 28 Jan 2000 17:26:19 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

> >I cannot find my smartcard... I suppose I left it at my friend's 
> >house, but I am not sure... So I ask for a suspesion of the service.
> >Then I go to my friend's house and I find my smartcard... so the 
> > certificate have never been in danger, I can ask the
> >CA Org not to revoke it and from the suspended state it returns to the
> > lid state.
> 
> 
[...]

> Revoking certificates and reissue sounds like an excellent solution to 
> is problem. The encryption key can be rolled over in the re-issued card,
> miniting new signing keys is never a problem.
> 
> I don't think that the change of the cert status back to 
> valid has much hope of being acurately and reliably tracked.
> Re-certificatrion is a slam dunk.

I don't quite agree. Reissuing a certificate for a smart card will always be
more of hassle than suspending/unsuspending. Not so much for the CA, but for
the user who needs to put his card into a reader capable of updating the
certificate on the smart card (assuming that the certificate is stored
together with the keys). Given that suspension/unsuspensions usually are
requested over phone, I don't think people would be happy with this.

Simon

Simon Tardell, Software Architect, iD2 Technologies
[e-mail], http://www.iD2tech.com/
voice [phone], cell [phone], fax [phone]
European IT-prize grand winners 1998 -- http://www.it-prize.org
AU-System Group Swedish IT-company of the year 1999


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02967 for <[e-mail]>; Thu, 27 Jan 2000 16:59:48 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id BAA20802; Fri, 28 Jan 2000 01:59:42 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 02:01:11 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Antonio Lioy <[e-mail]>
CC: [e-mail]
Subject: More on OCSP and CSL
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8BC0966487B9601BCB9DA3B6"

This is a cryptographically signed message in MIME format.

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

Hi Antonio Lioy,

good in reading you again. You wrote:

> I think that CSL is a real need in several cases and that it
> cannot be easily substituted with CRL or OCSP.

I had different comments on this, some share our opininon, others
have expressed perplexity in defining a new acronymous and/or
definition... :-(

[...]
> So I'd like to see this scenario supported by the following
> technical details:
> - a status code returned by an OCSP server to tell that a
> cert is SUSPENDED

Most of the people reported that the OCSP can be used in conjunction
with extentions to state the certificateHold revokation reason (this
is the widely suggested option we actually have for the OCSP
responder ... ). The same (by absurd) could apply to CRLs: CRLs can
be replaced by an OCSP responder, isn't it ??? But would you abandon
the CRL mechanism??? No ??? Why ??? Probably what you would respond
to this question is very similar to what I would about CSL ...

> - a long term memory that a cert was suspended during a
> certain period of time; this should be provided by a CSL,
> which closely resembles the format (but not the meaning) of
> a CRL

Here I do have to point out this: I think it is not required
to keep track of the suspension time of a certificate if it
has not been revoked, if you have doubt about possible misusages
of it, then it should be revoked, otherwise it has never been
in 'danger' and it should be trusted so we don't have to keep
track for suspension time.

To clarify:

	o CSL should keep track of suspension periods for
	  (afterwards) revoked certificates;

	o CSL should not keep track of suspension periods
	  for not (afterwards) revoked certificates;

This should be adopted not to have CSLs too long and carring
not useful data (why keeping track of supension periods if
you, moving again to the valid state the certificate, say it
was never in danger and you trust it.... ).

This is only my vision on CSL :-D More comments on this ???

C'you,

	Massimiliano Pala ([e-mail])
--------------ms8BC0966487B9601BCB9DA3B6
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI4MDEwMTExWjAjBgkqhkiG9w0BCQQxFgQUCXS8XRW+bXIBPDDNbJrgfnshCBww
DQYJKoZIhvcNAQEBBQAEgYAm8aCWt+RJwLzlCYxEJ+fQoXZPuD1fVDbRjUm6BzwZ7WhqhoZ5
1KNXVcy0TtfbCOMw7sU6FbSUyY66PPUfC2vslsSxZ7oASCAXmlm2phS0Dcx5GlpyB/hsaFeF
/EUPYrbGcZ0q3MQdoQUWpBPmdfp+D3JY8rtRIFINL9ukNMok5g==
--------------ms8BC0966487B9601BCB9DA3B6--



Received: from c004.sfo.cp.net (c004-h009.c004.sfo.cp.net [209.228.14.66]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA02446 for <[e-mail]>; Thu, 27 Jan 2000 16:32:46 -0800 (PST)
Received: (cpmta 20273 invoked from network); 27 Jan 2000 16:44:17 -0800
Received: from cs2889-175.austin.rr.com (HELO tuvit.net) (24.28.89.175) by smtp.tuvit.net with SMTP; 27 Jan 2000 16:44:17 -0800
X-Sent: 28 Jan 2000 00:44:17 GMT
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2000 18:36:05 -0600
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Philip Hallam-Baker <[e-mail]>
CC: Paul Koning <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: IETF and ISO alignment on Time Stamping
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------D98A8129E816209C62455B5D"

This is a multi-part message in MIME format.
--------------D98A8129E816209C62455B5D
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Phil,

I do understand your concern but taking into account that this leads to
a moderate delay and the benefits in having compatibility with an ISO
standards and a structure readz for future extensions it is not that
bad.

All I can say is that the ISO committee was always trying to keep its
Working Draft aligned but these are unsolvable issues without the
support of you. And we did meet last week during the RSA to head this
way. That sounds like excuses but it´s the way it is.

Roland

Philip Hallam-Baker wrote:
> 
> I am really not happy with any proposal to extend functionality that
> appears during a last call.
> 
> At that point the only fair thing to do IMHO is to ask 'is this
> something
> that absolutely cannot be supported through the existing extension
> mechanism(s) supported', and if there is no extension mechanism to add
> one.
> 
> Last call should be about 'it is broken', 'the spec is broken', 'not
> enough time to discuss', 'fundamentally broken approach' etc.
> 
> The number of patents issued in the timestamp field do not give me much
> confidence in the statement 'none of them under patent restrictions'.
> Someone has already claimed to own the entire idea and been full enough
> of themselves to try their luck in court. I am pretty sure that the
> USPTO is currently approving patents on the fourth dimension itself.
> Minutes after the post went out on the list six lurkers probably filled
> claims. The latest scam by the way is to take an existing idea and
> write out the claims in object oriented progamming jargon to make it
> sound different. Apparently the technique is as effective on the PTO
> as it is in marketing.
> 
> There are racks of patent claims on time. Most are demonstrably abusive
> patents but gathering together prior art takes a lot of time. It is not
> a can of worms that can really be opened in the context of last call.
> 
> Rather than delay the last call it is probably best to apply the
> 'extension'
> principle I outlined and submit a draft proposing the features as
> extensions.
> 
> I don't think this should take any longer than taking timestamp out of
> last call, rediting and recycling the last call.
> 
>                 Phill
>
--------------D98A8129E816209C62455B5D
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------D98A8129E816209C62455B5D--



Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02320 for <[e-mail]>; Thu, 27 Jan 2000 16:32:26 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id BAA19775; Fri, 28 Jan 2000 01:33:15 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2000 01:34:44 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Meijer <[e-mail]>
CC: [e-mail]
Subject: More on OCSP and CSL
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE8F9059920500372775046AE"

This is a cryptographically signed message in MIME format.

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

Jan Meijer wrote:

> I still have some doubts however regarding the feasibility of implementing
> this thing.  It seems to me you open your CA to a nice little DoS attack if
> you do not carefully authorize the certificate suspension.  How to take care
> of the certificate suspension (signature of course, problem solved).

You are right when you say a DoS attack is possible, but the problem, to me,
it is internal to every organization. Let me explain. How CSL is generated
(got from the 24/h phone service, passwd authenticate service... ) this is
something you should solve within the organization and the software you are
using, it is not a matter of standards...

Some time ago we have talked about this problems, one solution would have been
sending an encrypted mail when the certificate is issued with a 'suspension/
revokation' code/passwd (indeed the true path is more complex, anyway lets cut
off details), but this is only ONE solution... :-D

> Second possible problem, how to trust the CSL.  I can trust the CSL because
> it has been signed by the CA on the offline certification server (sorry, had
> to use the term ;).  I cannot ever trust the CSL because it cannot have been
> generated on the offline certification server (because of arguments given
> before).  I don't see a solution to this.

The CSL could be signed by a certificate allowed to sign CSLs. This could be the
same OCSP server: when a certificate is to be moved from one state to another a
new CSL is issued and signed. This could be useful in OCSP implementations as the
OCSP responder can keep informations in the couple CSL/CRL. When a certificate is
found to be suspended, as suggested by many people, a response of 'revoke' can be
given by the OCSP responder with reason extention set to certificateHold...
 
> Third possible problem, how do you recognize the true owner of a certificate
> if he wants to turn his status back to "OK".  Someone explicitly (and
> probably with client authentication or something similar) stated his
> certificate has possibly been compromised.  You will need a good mechanism
> to make sure that the certificate owner is telling the truth when stating
> his certificate has not been compromised.  This might be more of a
> procedural thing, still is important to think about.  Once a certificate has
> been marked as possibly compromised, how to trust it again?
> 
> Jan

Turning his certificate back to OK could be a feature, supported or not by the
organization, requiring more than one pass to be accomplished or not. I think
this is a procedural matter within the organization...

Many (and different) aknoledgemnt methods can be used ( phone, e-mail, fax,
meeting in person) can be adopted to check the ID to be the authorized one.

C'you,

	Massimiliano Pala ([e-mail])
--------------msE8F9059920500372775046AE
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI4MDAzNDQ0WjAjBgkqhkiG9w0BCQQxFgQUCdapDeyq+m3RhVgHA+XrBEi03rsw
DQYJKoZIhvcNAQEBBQAEgYAcKa/QFti84cMkN4NbsG0unLDiIUFQgmSWeqaGAdx8dzIiCp/a
pFpbH9RQctrtxRVaBENVnP/vEnpsAPekddtnIJVpghnCjAkEhpRlZQ8qRpc+KXfbZyXg8pVI
qSNrwsINaD+rPH03e+N1Gr9Qs6dnuCSFdsLWhQSlndfDnmTdug==
--------------msE8F9059920500372775046AE--



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01829 for <[e-mail]>; Thu, 27 Jan 2000 16:03:15 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id QAA19757; Thu, 27 Jan 2000 16:01:56 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <CMBLXM9Y>; Thu, 27 Jan 2000 16:04:04 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Roland Mueller'" <[e-mail]>, Paul Koning <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: IETF and ISO alignment on Time Stamping
Date: Thu, 27 Jan 2000 16:04:02 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0035_01BF68F9.71F6AC40"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01BF68F9.71F6AC40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am really not happy with any proposal to extend functionality that
appears during a last call.

At that point the only fair thing to do IMHO is to ask 'is this
something
that absolutely cannot be supported through the existing extension 
mechanism(s) supported', and if there is no extension mechanism to add
one.

Last call should be about 'it is broken', 'the spec is broken', 'not
enough time to discuss', 'fundamentally broken approach' etc.


The number of patents issued in the timestamp field do not give me much
confidence in the statement 'none of them under patent restrictions'. 
Someone has already claimed to own the entire idea and been full enough
of themselves to try their luck in court. I am pretty sure that the
USPTO is currently approving patents on the fourth dimension itself.
Minutes after the post went out on the list six lurkers probably filled
claims. The latest scam by the way is to take an existing idea and
write out the claims in object oriented progamming jargon to make it
sound different. Apparently the technique is as effective on the PTO
as it is in marketing.

There are racks of patent claims on time. Most are demonstrably abusive
patents but gathering together prior art takes a lot of time. It is not
a can of worms that can really be opened in the context of last call.


Rather than delay the last call it is probably best to apply the
'extension'
principle I outlined and submit a draft proposing the features as
extensions.

I don't think this should take any longer than taking timestamp out of
last call, rediting and recycling the last call.

		Phill


-----Original Message-----
From: Roland Mueller [mailto:[e-mail]]
Sent: Thursday, January 27, 2000 10:28 AM
To: Paul Koning
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: Re: IETF and ISO alignment on Time Stamping


Paul,

the current document proposes in its part 2 a few mechanisms, none of
them under patent restrictions. I copied this part after my signature.
Sorry but i's quite some stuff and the figures are not included. If
interested I can also provide the whole doc but then it's PDF and it
does not reflect the results of the discussions we had last week. 

Roland

---------------------------------------
First Protocol (TSA checks T and signs receipt)
Step 1 (Originator): For a given document D, the originator creates a
time-stamp receipt using the current time T and a hash value H(D)
computed on the document D.  We assume that the originator has access to
a trusted clock that provides current time T.
Step 2 (Originator): The originator provides or transmits the time-stamp
receipt to a Time-Stamping Authority (TSA).
Step 3 (TSA): Optionally, the TSA performs a consistency check on the
received time-stamp receipt to ensure that the data contained in the
time-stamp receipt is consistent with data maintained at and controlled
by the TSA.
Step 4: (TSA): The TSA also verifies that the (now) current time T' and
the time value T in the time-stamp receipt are equal to within some
pre-established time window.  For example, it may be pre-arranged that
the time values T and T' are specified to the nearest whole minute,
e.g., by rounding up to the nearest whole minute.  That is, the clock
values are accurate to the nearest minute.  Thus, if T and T' are equal
with respect to year, month, day, hour, and minute, then they are
considered equal, even though they may not be equal if greater accuracy
were used.  (T and T' could differ by several seconds and still be equal
to the nearest whole minute.)  We assume that the TSA has access to a
trusted clock that provides current time T'.
Step 5 (TSA): If the time-stamp receipt is acceptable, the TSA signs the
time-stamp receipt with its private signature generation key.  We assume
that the TSA has a public and private key pair used for signing
time-stamp receipts.  The private signing key is available only to the
TSA, whereas the public key is made available to anyone so that they can
verify the signatures on time-stamp receipts generated by the TSA.  The
public key of the TSA can be stored in a certificate signed by a
Certification Authority (CA), so that the TSA's public key can validated
and, hence, trusted by those using that public key.
Step 6 (TSA): The TSA provides or transmits the signed time-stamp
receipt to the originator.






 			


Figure 1.  Time-Stamping in First Protocol

Differences:  In Fischer [1], the TSA operates on TSA-generated clock
signals.  In the alternative protocol, the TSA operates on clock signals
generated by the originator. In Haber [2, 3], the TSA creates the
receipt.  In the alternative protocol, the originator creates the
receipt.

4 Second Protocol (TSA computes age of time-stamped receipt)
Step 1 (Originator): For a given document D, the originator creates a
time-stamp receipt using the current time T and a hash value H(D)
computed on the document D.  We assume that the originator has access to
a trusted clock that provides current time T.
Step 2 (Originator): The originator provides or transmits the time-stamp
receipt to a Time-Stamping Authority (TSA).
Step 3 (TSA): Optionally, the TSA performs a consistency check on the
received time-stamp receipt to ensure that the data contained in the
time-stamp receipt is consistent with data maintained at and controlled
by the TSA.
Step 4 (TSA): The TSA computes a time difference, ?, between the time T
in the received time-stamp receipt and the now current time T', e.g., ?
= T' - T, where ? is referred to as an age value, or the age of the
document.  We assume that the TSA has access to a trusted clock that
provides current time T'.
Step 5 (TSA): If the received time-stamp receipt is acceptable, the TSA
creates an augmented time-stamp receipt from the computed age value of
the document and the received time-stamp receipt.
Step 6 (TSA): The TSA signs the augmented time-stamp receipt with its
private signature generation key.  We assume that the TSA has a public
and private key pair used for signing time-stamp receipts.  The private
signing key is available only to the TSA, whereas the public key is made
available to anyone so that they can verify the signatures on time-stamp
receipts generated by the TSA.  The public key of the TSA can be stored
in a certificate signed by a Certification Authority (CA), so that the
TSA's public key can validated and, hence, trusted by those using that
public key.
Step 7 (TSA): The TSA provides or transmits the signed augmented
time-stamp receipt to the originator.







 			


Figure 2.  Time-Stamping in Second Protocol


Differences: In Fischer [1], the TSA operates on a digital input and a
TSA-generated clock value.  In the alternative protocol, the TSA
operates on a digital input and a computed age value.  In Haber [2,3],
the TSA creates a receipt comprising a digital input and a TSA-generated
clock value.  In the alternative protocol, the TSA creates a receipt
comprising a digital input and a computed age value.
5 Third Protocol (TSA validates MAC on time-stamp receipt)
In the third protocol, the TSA provides both a "local" time-stamping
service and a "global" time-stamping service.  The distinction between
"local" and "global" is this: A local time-stamping service is one that
produces time-stamp receipts that can be validated only by the TSA that
generated them.  Therefore, only that particular TSA can "vouch" for the
time-stamp receipt.  A global time-stamping service is one that produces
time-stamp receipts that can be validated universally, by any entity. 
For our purposes, a local time-stamp receipt is one produced using a
keyed-hash function, or symmetric key cryptography; a global time-stamp
receipt is one produced, as is the usual case, using public key
cryptography.
A local time-stamping service could be beneficial in its own right. 
However, in the third protocol the local time-stamping service is shown
in combination with a global time-stamping service, where (in this case)
the local time-stamping service provides the originator with a local
time-stamp receipt that it can later choose to translate to a global
time-stamp receipt.  The fees for local and global time-stamping
services might be priced differently to provide customers with a wider
selection of time-stamping options.
Step 1 (Originator): The originator sends a hash value H(D) computed on
the document D to a TSA.  
Step 2 (TSA): The TSA creates a time-stamp receipt using the current
time T and H(D).  The TSA has access to a trusted clock that provides
current time T.
Step 3 (TSA): The TSA generates a secret random value K, e.g., a secret
key.  The TSA generates a Message Authentication Code (MAC) on the
time-stamp receipt using the generated secret value K.  Each generated K
is saved and later retrieved and used to validate the MAC (step 6 in the
protocol), after which K can be discarded.  The stored K is indexed
using any convenient method that links the time-stamp receipt to the
stored value of K, e.g., a sequential receipt number R.  Or, the MAC
(treated as a binary number) might be used to index a direct access file
composed of values of the form (MAC, K).
Step 4 (TSA): The TSA provides or transmits the time-stamp receipt and
MAC to the originator.
Step 5 (Originator): At a later time, the originator optionally provides
or transmits the time-stamp receipt and MAC, received at step 4 in the
protocol, to the TSA, requesting the TSA to certify the time-stamp
receipt.
Step 6 (TSA): The TSA locates K and uses it to validate the received
time-stamp receipt and MAC. If the time-stamp receipt and MAC are valid,
the protocol continues.
Step 7 (TSA): The TSA signs the received MAC with its private signature
generation key.  We assume that the TSA has a public and private key
pair used for signing time-stamp receipts.  The private signing key is
available only to the TSA, whereas the public key is made available to
anyone so that they can verify the signatures on time-stamp receipts
generated by the TSA.  The public key of the TSA can be stored in a
certificate signed by a Certification Authority (CA), so that the TSA's
public key can be validated and, hence, trusted by those using that
public key.
Step 8 (TSA): The TSA provides or transmits the signed MAC and K to the
originator.  K is provided to allow the originator to validate the
received signed MAC value.  
NOTE:  Once the TSA validates the time-stamp receipt and MAC, step 6 in
the protocol, there is no loss in security for the TSA to divulge K,
provided of course that its stored copy of K is erased or marked
"unusable."  Erasing K or marking it unusable will prevent a subsequent
spoofing attack in which the originator generates a new MAC on a forged
time-stamp receipt using K.
Step 9 (Originator): The originator validates the time-stamp receipt and
MAC received at step 4 in the protocol.  This is accomplished by using
the received value of K to generate a MAC on the time-stamp receipt and
then comparing the generated MAC with the MAC received at step 4 in the
protocol, for equality.  If the MAC received at step 4 in the protocol
is valid, the originator then validates the signed MAC, received at step
8 in the protocol, using the public key of the TSA.  Finally, the
originator forms a new record consisting of [time-stamp receipt, MAC, K,
and Signed MAC], which will allow time-stamp receipt to be validated by
any third party.







 			




 			


Figure 3.  Time-Stamping in Third Protocol
7.1 Third Protocol Variation
In a variation on the third protocol, the TSA does not store secret K
values.  Instead, the TSA has a secret master key KM that is uses to
encrypt the K values.  It has another secret key Kmac that it uses to
generate message authentication codes on the concatenation of K and
MAC.   In this case, there are two levels of MAC.  One is based on a
dynamic key K that the TSA later divulges to the originator, the other
is based on a persistent key Kmac that the TSA does not divulge to the
originator, or to anyone.
Steps 1 (Originator): unchanged. 
Step 2 (TSA): unchanged.  
Step 3 (TSA): The TSA additionally encrypts K under KM to produce the
encrypted key value eKM(K) and it additionally generates a message
authentication code, denoted MAC2, on K and MAC using Kmac.  In this
case, K and MAC are treated as data values and combined, e.g., by
concatenating the values. 
Step 4 (TSA): The TSA provides or transmits the time-stamp receipt, 
MAC, encrypted key eKM(K), and MAC2 to the originator.  
Step 5 (Originator): The originator provides or transmits the time-stamp
receipt,  MAC, eKM(K), and MAC2 to the TSA.  
Step 6 (Originator): The TSA retrieves K by decrypting the received
value of eKM(K) with its stored and retrieved copy of KM.  Next, the TSA
validates MAC2 by computing a message authentication code on K and MAC
using its stored copy of Kmac and comparing the computed message
authentication code with the received value of MAC2, for equality.  If
the combination of K and MAC (e.g., the concatenation of K and MAC) are
valid, the TSA validates the received time-stamp receipt and MAC using
K.  This is accomplished by computing a message authentication code on
the received time-stamp receipt using the retrieved and authenticated
value of K and then comparing the computed message authentication code
with the received MAC for equality.  If the validation operations
succeed, then the inputs are accepted as valid.  Otherwise, the values
are rejected.  
Step 7 (TSA): This step executes only if all validation operations in
step 6 succeed.  
Step 8 (TSA): This step is different in that there is no stored copy of
K at the TSA to be erased.  Divulging K does not subvert security, since
even with knowledge of K, the originator (or an adversary) cannot
generate a valid MAC2 without knowledge of Kmac, which is necessary in
order to spoof the TSA at step 6.  
Step 9 (Originator): unchanged. 






 			




 			

Figure 4.  Time-Stamping in the Third Protocol (Variation)
Differences: In Fischer [1], the TSA operates on two values, a digital
input and a TSA-generated clock value.  In the alternative protocol, the
TSA operates on one value, a digital input (i.e., a MAC).  In Haber [2,
3], the TSA certifies a receipt comprising an input digital document and
a clock value.  In the alternative protocol, the TSA certifies a digital
input (i.e., a MAC).
6 Fourth Protocol (TSA creates two records coupled via a nonce)
Step 1 (Originator): The originator sends a hash value H(D) computed on
the document D to a TSA.  
Step 2 (TSA): The TSA generates a nonce value, N.   
NOTE: It is important that N does not repeat for a given signing key. 
If N is randomly generated, we assume that the length of N is adjusted
to ensure adequate security.  If N is the value of an incrementing
counter or sequence number, we assume that it is large enough to ensure
that it does not repeat or cycle. 
Step 3 (TSA): The TSA creates a first receipt (N, T), which is a
time-stamp receipt, consisting of the nonce N and the current time T. 
The TSA has access to a trusted clock that provides current time T.
Step 4 (TSA): The TSA creates a second receipt (N, H(D)) consisting of
the nonce N and  H(D).
Step 5 (TSA): The TSA generates two signatures.  It signs the first
receipt (N, T), produced at step 3, with its private signature
generation key.  It signs the second receipt (N, H(D)), produced at step
4, with its private signature generation key.
Step 6 (TSA): The TSA provides or transmits the signed time-stamp
receipt (N, T) and the signed receipt (N, H(D)) to the originator.







 			


Figure 5.  Time-Stamping in Fourth Protocol

Differences: In Fischer [1], the TSA operates simultaneously on the
digital input and a TSA-generated clock value.  In the alternative
protocol, the TSA operates separately on the digital input and the
TSA-generated clock value.  In Haber [2, 3], the TSA certifies a receipt
comprising an input digital document and a clock value.  In the
alternative protocol, the TSA certifies two receipts, but these two
receipts are different from the single receipt in Haber.
7 Fifth Protocol (TSA computes time difference on time-stamp receipt
using the public verification key certificate)
The fifth protocol is similar to the second protocol, in that the TSA
computes a time difference, ?, between two time values.  But, in the
fifth protocol, ? is the difference between the time T recorded in the
public key certificate corresponding to the TSA's private signing key
and the now current time T', as measured by the TSA, i.e., ? = T - T'. 
Hence, in the fifth protocol, ? does not represent the age of document
D, but rather it is an arbitrary value, representing neither the current
time nor the age of the document.  Since the public key certificate,
containing T, is always available to validate a time-stamp receipt,
containing ?, one is assured that T can be readily determined.
NOTE:  The fifth protocol will operate in situations where the TSA's
public key certificate is signed by a CA or where it is signed by the
TSA using it's private signing key (self-signing).  In the latter case,
some cross certification of certificates may also be useful or
necessary, depending on how the protocol is operated.
Step 1 (Originator): The originator sends a hash value H(D) computed on
the document D to a TSA.  
Step 2 (TSA): The TSA computes a time difference, ?, between the time T
recorded in the public key certificate corresponding to the TSA's
private signing key and the now current time T', e.g., ? = T' - T.  The
TSA has access to a trusted clock that provides current time T'.
NOTE:  The value of T in the public key certificate is a value that may
be established by the TSA when requesting a certificate, it may be
determined by the CA or some combination of both the TSA and CA, or some
completely independent means.
Step 3 (TSA): The TSA creates a time-stamp receipt from the computed
value of ? and the received H(D).
Step 4 (TSA): The TSA signs the time-stamp receipt with its private
signature generation key.  We assume that the TSA has a public and
private key pair used for signing time-stamp receipts.  The private
signing key is available only to the TSA, whereas the public key is made
available to anyone so that they can verify the signatures on time-stamp
receipts generated by the TSA.  The public key of the TSA can be stored
in a certificate signed by a Certification Authority (CA), so that the
TSA's public key can be validated and, hence, trusted by those using
that public key.
Step 7 (TSA): The TSA provides or transmits the signed time-stamp
receipt to the originator.







 			


Figure 6.  Time-Stamping in Fifth Protocol
Differences: In Fischer [1], the TSA operates on a digital input and a
TSA-generated clock value.  In the alternative protocol, the TSA
operates on a digital input and a computed time difference.  In Haber
[2,3], the TSA creates a receipt comprising a digital input and a
TSA-generated clock value.  In the alternative protocol, the TSA creates
a receipt comprising a digital input and a computed time difference.  In
both cases, the signed time-stamp receipt does not contain enough
information to determine the current time T'.  The additional
information needed to compute T' is carried outside the signed
time-stamp receipt, in the TSA's public key certificate.
8 Sixth Protocol (time is completely determined by the public key
certificate) 
In the sixth protocol, the TSA's public key certificate alone determines
the time-stamp.  To illustrate the idea, suppose that the TSA issues a
new public key certificate daily.  That is, a new public and private
signing key pair is generated and used each day.  In this case, any
document signed with the TSA's daily signing key establishes the date
and time, to within 24 hours, when the document was received by the
TSA.  
The idea could be extended by generating new key pairs more frequently,
e.g., hourly, or in increments of a few minutes.  In such a case, the
TSA would not only return the signed value of H(D), but it would also
return the associated public key certificate, thereby allowing the
originator to verify the time-stamp.  In turn, the originator could
provide the signed H(D) and certificate to third parties interested in
validating the time-stamp.  The TSA would also escrow its public key
certificates in case users inadvertently lose or misplace them.  
For  TSAs with high volumes of traffic, the sixth protocol could be
attractive, since the time information is completely carried in the
certificate, and hence users only need to handle signed documents, in
the usual sense.
The TSA still needs to have access to a trusted clock to ensure that
keys roll over at the proper times.
Differences: In Fischer [1], the TSA operates on a digital input and a
TSA-generated clock value.  In Haber [2,3], the TSA creates a receipt
comprising a digital input and a TSA-generated clock value.  In the
alternative protocol, the TSA merely signs the digital input H(D) from
the originator.  The certificate contains a start and stop time, and is
signed.  But, this is not a time-stamp, since the times established in
the certificate are not indicative of the current time when the
certificate is generated, received, or signed.
9 References
A. M. Fischer, "Public/Key Date-Time Notary Facility," U.S. Patent
5,001,752, issued March 19, 1991.
S. A. Haber and W. S. Stornetta, Jr., "Method for secure time-stamping
of digital documents," U. S. Patent 5,136,647, issued August 4, 1992.
S. A. Haber and W. S. Stornetta, Jr., "Method for secure time-stamping
of digital documents," U. S. Patent Re. 34,954, issued May 30, 1995.
B. Schneier, "Applied Cryptography" (second edition), John Wiley & Sons,
Inc., 1996, pp. 75-78.


Paul Koning wrote:
> 
> Could you give an example of an application for the proposed Mechanism
> Identifier field?  While more generality can be a good thing, it's
> useful to have an example to justify added stuff.
> 
>         paul

------=_NextPart_000_0035_01BF68F9.71F6AC40
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDEyODAwMDUxNVowIwYJKoZI
hvcNAQkEMRYEFEG7S3jbd0tqQQx1rXkae2a/uWnhMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAfgokJk0XMHWY2aQP43cr+x4UY7d44KlOkUcs5ykRYq5YtpF4RANV9zFc+YjDL0kV
Shvo4c80A7R963njEEBkoaXo/MsUxwF9iSBr68fyHUhktyM4mQ+CYHVQeXM/uy6Z6uHl3kmQRdHZ
kVXtL0MohYWDH+tAh9i5aBldAcVkSm0AAAAAAAA=

------=_NextPart_000_0035_01BF68F9.71F6AC40--



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27297 for <[e-mail]>; Thu, 27 Jan 2000 11:44:41 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLVSLX>; Thu, 27 Jan 2000 11:39:04 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Antonio Lioy'" <[e-mail]>, [e-mail]
Cc: "'Massimiliano Pala'" <[e-mail]>
Subject: RE: OCSP and CSL
Date: Thu, 27 Jan 2000 11:39:03 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Antonio,
    Comments inline.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Antonio Lioy [mailto:[e-mail]]
> Sent: Thursday, January 27, 2000 9:32 AM
> To: [e-mail]
> Cc: 'Massimiliano Pala'
> Subject: Re: OCSP and CSL
> 
> 
> I think that CSL is a real need in several cases and that it
> cannot be easily substituted with CRL or OCSP.
> 
> First of all OCSP is out of question is it is not a trust
> source but rather a delivery channel for fast trust
> information. For non-repudiation service, it needs to be
> backed up by long-term data such as those of a CRL.

I hope not! OCSP responses are signed and can very much be used for
non-repudiation.

The benefit of a CRL over OCSP, is that you have all the revoked certs
in a single list, which is better for storage, IF YOU ARE INTERESTED
IN THE STATUS OF ALL THE CERTS. However, it isn't any more non-repudiable
than an OCSP response.


> 
> CRL is not good either due to revokation costs, that are
> among the highest ones in the PKI world. So I would like to
> minimize the number of revokations, especially if followed
> by a re-issue of the same certificate with a different key
> pair (especially difficult to work with those remote friends
> that have stored remotely my cert to send me encrypted
> e-mail while off-line)
> 
> Finally, I'd like to give my users the autonomous ability to
> suspend and then re-activate their certificates. Let's
> imagine the following scenario:
> - I don't want to take my smart-card with me and I leave it
> at the office (or I use a software PSE installed on my PC at
> work)
> - as I don't trust the company in charge of cleaning up the
> office (or may be my co-workers), I'd like to suspend the
> cert validity during week-ends, vacation, or even during
> night hours
> - I'd like to do this by just clicking on a button on a
> secure Web page (with client authentication) or sending a
> signed S/MIME message to an automatic responder
> - the responder (or the Web server) could in turn provide me
> with a one-time token to re-activate the cert at my will
> 
> There are other similar scenarios (like I forgot where I put
> my smart-card, and later I find it) where I don't want to
> have the burden of revoking and reissuing certs.
> 
> So I'd like to see this scenario supported by the following
> technical details:
> - a status code returned by an OCSP server to tell that a
> cert is SUSPENDED

This is already possible in OCSP - see my previous mail on this
topic.

> - a long term memory that a cert was suspended during a
> certain period of time; this should be provided by a CSL,
> which closely resembles the format (but not the meaning) of
> a CRL
> 
> Opinions?
> 
> Antonio Lioy
> 

Not quite sure what the CSL bought you - keeping track of all these
suspensions - particularly if every user is going to suspend their
cert on an average once a week will get pretty expensive very soon.

Regards,
Ambarish


Received: from taurus.polito.it (taurus.polito.it [130.192.3.60]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA24698 for <[e-mail]>; Thu, 27 Jan 2000 09:30:48 -0800 (PST)
Received: (qmail 17894 invoked from network); 27 Jan 2000 17:33:21 -0000
Received: from lioy.polito.it (HELO polito.it) (130.192.3.33) by taurus.polito.it with SMTP; 27 Jan 2000 17:33:21 -0000
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2000 18:32:29 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.6 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "'Massimiliano Pala'" <[e-mail]>
Subject: Re: OCSP and CSL
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF35CC68754270760B398E9D3"

This is a cryptographically signed message in MIME format.

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

I think that CSL is a real need in several cases and that it
cannot be easily substituted with CRL or OCSP.

First of all OCSP is out of question is it is not a trust
source but rather a delivery channel for fast trust
information. For non-repudiation service, it needs to be
backed up by long-term data such as those of a CRL.

CRL is not good either due to revokation costs, that are
among the highest ones in the PKI world. So I would like to
minimize the number of revokations, especially if followed
by a re-issue of the same certificate with a different key
pair (especially difficult to work with those remote friends
that have stored remotely my cert to send me encrypted
e-mail while off-line)

Finally, I'd like to give my users the autonomous ability to
suspend and then re-activate their certificates. Let's
imagine the following scenario:
- I don't want to take my smart-card with me and I leave it
at the office (or I use a software PSE installed on my PC at
work)
- as I don't trust the company in charge of cleaning up the
office (or may be my co-workers), I'd like to suspend the
cert validity during week-ends, vacation, or even during
night hours
- I'd like to do this by just clicking on a button on a
secure Web page (with client authentication) or sending a
signed S/MIME message to an automatic responder
- the responder (or the Web server) could in turn provide me
with a one-time token to re-activate the cert at my will

There are other similar scenarios (like I forgot where I put
my smart-card, and later I find it) where I don't want to
have the burden of revoking and reissuing certs.

So I'd like to see this scenario supported by the following
technical details:
- a status code returned by an OCSP server to tell that a
cert is SUSPENDED
- a long term memory that a cert was suspended during a
certain period of time; this should be provided by a CSL,
which closely resembles the format (but not the meaning) of
a CRL

Opinions?

Antonio Lioy
--------------msF35CC68754270760B398E9D3
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

MIIP9gYJKoZIhvcNAQcCoIIP5zCCD+MCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DjIwggT5MIID4aADAgECAgEBMA0GCSqGSIb3DQEBBAUAMGUxCzAJBgNVBAYTAklUMR4wHAYD
VQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8xNjA0BgNVBAMTLVBvbGl0ZWNuaWNvIGRpIFRv
cmlubyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDAxMTgxMjAwMDBaFw0wMDEyMzEx
MjAwMDBaMHcxCzAJBgNVBAYTAklUMR4wHAYDVQQKExVQb2xpdGVjbmljbyBkaSBUb3Jpbm8x
MTAvBgNVBAsTKERpcGFydGltZW50byBkaSBBdXRvbWF0aWNhIGUgSW5mb3JtYXRpY2ExFTAT
BgNVBAMTDEFudG9uaW8gTGlveTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyISyZRZK
mGqFfcdjcKJ7NegAKLDiLdlO9UK1pN4vJzGmrBtUqV6bKkfslCPCfRsULdpr4NgPwanqTxJn
WGS9TR/zV9fHv4cxDTLq/n49UnXI3nP0eTpHOi+y4D1VkTjI+1t6d0qggUIapxxXmfBpqP7R
/uxk2x4q07YxTBSjIoUCAwEAAaOCAiQwggIgMB8GA1UdIwQYMBaAFEbcLc3EM3GcgWtDoYzB
7HR2zgt7MB0GA1UdDgQWBBTHkFr7ivGI44U5A3zluh0EQ6nOLTAOBgNVHQ8BAf8EBAMCBPAw
gdoGA1UdIASB0jCBzzBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBBBgorBgEEAakHAgEBMDMwMQYIKwYBBQUH
AgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2EvaXQvY3BzLzEuMS8wRQYKKwYBBAGVYgEC
ATA3MDUGCCsGAQUFBwIBFilodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3BvbGl0by9jcHMv
MS4xLzAZBgNVHREEEjAQgQ5saW95QHBvbGl0by5pdDAMBgNVHRMBAf8EAjAAMDAGA1UdHwQp
MCcwJaAjoCGGH2h0dHA6Ly9jYS5wb2xpdG8uaXQvY3JsL2NybC5kZXIwgZUGCWCGSAGG+EIB
DQSBhxaBhElzc3VlZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcv
Y2Evcm9vdC9jcHMvMS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4x
LwogaHR0cDovL2NhLnBvbGl0by5pdC9jcHMvMi4xLzANBgkqhkiG9w0BAQQFAAOCAQEAGi5A
GJb2EoR6BpTSunNG/dPkEJ94RSzXiBXwomvdXtWZHQFeCUEsV07j+Imoqtrsm96Ub9Uhv+/A
2CBGvrsk2NhPXUQlcAvFs6KCYjXZK6B/2EyLKkm+6sW1sG2rmkQZmypQHodgwsY2/sHkLqPf
nDxokzsBj4uurnS26yEfQT+8EbcNOEyLeDdsQhgMFoTGFJON6zT6wBHflA7mOWzUQ1PJF8/Z
M2zDuq5AklIGcvF0gMaBJMQNSvQf9RMchxIoFVCGYqbmIOorADjXytE2qDtv9hPa/uq6IuU4
d/qcdPTgrGnzgnAlvE6uHnqo18EOA8koAKsrs5R23Jn7JGw4vDCCBN4wggPGoAMCAQICAQEw
DQYJKoZIhvcNAQEEBQAwUTELMAkGA1UEBhMCSVQxEDAOBgNVBAoTB0V1cm9QS0kxMDAuBgNV
BAMTJ0V1cm9QS0kgSXRhbGlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAcFw0wMDAxMTUx
MzUzMzdaFwswMTEyMzEwMDAwWjBlMQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25p
Y28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD+kQn+Hxvh
SJQs/5y7IdbpVg6+1yXgJ4l6Nguz7InoYZEcG2KBGPhunjalAmQ/DX8xovdQ8lx6nv49M5Xm
toMPoYsqe9ZoJhKc3sBiOTFpSp4noP8uzc+muM/95i5VMRtRSjUQB1rhmJ91y4sDenlMhZmd
Yb9Qtg57ggseOU5vDK39bSY4VcMg4Ang8jsOZnApVdmPsuS78Up1PsT4dWvqaRDE+CKXCpyr
9lKIot0kw3Tjc0wrixAV0TGH4IeCKeeUp6kk7sTbLvjMN7NPufwZgJUqcGvjtY2A4nWXJ94v
F6cK8zs39wBBVesa8saaeCIlTbjCjYXF0fazakgWY92hAgMBAAGjggGtMIIBqTAfBgNVHSME
GDAWgBSSQLydgXtL7H3j5uZ042HNGjYHqTAdBgNVHQ4EFgQURtwtzcQzcZyBa0OhjMHsdHbO
C3swDgYDVR0PAQH/BAQDAgH+MIGTBgNVHSAEgYswgYgwQwYKKwYBBAGpBwEBATA1MDMGCCsG
AQUFBwIBFidodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wQQYKKwYB
BAGpBwIBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nw
cy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL3d3dy5l
dXJvcGtpLm9yZy9jYS9pdC9jcmwvY3JsLmRlcjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVu
ZGVyIHBvbGljaWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEv
CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUA
A4IBAQCdIU0f6e4lWV8FHDj9Cdv/7YUqSx0JgcGXR22lnDkC+ouJMJ1lAsouuqxawA6pf+M9
KEUwOC6oEaF0K9GTY+BIddZbBKMfsUy5IiV9DOC7qwTfhm30cXLGjdPqx9bSxRnx/oz4lo33
FRQQd7OpsAL94fK+M23g6RRF49DxFb5L9bX2ube9ss6jyCWTxj/nwnNaadZRZzTRPawA9bKZ
XkhzLTs/iC+Rvfy6sp5n4t1Gq5paD2j6GIIIKQK6Iwwy3FemaxLxzFmU3Xa3wBddwGEP6EUP
v6y7kceldQP9sqfaKHz8mpzOycBi1PGLUgJVjbU7ubNpg9ZFRLYGbHbc6GKrMIIETzCCAzeg
AwIBAgIBAzANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRF
dXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDAwMTExMTgzNjI5WhcN
MDExMjMxMTIwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVyb1BLSTEwMC4GA1UE
AxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/7PzUFrMRRgJVYlUIyv7OfnEeq+arRzi/69G+6w8kuJz
e3/5LSuQ/OFdOYt5lagbv1f4neINDG2k2Mgt+h5UpEXLg1OXxgPP4JBo4iZYpi8KS7DEkd8n
428E3Pl7QjvVx/LeFi0zDlzUSuGRwzqOah/Hp9q6xjIdnG4xeCDcgmmEW1dzeUa56X8UNAy/
qNgBeN0+aJsD5LbLzsJEMNnIX4YZzv+7Fhb5mgNn/M3MKoNNAGY3la5eYy7P6Pedo/vCeyYd
pfhcEDlYBNdnEMKnsC7AayCjNaJLxaIQntRXbFEj3oSwH/a0X9yNzCE97KnlX+m+C5OamlvR
gkiRLBzLXwIDAQABo4IBQDCCATwwHwYDVR0jBBgwFoAUjNyLsaVKkOdOiHMYPJ3VXn7kss0w
HQYDVR0OBBYEFJJAvJ2Be0vsfePm5nTjYc0aNgepMA4GA1UdDwEB/wQEAwIBxjBOBgNVHSAE
RzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9y
Zy9jYS9yb290L2Nwcy8xLjEvMA8GA1UdEwEB/wQFMAMBAf8wOwYDVR0fBDQwMjAwoC6gLIYq
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMEwGCWCGSAGG+EIB
DQQ/Fj1Jc3N1ZWQgdW5kZXIgcG9saWN5OgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9y
b290L2Nwcy8xLjEvMA0GCSqGSIb3DQEBBAUAA4IBAQBR6o4zIMOxhKXGFYxDTbu+Jxmh/i/p
EH25kahS5SfFDtclgm/6dfqH6UQEKH7V1yfrhNNGOogVHe3b5m8FsrEf8Oyzr1+vlUVzC0m8
VpEzvyN6PqbwMSsaMP77xlSRe+6zB3iD2h3szHe95ATbML3pz2BDatPVh5ubGUh0LTEwOQkp
2rTn4/K7lUvlMw61X8+lpUtd2tLTGLLEUgcLMrGgZwG+csZ58TdFGGD6pNXyE/lgpWdqFlqH
vqtXoRey1JIj1pZ4xzsqWlUTNFXncSOBJElotbo8aFd3hT8IjdSaiwCqiyQ33V8EMVsQXIpw
NcOFQY7B49bCxpaY7onrGacoMYIBjDCCAYgCAQEwajBlMQswCQYDVQQGEwJJVDEeMBwGA1UE
ChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBUb3Jp
bm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0B
CQUxDxcNMDAwMTI3MTczMjMwWjAjBgkqhkiG9w0BCQQxFgQUo/hFiGh+H7mqBif8E6JRO5J+
PdswDQYJKoZIhvcNAQEBBQAEgYCCfkhmwgGf+PFFftf0Vyw1olXn0Dd7adNv2BbBrLW8d6Si
PXRrJhBUf21eXe7D85+4uTb5ey0Dkzwjc+GprX2tAfl7T9Cw61VM7vPDdsY3Kv1iScLHt/IY
HFcR93EMpjElrrPsxDB3yW5SaegrDSkmAeaHioa57a+q6+tSQHhY2w==
--------------msF35CC68754270760B398E9D3--



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22949 for <[e-mail]>; Thu, 27 Jan 2000 08:04:46 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhzvc08766; Thu, 27 Jan 2000 16:05:11 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA18483; Thu, 27 Jan 00 11:02:33 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA14343; Thu, 27 Jan 2000 11:05:10 -0500
Date: Thu, 27 Jan 2000 11:05:10 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: IETF and ISO alignment on Time Stamping
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

Roland,

Thanks for those examples.

I wonder if it is wise to include things like this in the same
standard.  The time stamp protocol as originally defined is based on
the rule that the TSA supplies and certifies the time stamp.

It seems to me that a service of the form "originator supplies a time, 
server verifies that it's 'close enough' and signs that conclusion" is 
an entirely different service.  I have my doubts on whether that
service has any merit, but whether or not it does, it doesn't seem
that it should be called the same thing.

One reason for my doubts: in this proposed scheme, if I have a
timestamp for T1 and you have one for T2, where T1 < T2, what does
this prove?  It is clear that it does not prove I generated my
timestamp earlier than you did.  The time relation proven by those two 
timestamps is actually looser than what you get from the original
specification: the request for T1 arrived at the server in the
interval T1 +/- K, and that for T2 during T2 +/- K, where K is the
"close enough" tolerance of that server.  Since K is necessarily
larger than the typical network latency, you don't get as tight an
ordering this way.

I think I'd rather see a spec that supports a single well-constructed
scheme, than an open-ended framework that can be used to construct all 
sorts of things.

	paul


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA22560 for <[e-mail]>; Thu, 27 Jan 2000 07:56:33 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id HAA13862; Thu, 27 Jan 2000 07:55:03 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <CMBLXGPC>; Thu, 27 Jan 2000 07:57:11 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Massimiliano Pala'" <[e-mail]>, Brian Ford <[e-mail]>, [e-mail]
Subject: RE: OCSP and CSL
Date: Thu, 27 Jan 2000 07:57:10 -0800
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_000E_01BF68B5.6CE8AB20"; 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_000E_01BF68B5.6CE8AB20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



>I cannot find my smartcard... I suppose I left it at my friend's house,
but I am not
>sure... So I ask for a suspesion of the service. Then I go to my
friend's house and
>I find my smartcard... so the certificate have never been in danger, I
can ask the
>CA Org not to revoke it and from the suspended state it returns to the
Valid state.


That is a requirement. Just because there is a technology that is
intended to meet a
requirement is no guarantee that it is a good idea to use that
technology.

Revoking certificates and reissue sounds like an excellent solution to
this problem.
The encryption key can be rolled over in the re-issued card, miniting
new signing
keys is never a problem.

I don't think that the change of the cert status back to valid has much
hope of 
being acurately and reliably tracked. Re-certificatrion is a slam dunk.

If there is a trully dynamic data source (such as when there is
authorization info
embedded in or associated with the cert) then a dynamic data protocol
such as OCSP
is appropriate. Trying to make static data structures such as CRLs and
Certs provide
a dynaic data service is like trying to speed up a tortoise by strapping
on an outboard 
motor.


		Phill

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJzCCA0Mw
ggKsoAMCAQICEB9+X+cD0eC/mSDca4kNSwQwDQYJKoZIhvcNAQEEBQAwXzELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAyIFB1YmxpYyBQcmltYXJ5
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk5MDIyNTAwMDAwMFoXDTA0MDEwNTIzNTk1OVow
ga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5l
bCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z5
6fy5WXixVcBTWLHPbxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiK
QNKaiRMpqbbV26d+4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCB
rTAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLmNybDARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh9o
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQD
AgEGMA0GCSqGSIb3DQEBBAUAA4GBAHn3Fc3oaFFZa/yppr3gHvu89D+Q3+f67eRU92E9VIsGupcy
Wh6rLO6vc6vHXdM/j/TOy05IYKKoYLY43qCm948p6BGszDl2UDzdOWwL8Vr9CFR23RZs9zFwuL8I
98kmBo7fuy8Zsba4tOg8SOgnsZcpIFcDnJtn+n1AxDh/GKqaMIIDxDCCAy2gAwIBAgIRAITO8g4A
ObV1VdoZh49S7YkwDQYJKoZIhvcNAQEEBQAwga0xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSYwJAYDVQQD
Ex1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDQy
MzU5NTlaMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwIrRh2Gi6jADVWsINvCX+hpU
NSQf6H2dyMNz09hG9ZEt2TjtlNewJnMq3pdQTf8iHL1wAJgMWCqxpHKPpbn3LXxg47Xf6X1OISFh
1fw7VMmkCZy7IvmiunBhT4ZGov0FZOwKP6ZYdle7FnNEfPClDZfAbKbxYwglsQQXlaCN/n8CAwEA
AaOB4jCB3zApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0xMTgwOAYDVR0f
BDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3JsMBEGCWCG
SAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH2h0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMC
AQYwDQYJKoZIhvcNAQEEBQADgYEAGUbO1GtwjlhciEI1rRZ9pQksqFOQ8fY9htfwznIUPSK88sMz
7dT8BZrgYyB1oxvvVRkPBnMhAmGupp5RK3jcW8iEi9XXts/V+D6XmLFEi6OYjqBL9pgxk7PwDN1R
dsqX5FZExvuUoUh9IkPMoMZceVX1Z4EbaJg0JESxmME6KF4wggQUMIIDfaADAgECAhADFO6qthx6
xbyOlTK51nT8MA0GCSqGSIb3DQEBBAUAMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQTAeFw05OTEyMjAwMDAwMDBaFw0wMDEyMTkyMzU5
NTlaMGwxETAPBgNVBAoTCFZFUklTSUdOMQswCQYDVQQLEwJIUTETMBEGA1UEAxMKUmVjaXBpZW50
czE1MDMGA1UEAxMscGJha2VyIChQaGlsaXAgSGFsbGFtLUJha2VyLCBWZXJpU2lnbiwgSW5jLikw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALd/SREjLYBTlweF+dTC4d5wU2rp2d//Cy/FL//g
23ysWCvYp29ARMppDrAaXqZWKMHq51lb11QpWgTWWe7YwxwiG0Avf5DZ2yvGWtMid+o8oB3G78W9
vifdjREi1b3OHUzMVZnxD3Pp4XYe4HAboA19HN8mCKuifJ+1tuK1HJrFAgMBAAGjggF0MIIBcDAJ
BgNVHRMEAjAAMFUGA1UdHwROMEwwSqBIoEaGRGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29t
L1ZlcmlTaWduSW5jRXhjaGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMMAsGA1UdDwQEAwIFoDAeBgNV
HREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEB
MIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwIC
MFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZl
cmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwHQYDVR0l
BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBABpQCkFcKNyY8Tl0U8eV
BWXif1ag5TsATjzvHELu9xHUwOEXyn/QYy7rM7Jl70IVVo6d1pgJGC/r2opNWgA2awwX94WxCf8d
qhcTP6Mc82BZw/IG7d26M72zY8tBu4FcTeshoOJXJN+1WCg287R9ySdKU05bGoe9tof1Fi+EyCGS
MYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBD
bGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MAkGBSsOAwIaBQCgggGMMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMDEyNzE1NTgyMVowIwYJKoZI
hvcNAQkEMRYEFCl7FXg+MOzxlE3bDBZ5m/ZvBKZPMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w
HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0
byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD
ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhADFO6qthx6xbyOlTK51nT8MA0GCSqGSIb3
DQEBAQUABIGAd9bwu26ZCm4Vvt0kN88agUVd/k1IrcXDFNev5WsWZV2HcM+kVVAAw6OrDDsFInNa
ecLUDBikwPx2egw/UwYoC+tD7AV9V4qhfxbTxiyG4rS2tfBLZVP4qCpF+a7MRtne07OYG2wYJnWd
Qu8pd68JxT4nJwrGIVzLIiG9AkL/p80AAAAAAAA=

------=_NextPart_000_000E_01BF68B5.6CE8AB20--



Received: from c004.sfo.cp.net (c004-h005.c004.sfo.cp.net [209.228.14.76]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA21740 for <[e-mail]>; Thu, 27 Jan 2000 07:24:16 -0800 (PST)
Received: (cpmta 17444 invoked from network); 27 Jan 2000 07:25:36 -0800
Received: from cs2889-175.austin.rr.com (HELO tuvit.net) (24.28.89.175) by smtp.tuvit.net with SMTP; 27 Jan 2000 07:25:36 -0800
X-Sent: 27 Jan 2000 15:25:36 GMT
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2000 09:27:32 -0600
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Paul Koning <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: IETF and ISO alignment on Time Stamping
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------1B556E6D00FBCD4CD8FD1699"

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

Paul,

the current document proposes in its part 2 a few mechanisms, none of
them under patent restrictions. I copied this part after my signature.
Sorry but i's quite some stuff and the figures are not included. If
interested I can also provide the whole doc but then it's PDF and it
does not reflect the results of the discussions we had last week. 

Roland

---------------------------------------
First Protocol (TSA checks T and signs receipt)
Step 1 (Originator): For a given document D, the originator creates a
time-stamp receipt using the current time T and a hash value H(D)
computed on the document D.  We assume that the originator has access to
a trusted clock that provides current time T.
Step 2 (Originator): The originator provides or transmits the time-stamp
receipt to a Time-Stamping Authority (TSA).
Step 3 (TSA): Optionally, the TSA performs a consistency check on the
received time-stamp receipt to ensure that the data contained in the
time-stamp receipt is consistent with data maintained at and controlled
by the TSA.
Step 4: (TSA): The TSA also verifies that the (now) current time T' and
the time value T in the time-stamp receipt are equal to within some
pre-established time window.  For example, it may be pre-arranged that
the time values T and T' are specified to the nearest whole minute,
e.g., by rounding up to the nearest whole minute.  That is, the clock
values are accurate to the nearest minute.  Thus, if T and T' are equal
with respect to year, month, day, hour, and minute, then they are
considered equal, even though they may not be equal if greater accuracy
were used.  (T and T' could differ by several seconds and still be equal
to the nearest whole minute.)  We assume that the TSA has access to a
trusted clock that provides current time T'.
Step 5 (TSA): If the time-stamp receipt is acceptable, the TSA signs the
time-stamp receipt with its private signature generation key.  We assume
that the TSA has a public and private key pair used for signing
time-stamp receipts.  The private signing key is available only to the
TSA, whereas the public key is made available to anyone so that they can
verify the signatures on time-stamp receipts generated by the TSA.  The
public key of the TSA can be stored in a certificate signed by a
Certification Authority (CA), so that the TSA's public key can validated
and, hence, trusted by those using that public key.
Step 6 (TSA): The TSA provides or transmits the signed time-stamp
receipt to the originator.






 			


Figure 1.  Time-Stamping in First Protocol

Differences:  In Fischer [1], the TSA operates on TSA-generated clock
signals.  In the alternative protocol, the TSA operates on clock signals
generated by the originator. In Haber [2, 3], the TSA creates the
receipt.  In the alternative protocol, the originator creates the
receipt.

4 Second Protocol (TSA computes age of time-stamped receipt)
Step 1 (Originator): For a given document D, the originator creates a
time-stamp receipt using the current time T and a hash value H(D)
computed on the document D.  We assume that the originator has access to
a trusted clock that provides current time T.
Step 2 (Originator): The originator provides or transmits the time-stamp
receipt to a Time-Stamping Authority (TSA).
Step 3 (TSA): Optionally, the TSA performs a consistency check on the
received time-stamp receipt to ensure that the data contained in the
time-stamp receipt is consistent with data maintained at and controlled
by the TSA.
Step 4 (TSA): The TSA computes a time difference, ?, between the time T
in the received time-stamp receipt and the now current time T', e.g., ?
= T' - T, where ? is referred to as an age value, or the age of the
document.  We assume that the TSA has access to a trusted clock that
provides current time T'.
Step 5 (TSA): If the received time-stamp receipt is acceptable, the TSA
creates an augmented time-stamp receipt from the computed age value of
the document and the received time-stamp receipt.
Step 6 (TSA): The TSA signs the augmented time-stamp receipt with its
private signature generation key.  We assume that the TSA has a public
and private key pair used for signing time-stamp receipts.  The private
signing key is available only to the TSA, whereas the public key is made
available to anyone so that they can verify the signatures on time-stamp
receipts generated by the TSA.  The public key of the TSA can be stored
in a certificate signed by a Certification Authority (CA), so that the
TSA's public key can validated and, hence, trusted by those using that
public key.
Step 7 (TSA): The TSA provides or transmits the signed augmented
time-stamp receipt to the originator.







 			


Figure 2.  Time-Stamping in Second Protocol


Differences: In Fischer [1], the TSA operates on a digital input and a
TSA-generated clock value.  In the alternative protocol, the TSA
operates on a digital input and a computed age value.  In Haber [2,3],
the TSA creates a receipt comprising a digital input and a TSA-generated
clock value.  In the alternative protocol, the TSA creates a receipt
comprising a digital input and a computed age value.
5 Third Protocol (TSA validates MAC on time-stamp receipt)
In the third protocol, the TSA provides both a "local" time-stamping
service and a "global" time-stamping service.  The distinction between
"local" and "global" is this: A local time-stamping service is one that
produces time-stamp receipts that can be validated only by the TSA that
generated them.  Therefore, only that particular TSA can "vouch" for the
time-stamp receipt.  A global time-stamping service is one that produces
time-stamp receipts that can be validated universally, by any entity. 
For our purposes, a local time-stamp receipt is one produced using a
keyed-hash function, or symmetric key cryptography; a global time-stamp
receipt is one produced, as is the usual case, using public key
cryptography.
A local time-stamping service could be beneficial in its own right. 
However, in the third protocol the local time-stamping service is shown
in combination with a global time-stamping service, where (in this case)
the local time-stamping service provides the originator with a local
time-stamp receipt that it can later choose to translate to a global
time-stamp receipt.  The fees for local and global time-stamping
services might be priced differently to provide customers with a wider
selection of time-stamping options.
Step 1 (Originator): The originator sends a hash value H(D) computed on
the document D to a TSA.  
Step 2 (TSA): The TSA creates a time-stamp receipt using the current
time T and H(D).  The TSA has access to a trusted clock that provides
current time T.
Step 3 (TSA): The TSA generates a secret random value K, e.g., a secret
key.  The TSA generates a Message Authentication Code (MAC) on the
time-stamp receipt using the generated secret value K.  Each generated K
is saved and later retrieved and used to validate the MAC (step 6 in the
protocol), after which K can be discarded.  The stored K is indexed
using any convenient method that links the time-stamp receipt to the
stored value of K, e.g., a sequential receipt number R.  Or, the MAC
(treated as a binary number) might be used to index a direct access file
composed of values of the form (MAC, K).
Step 4 (TSA): The TSA provides or transmits the time-stamp receipt and
MAC to the originator.
Step 5 (Originator): At a later time, the originator optionally provides
or transmits the time-stamp receipt and MAC, received at step 4 in the
protocol, to the TSA, requesting the TSA to certify the time-stamp
receipt.
Step 6 (TSA): The TSA locates K and uses it to validate the received
time-stamp receipt and MAC. If the time-stamp receipt and MAC are valid,
the protocol continues.
Step 7 (TSA): The TSA signs the received MAC with its private signature
generation key.  We assume that the TSA has a public and private key
pair used for signing time-stamp receipts.  The private signing key is
available only to the TSA, whereas the public key is made available to
anyone so that they can verify the signatures on time-stamp receipts
generated by the TSA.  The public key of the TSA can be stored in a
certificate signed by a Certification Authority (CA), so that the TSA's
public key can be validated and, hence, trusted by those using that
public key.
Step 8 (TSA): The TSA provides or transmits the signed MAC and K to the
originator.  K is provided to allow the originator to validate the
received signed MAC value.  
NOTE:  Once the TSA validates the time-stamp receipt and MAC, step 6 in
the protocol, there is no loss in security for the TSA to divulge K,
provided of course that its stored copy of K is erased or marked
"unusable."  Erasing K or marking it unusable will prevent a subsequent
spoofing attack in which the originator generates a new MAC on a forged
time-stamp receipt using K.
Step 9 (Originator): The originator validates the time-stamp receipt and
MAC received at step 4 in the protocol.  This is accomplished by using
the received value of K to generate a MAC on the time-stamp receipt and
then comparing the generated MAC with the MAC received at step 4 in the
protocol, for equality.  If the MAC received at step 4 in the protocol
is valid, the originator then validates the signed MAC, received at step
8 in the protocol, using the public key of the TSA.  Finally, the
originator forms a new record consisting of [time-stamp receipt, MAC, K,
and Signed MAC], which will allow time-stamp receipt to be validated by
any third party.







 			




 			


Figure 3.  Time-Stamping in Third Protocol
7.1 Third Protocol Variation
In a variation on the third protocol, the TSA does not store secret K
values.  Instead, the TSA has a secret master key KM that is uses to
encrypt the K values.  It has another secret key Kmac that it uses to
generate message authentication codes on the concatenation of K and
MAC.   In this case, there are two levels of MAC.  One is based on a
dynamic key K that the TSA later divulges to the originator, the other
is based on a persistent key Kmac that the TSA does not divulge to the
originator, or to anyone.
Steps 1 (Originator): unchanged. 
Step 2 (TSA): unchanged.  
Step 3 (TSA): The TSA additionally encrypts K under KM to produce the
encrypted key value eKM(K) and it additionally generates a message
authentication code, denoted MAC2, on K and MAC using Kmac.  In this
case, K and MAC are treated as data values and combined, e.g., by
concatenating the values. 
Step 4 (TSA): The TSA provides or transmits the time-stamp receipt, 
MAC, encrypted key eKM(K), and MAC2 to the originator.  
Step 5 (Originator): The originator provides or transmits the time-stamp
receipt,  MAC, eKM(K), and MAC2 to the TSA.  
Step 6 (Originator): The TSA retrieves K by decrypting the received
value of eKM(K) with its stored and retrieved copy of KM.  Next, the TSA
validates MAC2 by computing a message authentication code on K and MAC
using its stored copy of Kmac and comparing the computed message
authentication code with the received value of MAC2, for equality.  If
the combination of K and MAC (e.g., the concatenation of K and MAC) are
valid, the TSA validates the received time-stamp receipt and MAC using
K.  This is accomplished by computing a message authentication code on
the received time-stamp receipt using the retrieved and authenticated
value of K and then comparing the computed message authentication code
with the received MAC for equality.  If the validation operations
succeed, then the inputs are accepted as valid.  Otherwise, the values
are rejected.  
Step 7 (TSA): This step executes only if all validation operations in
step 6 succeed.  
Step 8 (TSA): This step is different in that there is no stored copy of
K at the TSA to be erased.  Divulging K does not subvert security, since
even with knowledge of K, the originator (or an adversary) cannot
generate a valid MAC2 without knowledge of Kmac, which is necessary in
order to spoof the TSA at step 6.  
Step 9 (Originator): unchanged. 






 			




 			

Figure 4.  Time-Stamping in the Third Protocol (Variation)
Differences: In Fischer [1], the TSA operates on two values, a digital
input and a TSA-generated clock value.  In the alternative protocol, the
TSA operates on one value, a digital input (i.e., a MAC).  In Haber [2,
3], the TSA certifies a receipt comprising an input digital document and
a clock value.  In the alternative protocol, the TSA certifies a digital
input (i.e., a MAC).
6 Fourth Protocol (TSA creates two records coupled via a nonce)
Step 1 (Originator): The originator sends a hash value H(D) computed on
the document D to a TSA.  
Step 2 (TSA): The TSA generates a nonce value, N.   
NOTE: It is important that N does not repeat for a given signing key. 
If N is randomly generated, we assume that the length of N is adjusted
to ensure adequate security.  If N is the value of an incrementing
counter or sequence number, we assume that it is large enough to ensure
that it does not repeat or cycle. 
Step 3 (TSA): The TSA creates a first receipt (N, T), which is a
time-stamp receipt, consisting of the nonce N and the current time T. 
The TSA has access to a trusted clock that provides current time T.
Step 4 (TSA): The TSA creates a second receipt (N, H(D)) consisting of
the nonce N and  H(D).
Step 5 (TSA): The TSA generates two signatures.  It signs the first
receipt (N, T), produced at step 3, with its private signature
generation key.  It signs the second receipt (N, H(D)), produced at step
4, with its private signature generation key.
Step 6 (TSA): The TSA provides or transmits the signed time-stamp
receipt (N, T) and the signed receipt (N, H(D)) to the originator.







 			


Figure 5.  Time-Stamping in Fourth Protocol

Differences: In Fischer [1], the TSA operates simultaneously on the
digital input and a TSA-generated clock value.  In the alternative
protocol, the TSA operates separately on the digital input and the
TSA-generated clock value.  In Haber [2, 3], the TSA certifies a receipt
comprising an input digital document and a clock value.  In the
alternative protocol, the TSA certifies two receipts, but these two
receipts are different from the single receipt in Haber.
7 Fifth Protocol (TSA computes time difference on time-stamp receipt
using the public verification key certificate)
The fifth protocol is similar to the second protocol, in that the TSA
computes a time difference, ?, between two time values.  But, in the
fifth protocol, ? is the difference between the time T recorded in the
public key certificate corresponding to the TSA's private signing key
and the now current time T', as measured by the TSA, i.e., ? = T - T'. 
Hence, in the fifth protocol, ? does not represent the age of document
D, but rather it is an arbitrary value, representing neither the current
time nor the age of the document.  Since the public key certificate,
containing T, is always available to validate a time-stamp receipt,
containing ?, one is assured that T can be readily determined.
NOTE:  The fifth protocol will operate in situations where the TSA's
public key certificate is signed by a CA or where it is signed by the
TSA using it's private signing key (self-signing).  In the latter case,
some cross certification of certificates may also be useful or
necessary, depending on how the protocol is operated.
Step 1 (Originator): The originator sends a hash value H(D) computed on
the document D to a TSA.  
Step 2 (TSA): The TSA computes a time difference, ?, between the time T
recorded in the public key certificate corresponding to the TSA's
private signing key and the now current time T', e.g., ? = T' - T.  The
TSA has access to a trusted clock that provides current time T'.
NOTE:  The value of T in the public key certificate is a value that may
be established by the TSA when requesting a certificate, it may be
determined by the CA or some combination of both the TSA and CA, or some
completely independent means.
Step 3 (TSA): The TSA creates a time-stamp receipt from the computed
value of ? and the received H(D).
Step 4 (TSA): The TSA signs the time-stamp receipt with its private
signature generation key.  We assume that the TSA has a public and
private key pair used for signing time-stamp receipts.  The private
signing key is available only to the TSA, whereas the public key is made
available to anyone so that they can verify the signatures on time-stamp
receipts generated by the TSA.  The public key of the TSA can be stored
in a certificate signed by a Certification Authority (CA), so that the
TSA's public key can be validated and, hence, trusted by those using
that public key.
Step 7 (TSA): The TSA provides or transmits the signed time-stamp
receipt to the originator.







 			


Figure 6.  Time-Stamping in Fifth Protocol
Differences: In Fischer [1], the TSA operates on a digital input and a
TSA-generated clock value.  In the alternative protocol, the TSA
operates on a digital input and a computed time difference.  In Haber
[2,3], the TSA creates a receipt comprising a digital input and a
TSA-generated clock value.  In the alternative protocol, the TSA creates
a receipt comprising a digital input and a computed time difference.  In
both cases, the signed time-stamp receipt does not contain enough
information to determine the current time T'.  The additional
information needed to compute T' is carried outside the signed
time-stamp receipt, in the TSA's public key certificate.
8 Sixth Protocol (time is completely determined by the public key
certificate) 
In the sixth protocol, the TSA's public key certificate alone determines
the time-stamp.  To illustrate the idea, suppose that the TSA issues a
new public key certificate daily.  That is, a new public and private
signing key pair is generated and used each day.  In this case, any
document signed with the TSA's daily signing key establishes the date
and time, to within 24 hours, when the document was received by the
TSA.  
The idea could be extended by generating new key pairs more frequently,
e.g., hourly, or in increments of a few minutes.  In such a case, the
TSA would not only return the signed value of H(D), but it would also
return the associated public key certificate, thereby allowing the
originator to verify the time-stamp.  In turn, the originator could
provide the signed H(D) and certificate to third parties interested in
validating the time-stamp.  The TSA would also escrow its public key
certificates in case users inadvertently lose or misplace them.  
For  TSAs with high volumes of traffic, the sixth protocol could be
attractive, since the time information is completely carried in the
certificate, and hence users only need to handle signed documents, in
the usual sense.
The TSA still needs to have access to a trusted clock to ensure that
keys roll over at the proper times.
Differences: In Fischer [1], the TSA operates on a digital input and a
TSA-generated clock value.  In Haber [2,3], the TSA creates a receipt
comprising a digital input and a TSA-generated clock value.  In the
alternative protocol, the TSA merely signs the digital input H(D) from
the originator.  The certificate contains a start and stop time, and is
signed.  But, this is not a time-stamp, since the times established in
the certificate are not indicative of the current time when the
certificate is generated, received, or signed.
9 References
A. M. Fischer, "Public/Key Date-Time Notary Facility," U.S. Patent
5,001,752, issued March 19, 1991.
S. A. Haber and W. S. Stornetta, Jr., "Method for secure time-stamping
of digital documents," U. S. Patent 5,136,647, issued August 4, 1992.
S. A. Haber and W. S. Stornetta, Jr., "Method for secure time-stamping
of digital documents," U. S. Patent Re. 34,954, issued May 30, 1995.
B. Schneier, "Applied Cryptography" (second edition), John Wiley & Sons,
Inc., 1996, pp. 75-78.


Paul Koning wrote:
> 
> Could you give an example of an application for the proposed Mechanism
> Identifier field?  While more generality can be a good thing, it's
> useful to have an example to justify added stuff.
> 
>         paul
--------------1B556E6D00FBCD4CD8FD1699
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------1B556E6D00FBCD4CD8FD1699--



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 HAA21724 for <[e-mail]>; Thu, 27 Jan 2000 07:24:14 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id HAA20943; Thu, 27 Jan 2000 07:22:03 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 27 Jan 2000 09:56:33 -0500
To: Brian Ford <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: OCSP and CSL
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <v04220806b4b3c9cb3dd3@[128.33.238.94]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

A particular client can always refuse to accept certificates from a 
particular CA.  I would assume that a CA that does not have a certificate 
path back to a trust anchor is one such example.  Other rules could also 
cause a client to reject certificates from a CA.  These rules have nothing 
whatsoever to do with suspended certificates or revoked certificates.

In general, the CA that issues a certificate is responsible for suspending 
it or revoking it.  The CA can delegate this responsibility with the CRL 
Distribution Point extension, but generally the CA retains this responsibility.

Russ


At 01:19 PM 01/26/2000 -0500, Brian Ford wrote:
>Ben,
>
>It comes down to your interpretation of suspend versus revoke.  If the
>network between a client and the CA goes bad and you cannot reach a CA for
>a period of time an argument could be made to "suspend" certs from that CA.
>  If the user leaves the employ of a company one would hope that their cert
>would be "revoked".  No?
>
>Regards,
>
>Brian



Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21337 for <[e-mail]>; Thu, 27 Jan 2000 07:09:21 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhzuy13627; Thu, 27 Jan 2000 15:09:25 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA17374; Thu, 27 Jan 00 10:06:43 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA14121; Thu, 27 Jan 2000 10:09:20 -0500
Date: Thu, 27 Jan 2000 10:09:20 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: IETF and ISO alignment on Time Stamping
References: <[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

Could you give an example of an application for the proposed Mechanism 
Identifier field?  While more generality can be a good thing, it's
useful to have an example to justify added stuff.

	paul


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03183 for <[e-mail]>; Thu, 27 Jan 2000 04:05:08 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id NAA22536 for <[e-mail]>; Thu, 27 Jan 2000 13:06:26 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2000 13:07:50 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP and CSL final report (?).
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0BCB928B87CFB4B570BDF016"

This is a cryptographically signed message in MIME format.

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

Ok, so, as far as I can understand the final proposed solution would be to
use the the OCSP server to send responses with extentions on the reason
(certificateHold).

I do think that the 'suspended' state could be bettere handled and some few
lines could be spent on the drafts (OCSP ???).

I'll follow your advice. Thank you all for the replies.

C'you,

	Massimiliano Pala ([e-mail])


P.S.: If you have more ideas on this, please send me two lines... :-D
--------------ms0BCB928B87CFB4B570BDF016
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI3MTIwNzUwWjAjBgkqhkiG9w0BCQQxFgQUx41slBv+/Xra4uZxt3w+dRz1aScw
DQYJKoZIhvcNAQEBBQAEgYClEATckoPtPaLE8ie4RArIMtaybMBkuGj9pVDgVJ4hzsYNBqZX
YrRyBrr9GNufLy6R8/EWCX+wykbqmx70AFdEm+dcJ+D4tMttx0hZqtNXg7ZmmD6549It7NoA
mKPXnVgLao/NgCstQD4IqSCAx16ZR4tHnbeMuFstxrlNgdydaw==
--------------ms0BCB928B87CFB4B570BDF016--



Received: from aspams52.cai.com (aspams52.cai.com [155.35.248.76]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00982 for <[e-mail]>; Thu, 27 Jan 2000 03:41:17 -0800 (PST)
Received: by aspams52.cai.com with Internet Mail Service (5.5.2650.21) id <DV4JF4C9>; Thu, 27 Jan 2000 22:43:39 +1100
Message-ID: <[e-mail]>
From: "Grant, Alistair" <[e-mail]>
To: Massimiliano Pala <[e-mail]>, [e-mail]
Subject: RE: OCSP and CSL
Date: Thu, 27 Jan 2000 22:43:46 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Massimiliano Pala wrote:
> The CSLs, let's call them CSL to distinguish from CRLs, have 
> sense in env
> where there is a time gap between the 'request for cert 
> revoking' by the
> user and the effective revoking by the CA: this is obvious if 
> you consider
> structures where the main CA computer is disconnected from 
> any network.
> 
> Would you allow a certificate to be used when a user says it 
> could have
> been compromised ? You can not either say it is revoked 
> because it is not
> (CRLs do not report it) and there is no way to verify it till the new
> CRL is issued.
> 
> With some instrument like the proposed CSLs (that is only a 
> proposal, I am
> not saying it is the best or the only solution to the 
> problem, I am obviously
> open to EVERY comment... :-D and hopefully to some better 
> solutions) you can
> say, from the moment the user signals a danger the usage of 
> the certificate
> is compromised and that itself is to be considered in a 
> 'freezed' state.
> 
> Am I completely out of the target ? What do you think about 
> this problem ?
> Thanks for the comments you sent.

Unless I am misunderstanding your proposal, I would have thought that CSL's
would suffer the same problems as CRL's if the CA is off-line (disconnected
from the network).

In any case, this sounds like you are looking for (near) real-time
revocation.  In that case, you might like to consider using an on-line
protocol such as OCSP (RFC2560).  OCSP returns a status of 'good', 'revoked'
or 'unknown'.  In the case of 'revoked', there is a revocation reason and
time.  As has already been pointed out by Tom Gindin, one of the reasons is
certificateHold, i.e. suspended.  OCSP Responders may determine the status
of the certificate in a number of ways, e.g. CRL or status lookup in a
directory.

Hope this helps.


Cheers,

Alistair Grant
Computer Associates International.
Phone:    [phone]
Mobile:   [phone]
Fax:      [phone]
E-Mail:   [e-mail]


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26489 for <[e-mail]>; Thu, 27 Jan 2000 03:08:23 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id MAA19690; Thu, 27 Jan 2000 12:09:36 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2000 12:11:00 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian Ford <[e-mail]>, [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDC7B14B66D1740A636FDBFB7"

This is a cryptographically signed message in MIME format.

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

Brian Ford wrote:
> 
> Massimiliano,
> 
> I'm no expert but my read of the RFCs is a little different.
> 
> The CSL which you describe seems to me like a subset of a CRL.  If you made
> a query at a CA for that info I'd guess that the current CRL at the CA
> would be parsed to deliver your answer.  The response would be in the form
> of a list.  So depending on the CRL lifetime, that info may (or may not) be
> current.
> 
> Using OCSP on the other hand the request would be made to a CA regarding a
> specific cert.  The CA would be queried directly for a response (so the
> info would be current).  The response would be either good, revoked or unknown.
> 
> Comments?
> 
> Regards,
> 
> Brian
> 

Sorry, probably I left out the main point. It is true that this can be done with
a subset of CRLs but if you refer to the network-disconnected CA model, the revokation
gets with some delay from the moment the user submits a 'request for revoking'.
The point is: can I sign a CRL using not the CA certificate ??? Will this be trusted
by today applications ?? Also consider this:

I cannot find my smartcard... I suppose I left it at my friend's house, but I am not
sure... So I ask for a suspesion of the service. Then I go to my friend's house and
I find my smartcard... so the certificate have never been in danger, I can ask the
CA Org not to revoke it and from the suspended state it returns to the Valid state.

Another question I have for the list: it is allowed signing a CRL with a revokation
date prior to the time of the effective revoking ??? Let's say I have a request for
revoking, can I use the time of the receiving of the request instead of the time
when the CA Operatorphisically does the revokation ???

C'you,

	Massimiliano Pala ([e-mail])
--------------msDC7B14B66D1740A636FDBFB7
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI3MTExMTAwWjAjBgkqhkiG9w0BCQQxFgQUc0ksqICpWHxotNs0EyYoz+xaEdsw
DQYJKoZIhvcNAQEBBQAEgYBQ4HmG5uCvAxNl7IhS2hIQIK70tnyHdaamZyZrgLvB+zivFGw/
LNjy4HFUp1qkppp1EAoBwm7GDs7RBtTZmNOY7nLP6HQLGXmy0qe0+rBK61+DjzGN8f2Z7HK0
Iu1MxOClRZs3QIhD3TXL82HYoZ5nRMbnX7jtbGZUhJT1Mnovdw==
--------------msDC7B14B66D1740A636FDBFB7--



Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26004 for <[e-mail]>; Thu, 27 Jan 2000 02:59:19 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id LAA19228; Thu, 27 Jan 2000 11:59:50 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 27 Jan 2000 12:01:13 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Laurie <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <v04220806b4b3c9cb3dd3@[128.33.238.94]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms656394F663D0DE7BB525AA82"

This is a cryptographically signed message in MIME format.

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

Ben Laurie wrote:

> Since a suspended certificate is as unusable as a revoked one, it makes
> no sense to me to permit _any_ differences between the creation of a
> suspension and the creation of a revocation. Which means that there's
> little point in supporting suspension at all.
> 
> Cheers,
> 
> Ben.

But the point is: the certificate is not yet revokable but its state it's
been reported to be 'probably compromised'. It would be useful to get the
server(s) not allowing critical data transmission using such keys...

(refer to a model where the ca machine is disconnected for security
porpouses).

C'you,

	Massimiliano Pala ([e-mail])
--------------ms656394F663D0DE7BB525AA82
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI3MTEwMTEzWjAjBgkqhkiG9w0BCQQxFgQUYBMIljFv44pQ/BVsijt/b7nP2Sow
DQYJKoZIhvcNAQEBBQAEgYA9SN2oPlb4RXJ2iuBib0+N9I3sNOfISDAi0lX8u4o74oBN8xB9
H9FvdRV1yffL7BLDQfUVVeieaRQZYQj4LDIXP5uukjoKBQdYmjQgIddHDKAawdWLh1qqTHEY
YdMcFKw2PTQy70jY4B2vWVhEODBFsZHcp2Rp1WLpXq1fFceESg==
--------------ms656394F663D0DE7BB525AA82--



Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA15066 for <[e-mail]>; Thu, 27 Jan 2000 00:37:55 -0800 (PST)
Received: (qmail 43132 invoked from network); 27 Jan 2000 08:39:39 -0000
Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 27 Jan 2000 08:39:39 -0000
Received: (qmail 11682 invoked from network); 27 Jan 2000 08:39:38 -0000
Received: from storas03.dynas.se (10.129.29.103) by spirit.dynas.se with SMTP; 27 Jan 2000 08:39:38 -0000
Date: Thu, 27 Jan 2000 09:40:20 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[e-mail]>
To: [e-mail], Peter Gutmann <[e-mail]>
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-X-Sender: magnus@[172.16.1.10]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I could not agree more. IMHO, these context tags adds confusion,
bits-on-the-wire, and makes type-checking harder. Please remove them.

-- Magnus

On Thu, 27 Jan 2000, Peter Gutmann wrote:

> 
> >This document is hereby issued for 14-day WG Last Call.  Please submit any
> >comments to this list.
> 
> I have the usual ASN.1 style complaint, the whole thing contains large amounts
> of unnecessary tagging which obscures the underlying data types (as well as 
> making the encoding more complex than necessary).  For example in TimeStampReq:
> 
> TimeStampReq ::= SEQUENCE  {
>      version                      Integer  { v1(1) },
>      messageImprint               MessageImprint,
>        --a hash algorithm OID and the hash value of the data to be
>        --time stamped
>      reqPolicy                [0] PolicyInformation      OPTIONAL,
>      nonce                    [1] Integer                OPTIONAL,
>      certReq                  [2] BOOLEAN           DEFAULT FALSE,
>      extensions               [3] EXPLICIT Extensions    OPTIONAL
> }
> 
> only the extensions actually need a tag, and that doesn't need to be explicit
> (all the elements except the last are distinct, why are they given context-
> specific tags?).  In addition the primitive types should really be 
> capitalised, ie use INTEGER instead of Integer.  For the rest of the PDU's,
> you can remove almost all the tags without causing any problems, which both
> simplifies the encoding and makes the encoded data easier to work with (for
> example you can actually see an INTEGER rather than just an opaque [0] blob).
> 
> Peter.
> 
> 
> 

-- Magnus
Magnus Nystrom		Email: [e-mail]
RSA Laboratories



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA05425 for <[e-mail]>; Wed, 26 Jan 2000 21:23:53 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLVQ6B>; Wed, 26 Jan 2000 21:18:15 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Massimiliano Pala'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: OCSP and CSL
Date: Wed, 26 Jan 2000 21:18:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Massimiliano,
    Yes, you can indicate that a certificate is suspended
in OCSP - you return a status of revoked and in
singleExtensions, include a reasonCode extension, with a
CRLReason of certificateHold.

Hope this clarifies the issue.

Regards,
Ambarish

P.S. This extension is not explicitly mentioned in the draft, but we
do say that we support all CRL Entry Extensions (see section 4.4.5
of RFC 2560).


---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Massimiliano Pala [mailto:[e-mail]]
> Sent: Tuesday, January 25, 2000 4:39 PM
> To: Russ Housley
> Subject: Re: OCSP and CSL
> 
> 
> Russ Housley wrote:
> > 
> > Massimiliano:
> > 
> > I do not think that we should do anything to encourage CAs 
> to suspend
> > certificates.  This feature adds significant complexity to the whole
> > system, and we should discourage it's use.
> > 
> > Russ
> > 
> 
> You are right saying that adding complexity should be 
> discouraged, by the
> way I suggested them because we need something like that (I 
> am from the
> OpenCA project). Let me explain in more details why I think something
> similar could come in handy.
> 
> The CSLs, let's call them CSL to distinguish from CRLs, have 
> sense in env
> where there is a time gap between the 'request for cert 
> revoking' by the
> user and the effective revoking by the CA: this is obvious if 
> you consider
> structures where the main CA computer is disconnected from 
> any network.
> 
> Would you allow a certificate to be used when a user says it 
> could have
> been compromised ? You can not either say it is revoked 
> because it is not
> (CRLs do not report it) and there is no way to verify it till the new
> CRL is issued.
> 
> With some instrument like the proposed CSLs (that is only a 
> proposal, I am
> not saying it is the best or the only solution to the 
> problem, I am obviously
> open to EVERY comment... :-D and hopefully to some better 
> solutions) you can
> say, from the moment the user signals a danger the usage of 
> the certificate
> is compromised and that itself is to be considered in a 
> 'freezed' state.
> 
> Am I completely out of the target ? What do you think about 
> this problem ?
> Thanks for the comments you sent.
> 
> C'you,
> 
> 	Massimiliano Pala ([e-mail])
> 


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA24900 for <[e-mail]>; Wed, 26 Jan 2000 19:02:39 -0800 (PST)
Received: from postal-gw2.verisign.com (mailhost2.verisign.com [208.206.241.102]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id TAA24111; Wed, 26 Jan 2000 19:01:20 -0800 (PST)
Received: by postal-gw2.verisign.com with Internet Mail Service (5.5.2650.21) id <DF18G403>; Wed, 26 Jan 2000 19:03:28 -0800
Message-ID: <[e-mail]>
From: Michael Myers <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, Massimiliano Pala <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Wed, 26 Jan 2000 19:03:27 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Steve, Russ, Massimiliano:

I agree that CRL-based suspension warrants deprecation.  However, we should
not rush to deprecate the notion of certificate suspension in general.

In actual practice, OCSP is being used to achieve certificate suspension
through the use of a state variable in a CA's certificate management
database.  The practice is directly analogous to velocity management of
credit cards, calling cards and the like.

The state variable of a certificate suspected of being unreliable is set to
an equivalent of "revoked", leading to a "revoked" OCSP response.  If it is
ultimately determined that the certificate is reliable (e.g. it is in fact
the subscriber making all those online purchases), the state variable is
reset back to an equivalent of "good".  This achieves the effect of
suspension with no additional complexity.

This further illustrates the fact that OCSP deployments should not depend
upon CRLs.

Mike




> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Wednesday, January 26, 2000 10:36 AM
> To: Massimiliano Pala

. . . .

> >I was also thinking about the OCSP service: if I can remember well 
> >the possible states
> >for a given certificate can be Good/Revoked or Unknown only, right 
> >??? What about,
> >if there is not yet, adding a 'Suspended' state ???
> 
> I don't recall what OCSP says re suspended certs as a form of 
> revoked cert.
> 
> Finally, I have to agree with Russ. I am not fond of suspension as a 
> revocation declaration and since 2459 disparages use of this 
> facility, I don't think we should spend lots of time on this issue.
> 
> Steve
> 


Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA22872 for <[e-mail]>; Wed, 26 Jan 2000 18:41:05 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA29740; Thu, 27 Jan 2000 12:46:07 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <DV4HBKWT>; Thu, 27 Jan 2000 13:42:56 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Roland Mueller <[e-mail]>, Michael Zolotarev <[e-mail]>
Cc: PKIX mailing group <[e-mail]>
Subject: RE: IETF and ISO alignment on Time Stamping
Date: Thu, 27 Jan 2000 13:42:56 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

"...primarily intended for something else..."? 
The policy IMHO is specifically used by the client to specify a particular
variant of a general service, provided by the server. Generating ISO or
IETF-flavored token is precisely a variant of a general service.

A server can use a policy, or a combination of a policy and a policy
qualifier. I personally would favor using a qualifier with a policy, like
id_timestamp-body-ISO and id_timestamp-body-IETF.

Example:
A TSA Server declares: Policy X.Y.Z will generate a timestamp with the most
precise timing information I have. Use the qualifier id-timestamp-body-ISO
to obtain the ISO-formed response, and the id_timestamp-body-IETF otherwise.

Defaults... Hmm. If no policy (and no qualifiers, therefore) are defined in
the request, the TSA should use the default policy (of course) and IETF
wrapping of the response. But I can compromise here :).

Michael

> -----Original Message-----
> From: Roland Mueller [mailto:[e-mail]]
> Sent: Thursday, January 27, 2000 1:21 PM
> To: Michael Zolotarev
> Cc: PKIX mailing group
> Subject: Re: IETF and ISO alignment on Time Stamping
> 
> 
> Michael,
> 
> you are right but taking into account that there are other mechanisms
> then this way would be cleaner and not a way of using a field that's
> primarily intended for something else.
> 
> Roland
> 
> Michael Zolotarev wrote:
> > 
> > The current timestamping draft defines the Policy field in 
> the request
> > message. I believe it can be successfully used instead of 
> introducing the
> > MechanismIdentifier field.
> > 
> > Michael
> > 
> > > -----Original Message-----
> > > From: Roland Mueller [mailto:[e-mail]]
> > > Sent: Thursday, January 27, 2000 6:52 AM
> > > To: IETF-PKIX
> > > Cc: Zuccherato, Robert; Manas, Jose A.; Matyas, Mike; Quisquater,
> > > Jean-Jaques; Haber, Stuart; Doonan, Wes; Lai, Xuejia; 
> Chawrun, Mike
> > > Subject: IETF and ISO alignment on Time Stamping
> > >
> > >
> > > I write to the PKIX working group as the editor of the ISO
> > > working draft
> > > on time stamping. ISO SC27 has begun work on an 
> International Standard
> > > on time stamping (ISO Working Draft 18014) in 1998.  The 
> ISO SC27 WG2
> > > adhoc group on time stamping met recently and discussed the
> > > differences
> > > between the IETF draft and ISO WD 18014, especially with
> > > respect to data
> > > structures, and came to the following conclusions.
> > >
> > > The apporach of WD 18014 has been to be compatible with 
> the IETF PKIX
> > > working
> > > group's Time Stamp Protocol document. It is understood 
> that the PKIX
> > > approach
> > > focuses on digital signatures as the means to bind 
> information within
> > > time stamp
> > > tokens. The motivation for the protocol is well 
> understood. The SC 27
> > > WG2 group
> > > has always attempted to align their work as much as 
> possible with the
> > > respective
> > > valid IETF drafts.
> > >
> > > However, the members of the ISO SC27 WG2 adhoc group have taken a
> > > broader and
> > > more generic approach to accommodate the diversity of time stamp
> > > mechanisms that
> > > exist within the community. This includes the standardization
> > > of other
> > > mechanisms beyond the particular mechnisms to be 
> standardised by the
> > > PKIX
> > > working group.
> > >
> > > Therefore the WG2 adhoc group would like to offer the
> > > following proposal
> > > to the
> > > PKIX working group to solve the interoperability issues
> > > present. It is
> > > understood that this proposal reaches the IETF working group at an
> > > extremely
> > > late stage in its standardisation cycle. Even at this late
> > > time the SC27
> > > WG2
> > > adhoc group feels that it is important to achieve 
> interoperability. It
> > > is also
> > > realised that the adoption of this proposal may cause a 
> delay in the
> > > IETF
> > > process. However, the PKIX working group may consider whether
> > > the issue
> > > of
> > > interoperability is more important than the timeliness of the
> > > document.
> > >
> > > The ISO SC27 WG adhoc group's proposal can be characterised in the
> > > following clause.
> > >
> > >
> > > IETF - ISO Interoperability
> > > ---------------------------
> > >
> > > Summary
> > > -------
> > >
> > > To achieve interoperability between ISO and IETF proposed 
> standards,
> > > the ISO has adjusted its messages and tokens in order to align as
> > > closely as possible with the IETF standard, while still 
> serving the
> > > diverse interests of the group.  The following summarizes the
> > > remaining areas to be resolved between the two standards, 
> along with
> > > an exact specification of the proposed changes.
> > >
> > > 1. Add one field in TimeStampReq and TSTInfo
> > > 2. Add one additional error code
> > > 3. Adjust encapsulation of TimeStampToken
> > >
> > >
> > > Detail
> > > ------
> > >
> > > 1. TimeStampReq, TSTInfo
> > >
> > > The ISO has adjusted its timestamp request message and 
> timestamp info
> > > structures to be compatible with the corresponding IETF 
> structures,
> > > with the addition of a single "mechanism" field.  This field
> > > identifies which mechanism is used to form the timestamp 
> token, either
> > > the IETF mechanism or any of the proposed ISO mechanisms. 
>  In the IETF
> > > standard, only the IETF mechanism would need be 
> recognized.  The field
> > > contains an OID identifying the timestamping mechanism, 
> and is added
> > > to the structures as follows:
> > >
> > > MechanismIdentifier ::= OBJECT IDENTIFIER
> > >
> > > TimeStampReq ::= SEQUENCE {
> > >       ...
> > >       messageImprint  MessageImprint,
> > >       mechanism       MechanismIdentifier,  -- addition
> > >       ...
> > > }
> > >
> > > TSTInfo ::= SEQUENCE {
> > >       ...
> > >       policy          PolicyInformtion,
> > >       mechanism       MechanismIdentifier,  -- addition
> > >       ...
> > > }
> > >
> > > An OID would also be allocated for use in identifying the IETF
> > > mechanism.
> > >
> > > 2. PKIFailureInfo
> > >
> > > If the TSA does not support the requested mechanism it returns an
> > > error code in the "status" field of the TimeStampResp 
> message.  A new
> > > error code is added to PKIFailureInfo to support this, as follows:
> > >
> > > PKIFailureInfo ::= BITSTRING {
> > >       ...
> > >       mechanismNotSupported (18),  -- addition
> > >       -- the TSA does not support the requested mechanism.
> > > }
> > >
> > > 3. TimeStampToken
> > >
> > > The ISO has modified its timestamp token structure to interoperate
> > > with the IETF token, with an adjustment to the specified
> > > encapsulation.  The ISO supports alternate token 
> encapsulations and
> > > hence defines the token more abstractly.  The IETF mechanism will
> > > continue to use the specified SignedData construct [CMS], 
> encoded as
> > > an external signature (RFC 2630 pp. 9) in the signatureInfo field
> > > below:
> > >
> > > TSTSignature ::= OCTET STRING
> > >
> > > TimeStampToken ::= SEQUENCE {
> > >         tokenInfo       TSTInfo,
> > >         signatureInfo   TSTSignature OPTIONAL  -- SignedData,
> > > DER-encoded as
> > >                                                -- 
> external signature
> > > }
> > >
> > > The signature is computed on the TSTInfo structure as 
> before, and the
> > > signature data is inserted in a SignedData construct.  
> The construct
> > > is then encoded in the signatureInfo field as an external 
> signature
> > > (RFC 2630, pp. 9).  The existing content type identifier 
> is retained.
> > >
> > > Greetings
> > >
> > > Roland
> > >
> 


Received: from c004.sfo.cp.net (c004-h006.c004.sfo.cp.net [209.228.14.77]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA20459 for <[e-mail]>; Wed, 26 Jan 2000 18:18:04 -0800 (PST)
Received: (cpmta 6684 invoked from network); 26 Jan 2000 18:19:30 -0800
Received: from cs2889-175.austin.rr.com (HELO tuvit.net) (24.28.89.175) by smtp.tuvit.net with SMTP; 26 Jan 2000 18:19:30 -0800
X-Sent: 27 Jan 2000 02:19:30 GMT
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2000 20:21:29 -0600
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Michael Zolotarev <[e-mail]>
CC: PKIX mailing group <[e-mail]>
Subject: Re: IETF and ISO alignment on Time Stamping
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------69D7033562DFAF3761A146E5"

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

Michael,

you are right but taking into account that there are other mechanisms
then this way would be cleaner and not a way of using a field that's
primarily intended for something else.

Roland

Michael Zolotarev wrote:
> 
> The current timestamping draft defines the Policy field in the request
> message. I believe it can be successfully used instead of introducing the
> MechanismIdentifier field.
> 
> Michael
> 
> > -----Original Message-----
> > From: Roland Mueller [mailto:[e-mail]]
> > Sent: Thursday, January 27, 2000 6:52 AM
> > To: IETF-PKIX
> > Cc: Zuccherato, Robert; Manas, Jose A.; Matyas, Mike; Quisquater,
> > Jean-Jaques; Haber, Stuart; Doonan, Wes; Lai, Xuejia; Chawrun, Mike
> > Subject: IETF and ISO alignment on Time Stamping
> >
> >
> > I write to the PKIX working group as the editor of the ISO
> > working draft
> > on time stamping. ISO SC27 has begun work on an International Standard
> > on time stamping (ISO Working Draft 18014) in 1998.  The ISO SC27 WG2
> > adhoc group on time stamping met recently and discussed the
> > differences
> > between the IETF draft and ISO WD 18014, especially with
> > respect to data
> > structures, and came to the following conclusions.
> >
> > The apporach of WD 18014 has been to be compatible with the IETF PKIX
> > working
> > group's Time Stamp Protocol document. It is understood that the PKIX
> > approach
> > focuses on digital signatures as the means to bind information within
> > time stamp
> > tokens. The motivation for the protocol is well understood. The SC 27
> > WG2 group
> > has always attempted to align their work as much as possible with the
> > respective
> > valid IETF drafts.
> >
> > However, the members of the ISO SC27 WG2 adhoc group have taken a
> > broader and
> > more generic approach to accommodate the diversity of time stamp
> > mechanisms that
> > exist within the community. This includes the standardization
> > of other
> > mechanisms beyond the particular mechnisms to be standardised by the
> > PKIX
> > working group.
> >
> > Therefore the WG2 adhoc group would like to offer the
> > following proposal
> > to the
> > PKIX working group to solve the interoperability issues
> > present. It is
> > understood that this proposal reaches the IETF working group at an
> > extremely
> > late stage in its standardisation cycle. Even at this late
> > time the SC27
> > WG2
> > adhoc group feels that it is important to achieve interoperability. It
> > is also
> > realised that the adoption of this proposal may cause a delay in the
> > IETF
> > process. However, the PKIX working group may consider whether
> > the issue
> > of
> > interoperability is more important than the timeliness of the
> > document.
> >
> > The ISO SC27 WG adhoc group's proposal can be characterised in the
> > following clause.
> >
> >
> > IETF - ISO Interoperability
> > ---------------------------
> >
> > Summary
> > -------
> >
> > To achieve interoperability between ISO and IETF proposed standards,
> > the ISO has adjusted its messages and tokens in order to align as
> > closely as possible with the IETF standard, while still serving the
> > diverse interests of the group.  The following summarizes the
> > remaining areas to be resolved between the two standards, along with
> > an exact specification of the proposed changes.
> >
> > 1. Add one field in TimeStampReq and TSTInfo
> > 2. Add one additional error code
> > 3. Adjust encapsulation of TimeStampToken
> >
> >
> > Detail
> > ------
> >
> > 1. TimeStampReq, TSTInfo
> >
> > The ISO has adjusted its timestamp request message and timestamp info
> > structures to be compatible with the corresponding IETF structures,
> > with the addition of a single "mechanism" field.  This field
> > identifies which mechanism is used to form the timestamp token, either
> > the IETF mechanism or any of the proposed ISO mechanisms.  In the IETF
> > standard, only the IETF mechanism would need be recognized.  The field
> > contains an OID identifying the timestamping mechanism, and is added
> > to the structures as follows:
> >
> > MechanismIdentifier ::= OBJECT IDENTIFIER
> >
> > TimeStampReq ::= SEQUENCE {
> >       ...
> >       messageImprint  MessageImprint,
> >       mechanism       MechanismIdentifier,  -- addition
> >       ...
> > }
> >
> > TSTInfo ::= SEQUENCE {
> >       ...
> >       policy          PolicyInformtion,
> >       mechanism       MechanismIdentifier,  -- addition
> >       ...
> > }
> >
> > An OID would also be allocated for use in identifying the IETF
> > mechanism.
> >
> > 2. PKIFailureInfo
> >
> > If the TSA does not support the requested mechanism it returns an
> > error code in the "status" field of the TimeStampResp message.  A new
> > error code is added to PKIFailureInfo to support this, as follows:
> >
> > PKIFailureInfo ::= BITSTRING {
> >       ...
> >       mechanismNotSupported (18),  -- addition
> >       -- the TSA does not support the requested mechanism.
> > }
> >
> > 3. TimeStampToken
> >
> > The ISO has modified its timestamp token structure to interoperate
> > with the IETF token, with an adjustment to the specified
> > encapsulation.  The ISO supports alternate token encapsulations and
> > hence defines the token more abstractly.  The IETF mechanism will
> > continue to use the specified SignedData construct [CMS], encoded as
> > an external signature (RFC 2630 pp. 9) in the signatureInfo field
> > below:
> >
> > TSTSignature ::= OCTET STRING
> >
> > TimeStampToken ::= SEQUENCE {
> >         tokenInfo       TSTInfo,
> >         signatureInfo   TSTSignature OPTIONAL  -- SignedData,
> > DER-encoded as
> >                                                -- external signature
> > }
> >
> > The signature is computed on the TSTInfo structure as before, and the
> > signature data is inserted in a SignedData construct.  The construct
> > is then encoded in the signatureInfo field as an external signature
> > (RFC 2630, pp. 9).  The existing content type identifier is retained.
> >
> > Greetings
> >
> > Roland
> >
--------------69D7033562DFAF3761A146E5
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------69D7033562DFAF3761A146E5--



Received: from stargate.zergo.com.au (IDENT:[e-mail] [203.2.208.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19453 for <[e-mail]>; Wed, 26 Jan 2000 18:11:31 -0800 (PST)
Received: from sydneymail1.baltimore.com.au (sydneymail1.jp.zergo.com.au [192.168.71.5]) by stargate.zergo.com.au (8.9.1/8.8.7) with ESMTP id MAA29465; Thu, 27 Jan 2000 12:16:32 +1100
Received: by sydneymail1.jp.zergo.com.au with Internet Mail Service (5.5.2448.0) id <DV4HBKVM>; Thu, 27 Jan 2000 13:13:21 +1100
Message-ID: <[e-mail]>
From: Michael Zolotarev <[e-mail]>
To: Roland Mueller <[e-mail]>
Cc: PKIX mailing group <[e-mail]>
Subject: RE: IETF and ISO alignment on Time Stamping
Date: Thu, 27 Jan 2000 13:13:21 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

The current timestamping draft defines the Policy field in the request
message. I believe it can be successfully used instead of introducing the
MechanismIdentifier field.

Michael

> -----Original Message-----
> From: Roland Mueller [mailto:[e-mail]]
> Sent: Thursday, January 27, 2000 6:52 AM
> To: IETF-PKIX
> Cc: Zuccherato, Robert; Manas, Jose A.; Matyas, Mike; Quisquater,
> Jean-Jaques; Haber, Stuart; Doonan, Wes; Lai, Xuejia; Chawrun, Mike
> Subject: IETF and ISO alignment on Time Stamping
> 
> 
> I write to the PKIX working group as the editor of the ISO 
> working draft
> on time stamping. ISO SC27 has begun work on an International Standard
> on time stamping (ISO Working Draft 18014) in 1998.  The ISO SC27 WG2
> adhoc group on time stamping met recently and discussed the 
> differences
> between the IETF draft and ISO WD 18014, especially with 
> respect to data
> structures, and came to the following conclusions.
> 
> The apporach of WD 18014 has been to be compatible with the IETF PKIX
> working 
> group's Time Stamp Protocol document. It is understood that the PKIX
> approach 
> focuses on digital signatures as the means to bind information within
> time stamp 
> tokens. The motivation for the protocol is well understood. The SC 27
> WG2 group 
> has always attempted to align their work as much as possible with the
> respective 
> valid IETF drafts.
> 
> However, the members of the ISO SC27 WG2 adhoc group have taken a
> broader and 
> more generic approach to accommodate the diversity of time stamp
> mechanisms that 
> exist within the community. This includes the standardization 
> of other 
> mechanisms beyond the particular mechnisms to be standardised by the
> PKIX 
> working group. 
> 
> Therefore the WG2 adhoc group would like to offer the 
> following proposal
> to the 
> PKIX working group to solve the interoperability issues 
> present. It is 
> understood that this proposal reaches the IETF working group at an
> extremely 
> late stage in its standardisation cycle. Even at this late 
> time the SC27
> WG2 
> adhoc group feels that it is important to achieve interoperability. It
> is also 
> realised that the adoption of this proposal may cause a delay in the
> IETF 
> process. However, the PKIX working group may consider whether 
> the issue
> of 
> interoperability is more important than the timeliness of the 
> document.
> 
> The ISO SC27 WG adhoc group's proposal can be characterised in the
> following clause.
> 
> 
> IETF - ISO Interoperability
> ---------------------------
> 
> Summary
> -------
> 
> To achieve interoperability between ISO and IETF proposed standards,
> the ISO has adjusted its messages and tokens in order to align as
> closely as possible with the IETF standard, while still serving the
> diverse interests of the group.  The following summarizes the
> remaining areas to be resolved between the two standards, along with
> an exact specification of the proposed changes.
> 
> 1. Add one field in TimeStampReq and TSTInfo
> 2. Add one additional error code
> 3. Adjust encapsulation of TimeStampToken
> 
> 
> Detail
> ------
> 
> 1. TimeStampReq, TSTInfo
> 
> The ISO has adjusted its timestamp request message and timestamp info
> structures to be compatible with the corresponding IETF structures,
> with the addition of a single "mechanism" field.  This field
> identifies which mechanism is used to form the timestamp token, either
> the IETF mechanism or any of the proposed ISO mechanisms.  In the IETF
> standard, only the IETF mechanism would need be recognized.  The field
> contains an OID identifying the timestamping mechanism, and is added
> to the structures as follows:
> 
> MechanismIdentifier ::= OBJECT IDENTIFIER
> 
> TimeStampReq ::= SEQUENCE {
> 	...
> 	messageImprint	MessageImprint,
> 	mechanism	MechanismIdentifier,  -- addition
> 	...
> }
> 
> TSTInfo ::= SEQUENCE {
> 	...
> 	policy		PolicyInformtion,
> 	mechanism 	MechanismIdentifier,  -- addition
> 	...
> }
> 
> An OID would also be allocated for use in identifying the IETF
> mechanism.
> 
> 2. PKIFailureInfo
> 
> If the TSA does not support the requested mechanism it returns an
> error code in the "status" field of the TimeStampResp message.  A new
> error code is added to PKIFailureInfo to support this, as follows:
> 
> PKIFailureInfo ::= BITSTRING {
> 	...
> 	mechanismNotSupported (18),  -- addition
> 	-- the TSA does not support the requested mechanism.
> }
> 
> 3. TimeStampToken
> 
> The ISO has modified its timestamp token structure to interoperate
> with the IETF token, with an adjustment to the specified
> encapsulation.  The ISO supports alternate token encapsulations and
> hence defines the token more abstractly.  The IETF mechanism will
> continue to use the specified SignedData construct [CMS], encoded as
> an external signature (RFC 2630 pp. 9) in the signatureInfo field
> below: 
> 
> TSTSignature ::= OCTET STRING
> 
> TimeStampToken ::= SEQUENCE {
>         tokenInfo       TSTInfo,
>         signatureInfo   TSTSignature OPTIONAL  -- SignedData,
> DER-encoded as
>                                                -- external signature
> }
> 
> The signature is computed on the TSTInfo structure as before, and the
> signature data is inserted in a SignedData construct.  The construct
> is then encoded in the signatureInfo field as an external signature
> (RFC 2630, pp. 9).  The existing content type identifier is retained.
> 
> Greetings
> 
> Roland
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16222 for <[e-mail]>; Wed, 26 Jan 2000 16:48:04 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLVQHX>; Wed, 26 Jan 2000 16:42:55 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: Massimiliano Pala <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Wed, 26 Jan 2000 16:42:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

RFC 2459 states, quite simply, the material quoted below. You 
can independently verify this assertion at:

ftp://ftp.isi.edu/in-notes/rfc2459.txt

Other important processing rules and related material may be 
found searching for the term "hold" in the RFC. For example

"(3) the certificate had not been revoked at time T and is not
         currently on hold status that commenced before time T, (this
         may be determined by obtaining the appropriate CRL or status
         information, or by out-of-band mechanisms)"

One can define new hold oids at will. The Open CA community
can invent its own if those of ANSI/PKIX are not suitable.

read the instructions on "id-holdinstruction-reject" in combination
with rule (3) (above) carefully.

Your CSL idea can  be fashioned today from a CRL, which uses the
CRL entry extension as specified in 2459, and which is
quoted below.

OpenCA will need to build its own code. The NSA-related toolkits do
not seem to support this particular element.

Peter.



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Wednesday, January 26, 2000 10:36 AM
To: Massimiliano Pala
Cc: [e-mail]
Subject: Re: OCSP and CSL

 
Finally, I have to agree with Russ. I am not fond of suspension as a 
revocation declaration and since 2459 disparages use of this 
facility, I don't think we should spend lots of time on this issue.

Steve



RFC 2459:



"
5.3.2  Hold Instruction Code

   The hold instruction code is a non-critical CRL entry extension that
   provides a registered instruction identifier which indicates the
   action to be taken after encountering a certificate that has been
   placed on hold.

   id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }

   holdInstructionCode ::= OBJECT IDENTIFIER

   The following instruction codes have been defined.  Conforming
   applications that process this extension MUST recognize the following
   instruction codes.

   holdInstruction    OBJECT IDENTIFIER ::=
                    { iso(1) member-body(2) us(840) x9-57(10040) 2 }

   id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
   id-holdinstruction-callissuer
                             OBJECT IDENTIFIER ::= {holdInstruction 2}
   id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}

   Conforming applications which encounter an id-holdinstruction-
   callissuer MUST call the certificate issuer or reject the
   certificate.  Conforming applications which encounter an id-



Housley, et. al.            Standards Track                    [Page 50]


RFC 2459        Internet X.509 Public Key Infrastructure    January 1999


   holdinstruction-reject MUST reject the certificate. The hold
   instruction id-holdinstruction-none is semantically equivalent to the
   absence of a holdInstructionCode, and its use is strongly deprecated
   for the Internet PKI."


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 OAA13785 for <[e-mail]>; Wed, 26 Jan 2000 14:24:11 -0800 (PST)
Received: from [128.33.238.104] (TC104.BBN.COM [128.33.238.104]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA02287; Wed, 26 Jan 2000 17:25:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220805b4b4ed83c785@[128.33.238.90]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04220806b4b3c9cb3dd3@[128.33.238.94]> <[e-mail]>
Date: Wed, 26 Jan 2000 13:36:24 -0500
To: Massimiliano Pala <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OCSP and CSL
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Massimiliano,

>Yes, I think this is what we definetly need. What I was wondering is 
>if available
>software can disitinguish CSLs from CRLs ... As far as I know, 
>actually Netscape
>does not support CRLs with extentions. Am I wrong ???

I think the most recent release of Navigatior does know how to 
process CRLs, but probably not fancy CRLs with extensions.

>Do you know of some software supporting extentions in CRLs (widely 
>available) ???

Check on the Jonah software from IBM, or the NIST or Van Dyke toolkits.

>To issue a CRL, you'd need the CA certificate/key, but in 
>environment where you
>have (for security reasons) a network-less CA how to accomplish this 
>??? Can you
>sign CRLs with a certificate that is not the CA Cert ???

You can sign a CRL with an offline CA key, and transfer the signed 
CRL to a directory or other repository.  Also, you can have the CA 
have two certs, with two different keys, one for signing certs and 
one for signing CRLs.

>
>I was also thinking about the OCSP service: if I can remember well 
>the possible states
>for a given certificate can be Good/Revoked or Unknown only, right 
>??? What about,
>if there is not yet, adding a 'Suspended' state ???

I don't recall what OCSP says re suspended certs as a form of revoked cert.

Finally, I have to agree with Russ. I am not fond of suspension as a 
revocation declaration and since 2459 disparages use of this 
facility, I don't think we should spend lots of time on this issue.

Steve



Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13054 for <[e-mail]>; Wed, 26 Jan 2000 13:56:10 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id KAA15138 for <[e-mail]>; Thu, 27 Jan 2000 10:57:54 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94892387409049>; Thu, 27 Jan 2000 10:57:54 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 27 Jan 2000 10:57:54 (NZDT)
Message-ID: <[e-mail]>

>This document is hereby issued for 14-day WG Last Call.  Please submit any
>comments to this list.

I have the usual ASN.1 style complaint, the whole thing contains large amounts
of unnecessary tagging which obscures the underlying data types (as well as 
making the encoding more complex than necessary).  For example in TimeStampReq:

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(1) },
     messageImprint               MessageImprint,
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
     reqPolicy                [0] PolicyInformation      OPTIONAL,
     nonce                    [1] Integer                OPTIONAL,
     certReq                  [2] BOOLEAN           DEFAULT FALSE,
     extensions               [3] EXPLICIT Extensions    OPTIONAL
}

only the extensions actually need a tag, and that doesn't need to be explicit
(all the elements except the last are distinct, why are they given context-
specific tags?).  In addition the primitive types should really be 
capitalised, ie use INTEGER instead of Integer.  For the rest of the PDU's,
you can remove almost all the tags without causing any problems, which both
simplifies the encoding and makes the encoded data easier to work with (for
example you can actually see an INTEGER rather than just an opaque [0] blob).

Peter.




Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12989 for <[e-mail]>; Wed, 26 Jan 2000 13:55:29 -0800 (PST)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id VAA20952; Wed, 26 Jan 2000 21:56:31 GMT
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 VAA19682; Wed, 26 Jan 2000 21:56:54 GMT
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2000 21:56:28 +0000
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Brian Ford <[e-mail]>
CC: Massimiliano Pala <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <v04220806b4b3c9cb3dd3@[128.33.238.94]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Brian Ford wrote:
> 
> Ben,
> 
> It comes down to your interpretation of suspend versus revoke.  If the
> network between a client and the CA goes bad and you cannot reach a CA for
> a period of time an argument could be made to "suspend" certs from that CA.
>  If the user leaves the employ of a company one would hope that their cert
> would be "revoked".  No?

If you are talking about suspending _all_ certs from a CA, that's an
entirely different matter. What I (and everyone else, AFAICS) was
talking about was an ability to suspend individual certs.

Cheers,

Ben.

--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm

http://www.apache-ssl.org/ben.html

Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt


Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11653 for <[e-mail]>; Wed, 26 Jan 2000 12:48:04 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <DS7HF9X5>; Wed, 26 Jan 2000 15:49:47 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "Pkix List (E-mail)" <[e-mail]>
Subject: RE: Some Issues and observations with the son of 2459
Date: Wed, 26 Jan 2000 15:49:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Some views on Trevor's suggestions:
 
1) RFC 2459 chains vs son of RFC 2459 chains
Until recently I wasn't convinced this would be an issue, but have changed
my view and now agree that in some environments, this could present a 
problem. The recommendation made by Trevor seems reasonable. Just to be sure
I understand it properly, I'll rephrase. Trevor, please correct me if 
I've misinterpreted.
 
A special OID would be assigned (perhaps similar to how the 'anyPolicy' OID
was assigned). This special value, if included in the certificatePolicies
extension indicates that the certificate should be processed under the new
rules. This special OID would act as a trigger only and would not be
returned
to an application as a certificatePolicy value under which a path had
validated. We've looked at a number of alternative solutions, but the one
proposed 
by Trevor seems to have the least amount of associated problems.
 
2)  Name constraints
We're still reviewing these proposals and working through all the different
scenarios. Will send something later on this. We have determined at least 
that the current text could benefit from some more detail about processing
this extension.
 
3) EKU Policy
Seems like a perfectly reasonable strategy. No objections.
 
4) Other Policy qualifiers
No objections here either.
 

-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Sunday, January 23, 2000 5:12 PM
To: Pkix List (E-mail)
Subject: Some Issues and observations with the son of 2459


RFC 2459 chains vs. son of RFC 2459 chains
We will have two sets of semantics under which certificates can be issued -
RFC 2459, and son of RFC 2459, and two sets of rules for processing those
chains. In moving forward, two objectives which we must meet are:

*	When a new son of 2459 client is deployed into an existing 2459 PKI
it must not break with the deployed population of certificates 

*	There must be no requirement to reissue certificates in order to
deploy the new clients.


At the root of the problem is the clarification of what a new son of 2459
client must do if it encounters a chain which does not comply with the more
restrictive son of 2459 policy rules. If that chain was issued under the new
rules, it is indeed a bad chain and verification should fail. If it was
build under the 2459 rules, it is a "legacy chain" which is still valid.
There must be some mechanism to indicate if a certificate was issued under
son of 2459 rules. A possible solution to this would be to assign a "policy
semantics version" OID which must be included in every non self signed
certificate issued under the new rules in the policy extension. A single
2459 certificate in a chain potentially downgrades the chain to 2459 rules.
We can continue to process policy as currently defined, but if we end up
with an empty set, and one of the certificates in the chain does not contain
the policy version OID, we return that verification was successful with an
empty policy set. There are other possibilities for how to distinguish the
certificates such as assigning a new OID to the policy extension and include
both extensions in issued certificates, but at this stage, they seem more
expensive so I would like to see a very strong case in there favour before I
would consider them.
Name Constraint Processing
The current draft does not deal with the case where a certificate contains a
name in an unconstrained namespace. The current wording in the draft in
effect means that if a namespace has not constrained, it is allowed. I would
prefer to move to a model where the CA must explicitly state which
namespaces it wishes to allow, and all others are rejected.
Another problem with Name constraints is the relationships between
namespaces is not considered. Many namespaces can be traced back to DNS
names or IP addresses. URIs are a case in point. The host potion of a URI
(e.g. the name between the second and third forward slashes) can be either a
DNS name or an IP address. When a restriction on a DNS name or IP address is
made, then any other form of that same address (i.e. the host address in a
URI) must conform to the larger rule. The same may equally be said of email
addresses.
EKU Policy
EKU is an extension of policy. Having let the genie out of the bottle, it
will take some time to get it back in. To be consistent with the new rule, I
propose to make it a requirement that under son of 2459 rules, any OID in
the EKU extension must also be present in the policy extension. Any
certificate issued under the new rules where this rule is not met, is to be
considered invalid. Application developers can now migrate to using the
policy extension in stead of the EKU extension, and in time the EKU
extension can be phased out. Policy in the EKU extension will be consistent
with the other policy requirements. In the mean time, existing applications
will not break.
Other Policy Qualifiers
There are only two defined policy qualifiers in the current draft. We have
encountered two instances where other qualifiers are useful. I offer this
observation, for others who may also find them useful and hence like them to
them being more generally used and therefore including them in the draft. 
The first is in restricting the scope of a RA by using a name constraint as
a qualifier on the RA policy OID. This allows the CA to verify the RAs
ability to act for the subject for any given policy. 
The other case is providing some hint to relative authentication strength of
a certificate. If a user has a medium and a strong authentication
certificate which can both be used fro the same application e.g. client
authentication, then it provides a hint which certificate to use to the
client . Having a policy qualifier with a integer for the relative values
allows the client to know which was issued  with the stronger authentication
policy without any other out of band information.
 
Trevor Freeman
Program Manager
Tel: [phone]
Pager: 800-759-8352, id#1631457
Pager email:  <mailto:[e-mail]> [e-mail]
 



Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11414 for <[e-mail]>; Wed, 26 Jan 2000 12:39:58 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJLVPMF>; Wed, 26 Jan 2000 12:34:20 -0800
Message-ID: <[e-mail]>
From: Peter Williams <[e-mail]>
To: "'Philip Hallam-Baker'" <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Wed, 26 Jan 2000 12:34:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

https://www.verisign.com/repository/CPS1.2/CPSCH9.HTM  FYI.

9.8.2 is fun.


-----Original Message-----

From: Philip Hallam-Baker [mailto:[e-mail]]
Sent: Wednesday, January 26, 2000 12:14 PM
To: 'Brian Ford'; Massimiliano Pala
Cc: [e-mail]
Subject: RE: OCSP and CSL



>The CSL which you describe seems to me like a subset of a CRL. 

This is my understanding of the matter too. I really don't like the
profusion
of acronyms for variants of the same structure. I have seen various
varieties
of CRL refered to by customers - ARL (as Authority revocation list and
Attribute
revocation list), XRLs (for cross certification), SRLs (Self signed
root), 
CCRLs (revocation lists for revocation lists), PRLs (Patented
proprietary 
revocation lists, OK I made the last one up but its funny).

I really don't think we should do anything to encourage more acronyms.

The idea of doing anything different with suspended certs is a bit wierd
methinks. If one is going to have a prayer of using suspended certs 
in the manner originally intended then all the junk certs had better be
in the same bag.

The big problem of suspended certs is unsuspension. Unless you are
paying 
for your PKI on a per cert issued basis rather than a per PKI seat basis
there really is not a lot of incentive to suspend rather than
aggressively
revoke and then selectively reissue.

Reversing a certificate suspension would be nice if if was likely to
work
reliably enough. I can imagine a specialist status processing server
(e.g.
OCSP) getting suspension right but the idea of end clients checking the
sigs on reams of CRLs to find out about unsuspension and getting it
right
is surreal.

There are relatively few cases in which authentication data needs to be
suspended (Alice is Alice as Ayn Rand followers would say). It tends to
be authorization data (Alice is allowed to log on) that tends to require
short term modification. Hence my interest in getting a handle on the
distributed authorization issue.

	Phill


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10787 for <[e-mail]>; Wed, 26 Jan 2000 12:13:12 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id MAA27981; Wed, 26 Jan 2000 12:11:47 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <CMBLW5ZL>; Wed, 26 Jan 2000 12:13:47 -0800
Message-ID: <[e-mail]>
From: Philip Hallam-Baker <[e-mail]>
To: "'Brian Ford'" <[e-mail]>, Massimiliano Pala <[e-mail]>
Cc: [e-mail]
Subject: RE: OCSP and CSL
Date: Wed, 26 Jan 2000 12:13:45 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEDENvbnRl
bnQtVHlwZQQCOiAECnRleHQvcGxhaW4EBDsNCgkEB2NoYXJzZXQEAT0EASIECmlzby04ODU5LTEE
ASIEAg0KBBlDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nBAI6IAQEN2JpdAQCDQoEAg0KBIIG4g0K
PlRoZSBDU0wgd2hpY2ggeW91IGRlc2NyaWJlIHNlZW1zIHRvIG1lIGxpa2UgYSBzdWJzZXQgb2Yg
YSBDUkwuIA0KDQpUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG1hdHRlciB0b28uIEkg
cmVhbGx5IGRvbid0IGxpa2UgdGhlDQpwcm9mdXNpb24NCm9mIGFjcm9ueW1zIGZvciB2YXJpYW50
cyBvZiB0aGUgc2FtZSBzdHJ1Y3R1cmUuIEkgaGF2ZSBzZWVuIHZhcmlvdXMNCnZhcmlldGllcw0K
b2YgQ1JMIHJlZmVyZWQgdG8gYnkgY3VzdG9tZXJzIC0gQVJMIChhcyBBdXRob3JpdHkgcmV2b2Nh
dGlvbiBsaXN0IGFuZA0KQXR0cmlidXRlDQpyZXZvY2F0aW9uIGxpc3QpLCBYUkxzIChmb3IgY3Jv
c3MgY2VydGlmaWNhdGlvbiksIFNSTHMgKFNlbGYgc2lnbmVkDQpyb290KSwgDQpDQ1JMcyAocmV2
b2NhdGlvbiBsaXN0cyBmb3IgcmV2b2NhdGlvbiBsaXN0cyksIFBSTHMgKFBhdGVudGVkDQpwcm9w
cmlldGFyeSANCnJldm9jYXRpb24gbGlzdHMsIE9LIEkgbWFkZSB0aGUgbGFzdCBvbmUgdXAgYnV0
IGl0cyBmdW5ueSkuDQoNCkkgcmVhbGx5IGRvbid0IHRoaW5rIHdlIHNob3VsZCBkbyBhbnl0aGlu
ZyB0byBlbmNvdXJhZ2UgbW9yZSBhY3Jvbnltcy4NCg0KVGhlIGlkZWEgb2YgZG9pbmcgYW55dGhp
bmcgZGlmZmVyZW50IHdpdGggc3VzcGVuZGVkIGNlcnRzIGlzIGEgYml0IHdpZXJkDQptZXRoaW5r
cy4gSWYgb25lIGlzIGdvaW5nIHRvIGhhdmUgYSBwcmF5ZXIgb2YgdXNpbmcgc3VzcGVuZGVkIGNl
cnRzIA0KaW4gdGhlIG1hbm5lciBvcmlnaW5hbGx5IGludGVuZGVkIHRoZW4gYWxsIHRoZSBqdW5r
IGNlcnRzIGhhZCBiZXR0ZXIgYmUNCmluIHRoZSBzYW1lIGJhZy4NCg0KVGhlIGJpZyBwcm9ibGVt
IG9mIHN1c3BlbmRlZCBjZXJ0cyBpcyB1bnN1c3BlbnNpb24uIFVubGVzcyB5b3UgYXJlDQpwYXlp
bmcgDQpmb3IgeW91ciBQS0kgb24gYSBwZXIgY2VydCBpc3N1ZWQgYmFzaXMgcmF0aGVyIHRoYW4g
YSBwZXIgUEtJIHNlYXQgYmFzaXMNCnRoZXJlIHJlYWxseSBpcyBub3QgYSBsb3Qgb2YgaW5jZW50
aXZlIHRvIHN1c3BlbmQgcmF0aGVyIHRoYW4NCmFnZ3Jlc3NpdmVseQ0KcmV2b2tlIGFuZCB0aGVu
IHNlbGVjdGl2ZWx5IHJlaXNzdWUuDQoNClJldmVyc2luZyBhIGNlcnRpZmljYXRlIHN1c3BlbnNp
b24gd291bGQgYmUgbmljZSBpZiBpZiB3YXMgbGlrZWx5IHRvDQp3b3JrDQpyZWxpYWJseSBlbm91
Z2guIEkgY2FuIGltYWdpbmUgYSBzcGVjaWFsaXN0IHN0YXR1cyBwcm9jZXNzaW5nIHNlcnZlcg0K
KGUuZy4NCk9DU1ApIGdldHRpbmcgc3VzcGVuc2lvbiByaWdodCBidXQgdGhlIGlkZWEgb2YgZW5k
IGNsaWVudHMgY2hlY2tpbmcgdGhlDQpzaWdzIG9uIHJlYW1zIG9mIENSTHMgdG8gZmluZCBvdXQg
YWJvdXQgdW5zdXNwZW5zaW9uIGFuZCBnZXR0aW5nIGl0DQpyaWdodA0KaXMgc3VycmVhbC4NCg0K
VGhlcmUgYXJlIHJlbGF0aXZlbHkgZmV3IGNhc2VzIGluIHdoaWNoIGF1dGhlbnRpY2F0aW9uIGRh
dGEgbmVlZHMgdG8gYmUNCnN1c3BlbmRlZCAoQWxpY2UgaXMgQWxpY2UgYXMgQXluIFJhbmQgZm9s
bG93ZXJzIHdvdWxkIHNheSkuIEl0IHRlbmRzIHRvDQpiZSBhdXRob3JpemF0aW9uIGRhdGEgKEFs
aWNlIGlzIGFsbG93ZWQgdG8gbG9nIG9uKSB0aGF0IHRlbmRzIHRvIHJlcXVpcmUNCnNob3J0IHRl
cm0gbW9kaWZpY2F0aW9uLiBIZW5jZSBteSBpbnRlcmVzdCBpbiBnZXR0aW5nIGEgaGFuZGxlIG9u
IHRoZQ0KZGlzdHJpYnV0ZWQgYXV0aG9yaXphdGlvbiBpc3N1ZS4NCg0KCVBoaWxsDQoEAAAAAAAA
AKCCCycwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJs
aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAx
MDUyMzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g
VHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3Mg
MiBQZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yks
NJ2CvEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931
r2dZIArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sL
AgMBAAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNh
Mi5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggr
BgEFBQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEB
MAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3k
VPdhPVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhU
dt0WbPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMC
AQICEQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlz
IHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5
OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAw
WhcNMDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl
cmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0
IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWdu
IENsYXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0Ydhouow
A1VrCDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18
YOO13+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEE
F5Wgjf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEt
MTE4MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50
LmNybDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsG
AQUFBwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX
8M5yFD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6g
S/aYMZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEFDCCA32gAwIB
AgIQAxTuqrYcesW8jpUyudZ0/DANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBz
dWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkx
JTAjBgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNOTkxMjIwMDAwMDAwWhcN
MDAxMjE5MjM1OTU5WjBsMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMT
ClJlY2lwaWVudHMxNTAzBgNVBAMTLHBiYWtlciAoUGhpbGlwIEhhbGxhbS1CYWtlciwgVmVyaVNp
Z24sIEluYy4pMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3f0kRIy2AU5cHhfnUwuHecFNq
6dnf/wsvxS//4Nt8rFgr2KdvQETKaQ6wGl6mVijB6udZW9dUKVoE1lnu2MMcIhtAL3+Q2dsrxlrT
InfqPKAdxu/Fvb4n3Y0RItW9zh1MzFWZ8Q9z6eF2HuBwG6ANfRzfJgironyftbbitRyaxQIDAQAB
o4IBdDCCAXAwCQYDVR0TBAIwADBVBgNVHR8ETjBMMEqgSKBGhkRodHRwOi8vb25zaXRlY3JsLnZl
cmlzaWduLmNvbS9WZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTDALBgNVHQ8E
BAMCBaAwHgYDVR0RBBcwFYETcGJha2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtg
hkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBi
BggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y
cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQD
AgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQAaUApB
XCjcmPE5dFPHlQVl4n9WoOU7AE487xxC7vcR1MDhF8p/0GMu6zOyZe9CFVaOndaYCRgv69qKTVoA
NmsMF/eFsQn/HaoXEz+jHPNgWcPyBu3dujO9s2PLQbuBXE3rIaDiVyTftVgoNvO0fcknSlNOWxqH
vbaH9RYvhMghkjGCAvgwggL0AgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8g
dGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMc
VmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0/DAJBgUrDgMCGgUA
oIIBjDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDAxMjYyMDE0
MTRaMCMGCSqGSIb3DQEJBDEWBBQ01fA0+pwVlkWwV7ZA8NkOvbLV5DBYBgkqhkiG9w0BCQ8xSzBJ
MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUr
DgMCGjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlz
IHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5
OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQAxTuqrYcesW8jpUyudZ0
/DANBgkqhkiG9w0BAQEFAASBgLZ/ZtzTQ1BiPIZZKrsjwxNRvf2cwfgED81SEz0YukyRKmF7nyu5
9U+7V9zzWgWus0WXzkTq76RA8iAlzlHyuadNFzqpk++82ak31wM1swtgVj+HZAjAg++QYRCLao5M
ZdklP0CDi3zx785n1oPHs0z4cM7GIWW+UK2/RqQLJfxFAAAAAAAA


Received: from c004.sfo.cp.net (c004-h005.c004.sfo.cp.net [209.228.14.76]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA10187 for <[e-mail]>; Wed, 26 Jan 2000 11:48:56 -0800 (PST)
Received: (cpmta 29486 invoked from network); 26 Jan 2000 11:50:12 -0800
Received: from cs2889-175.austin.rr.com (HELO tuvit.net) (24.28.89.175) by smtp.tuvit.net with SMTP; 26 Jan 2000 11:50:12 -0800
X-Sent: 26 Jan 2000 19:50:12 GMT
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2000 13:52:11 -0600
From: Roland Mueller <[e-mail]>
Organization: TUVIT Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: IETF-PKIX <[e-mail]>
CC: "Zuccherato, Robert" <[e-mail]>, "Manas, Jose A." <[e-mail]>, "Matyas, Mike" <[e-mail]>, "Quisquater, Jean-Jaques" <[e-mail]>, "Haber, Stuart" <[e-mail]>, "Doonan, Wes" <[e-mail]>, "Lai, Xuejia" <[e-mail]>, "Chawrun, Mike" <[e-mail]>
Subject: IETF and ISO alignment on Time Stamping
Content-Type: multipart/mixed; boundary="------------D1AFA5D1ECA54A45BD4B5324"

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

I write to the PKIX working group as the editor of the ISO working draft
on time stamping. ISO SC27 has begun work on an International Standard
on time stamping (ISO Working Draft 18014) in 1998.  The ISO SC27 WG2
adhoc group on time stamping met recently and discussed the differences
between the IETF draft and ISO WD 18014, especially with respect to data
structures, and came to the following conclusions.

The apporach of WD 18014 has been to be compatible with the IETF PKIX
working 
group's Time Stamp Protocol document. It is understood that the PKIX
approach 
focuses on digital signatures as the means to bind information within
time stamp 
tokens. The motivation for the protocol is well understood. The SC 27
WG2 group 
has always attempted to align their work as much as possible with the
respective 
valid IETF drafts.

However, the members of the ISO SC27 WG2 adhoc group have taken a
broader and 
more generic approach to accommodate the diversity of time stamp
mechanisms that 
exist within the community. This includes the standardization of other 
mechanisms beyond the particular mechnisms to be standardised by the
PKIX 
working group. 

Therefore the WG2 adhoc group would like to offer the following proposal
to the 
PKIX working group to solve the interoperability issues present. It is 
understood that this proposal reaches the IETF working group at an
extremely 
late stage in its standardisation cycle. Even at this late time the SC27
WG2 
adhoc group feels that it is important to achieve interoperability. It
is also 
realised that the adoption of this proposal may cause a delay in the
IETF 
process. However, the PKIX working group may consider whether the issue
of 
interoperability is more important than the timeliness of the document.

The ISO SC27 WG adhoc group's proposal can be characterised in the
following clause.


IETF - ISO Interoperability
---------------------------

Summary
-------

To achieve interoperability between ISO and IETF proposed standards,
the ISO has adjusted its messages and tokens in order to align as
closely as possible with the IETF standard, while still serving the
diverse interests of the group.  The following summarizes the
remaining areas to be resolved between the two standards, along with
an exact specification of the proposed changes.

1. Add one field in TimeStampReq and TSTInfo
2. Add one additional error code
3. Adjust encapsulation of TimeStampToken


Detail
------

1. TimeStampReq, TSTInfo

The ISO has adjusted its timestamp request message and timestamp info
structures to be compatible with the corresponding IETF structures,
with the addition of a single "mechanism" field.  This field
identifies which mechanism is used to form the timestamp token, either
the IETF mechanism or any of the proposed ISO mechanisms.  In the IETF
standard, only the IETF mechanism would need be recognized.  The field
contains an OID identifying the timestamping mechanism, and is added
to the structures as follows:

MechanismIdentifier ::= OBJECT IDENTIFIER

TimeStampReq ::= SEQUENCE {
	...
	messageImprint	MessageImprint,
	mechanism	MechanismIdentifier,  -- addition
	...
}

TSTInfo ::= SEQUENCE {
	...
	policy		PolicyInformtion,
	mechanism 	MechanismIdentifier,  -- addition
	...
}

An OID would also be allocated for use in identifying the IETF
mechanism.

2. PKIFailureInfo

If the TSA does not support the requested mechanism it returns an
error code in the "status" field of the TimeStampResp message.  A new
error code is added to PKIFailureInfo to support this, as follows:

PKIFailureInfo ::= BITSTRING {
	...
	mechanismNotSupported (18),  -- addition
	-- the TSA does not support the requested mechanism.
}

3. TimeStampToken

The ISO has modified its timestamp token structure to interoperate
with the IETF token, with an adjustment to the specified
encapsulation.  The ISO supports alternate token encapsulations and
hence defines the token more abstractly.  The IETF mechanism will
continue to use the specified SignedData construct [CMS], encoded as
an external signature (RFC 2630 pp. 9) in the signatureInfo field
below: 

TSTSignature ::= OCTET STRING

TimeStampToken ::= SEQUENCE {
        tokenInfo       TSTInfo,
        signatureInfo   TSTSignature OPTIONAL  -- SignedData,
DER-encoded as
                                               -- external signature
}

The signature is computed on the TSTInfo structure as before, and the
signature data is inserted in a SignedData construct.  The construct
is then encoded in the signatureInfo field as an external signature
(RFC 2630, pp. 9).  The existing content type identifier is retained.

Greetings

Roland
--------------D1AFA5D1ECA54A45BD4B5324
Content-Type: text/x-vcard; charset=us-ascii;
 name="roland.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roland Mueller
Content-Disposition: attachment;
 filename="roland.vcf"

begin:vcard 
n:Mueller;Roland
tel;fax:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
org:TUVIT Inc.
version:2.1
email;internet:[e-mail]
adr;quoted-printable:;;8716 North MoPac=0D=0ASuite 220;Austin;Texas;78759;U.S.A.
x-mozilla-cpt:;-1
fn:Mueller, Roland
end:vcard

--------------D1AFA5D1ECA54A45BD4B5324--



Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07383 for <[e-mail]>; Wed, 26 Jan 2000 10:19:10 -0800 (PST)
Received: from brford-pc (brford-frame2.cisco.com [171.68.89.147]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with SMTP id KAA24708; Wed, 26 Jan 2000 10:19:39 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 26 Jan 2000 13:19:37 -0500
To: Ben Laurie <[e-mail]>
From: Brian Ford <[e-mail]>
Subject: Re: OCSP and CSL
Cc: Massimiliano Pala <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <v04220806b4b3c9cb3dd3@[128.33.238.94]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Ben,

It comes down to your interpretation of suspend versus revoke.  If the
network between a client and the CA goes bad and you cannot reach a CA for
a period of time an argument could be made to "suspend" certs from that CA.
 If the user leaves the employ of a company one would hope that their cert
would be "revoked".  No?

Regards,

Brian

At 05:27 PM 01/26/00, Ben Laurie wrote:
>Massimiliano Pala wrote:
>> 
>> Stephen Kent wrote:
>> >
>> > Massimiliano,
>> >
>> > Would not a CRL DP that holds only suspended certs achieve the effect
>> > you attribute to a CSL?
>> >
>> > Steve
>> 
>> Yes, I think this is what we definetly need. What I was wondering is if 
>available
>> software can disitinguish CSLs from CRLs ... As far as I know, actually 
>Netscape
>> does not support CRLs with extentions. Am I wrong ???
>> 
>> Do you know of some software supporting extentions in CRLs (widely 
>available) ???
>> 
>> To issue a CRL, you'd need the CA certificate/key, but in environment 
>where you
>> have (for security reasons) a network-less CA how to accomplish this ??? 
>Can you
>> sign CRLs with a certificate that is not the CA Cert ???
>
>Since a suspended certificate is as unusable as a revoked one, it makes
>no sense to me to permit _any_ differences between the creation of a
>suspension and the creation of a revocation. Which means that there's
>little point in supporting suspension at all.
>
>Cheers,
>
>Ben.
>
>--
>SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
>
>http://www.apache-ssl.org/ben.html
>
>Y19100 no-prize winner!
>http://www.ntk.net/index.cgi?back=2000/now0121.txt
>


Brian Ford  
Consulting Engineer, CCIE #2106  
Cisco Systems Inc.



Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06325 for <[e-mail]>; Wed, 26 Jan 2000 10:14:11 -0800 (PST)
Received: from brford-pc (brford-frame2.cisco.com [171.68.89.147]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with SMTP id KAA22539; Wed, 26 Jan 2000 10:15:14 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 26 Jan 2000 13:15:12 -0500
To: Massimiliano Pala <[e-mail]>
From: Brian Ford <[e-mail]>
Subject: Re: OCSP and CSL
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Massimiliano,

I'm no expert but my read of the RFCs is a little different.

The CSL which you describe seems to me like a subset of a CRL.  If you made
a query at a CA for that info I'd guess that the current CRL at the CA
would be parsed to deliver your answer.  The response would be in the form
of a list.  So depending on the CRL lifetime, that info may (or may not) be
current.

Using OCSP on the other hand the request would be made to a CA regarding a
specific cert.  The CA would be queried directly for a response (so the
info would be current).  The response would be either good, revoked or unknown.

Comments?

Regards,

Brian

At 06:51 PM 01/24/00, Massimiliano Pala wrote:
>Hi all,
>
>(first of all I apologize for my english(?), now let's go on ... )
>
>working about an OCSP server to be included in the OpenCA package
>I found very strange the lack of some kind of CSL (Certificate
>Suspension List). If there is something similar I'm not aware of,
>please report it and ignore this mail ...
>
>For CSL I mean a sort of CRL (same structures, formats), but carrying
>a list of only suspended certificates: this is obviously useful for
>ocsp implementations and considering the fact that in most env you'll
>not be requested for certificate status changing very often, issuing
>this kind of lists, I think, could be useful.
>
>First of all the software can, with very few modification, support
>this kind of lists because them are built exactly like CRLs (but
>them carry informations only on suspension: this can occour for
>example when a certificate is requested for revokation but the request
>have not been processed by the CA (think about network disconnected
>CAs)). These lists can be signed by, let's say, the OCSP server
>(certificate assigned to the OCSP authority or another certificate
>issued for this porpouse and placed on a network-connected station) and
>issued whenever a new certificate is suspended or its state is
>changed to revoke/valid . When this last option happens the certificate
>simply do not appear on the suspension list.
>
>The correct status of a certificate, then, can be given by the
>couple CSL/CRL without having to support OCSP or other protocols and
>moreover the CSL are the same as CRLs so you don't have to rewrite
>most of the software ... think about Apache (that now correctly
>checks CRLs) ... 
>
>Is there anything like this around ??? Do you think this could be
>useful or not ??? In case you approve I can take in charge of writing
>an initial rfc for publication if needed to ...
>
>Please report ANY comments :-D
>
>C'you,
>
>	Massimiliano Pala ([e-mail])


Brian Ford  
Consulting Engineer, CCIE #2106  
Cisco Systems Inc.



Received: from eastwood.aldigital.algroup.co.uk (eastwood.aldigital.algroup.co.uk [194.128.162.193]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28070 for <[e-mail]>; Wed, 26 Jan 2000 09:26:09 -0800 (PST)
Received: from freeby.ben.algroup.co.uk (freeby.ben.algroup.co.uk [193.133.15.6]) by eastwood.aldigital.algroup.co.uk (8.8.8/8.6.12) with ESMTP id RAA09272; Wed, 26 Jan 2000 17:27:38 GMT
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 RAA17880; Wed, 26 Jan 2000 17:27:57 GMT
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2000 17:27:39 +0000
From: Ben Laurie <[e-mail]>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: Massimiliano Pala <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <v04220806b4b3c9cb3dd3@[128.33.238.94]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Massimiliano Pala wrote:
> 
> Stephen Kent wrote:
> >
> > Massimiliano,
> >
> > Would not a CRL DP that holds only suspended certs achieve the effect
> > you attribute to a CSL?
> >
> > Steve
> 
> Yes, I think this is what we definetly need. What I was wondering is if available
> software can disitinguish CSLs from CRLs ... As far as I know, actually Netscape
> does not support CRLs with extentions. Am I wrong ???
> 
> Do you know of some software supporting extentions in CRLs (widely available) ???
> 
> To issue a CRL, you'd need the CA certificate/key, but in environment where you
> have (for security reasons) a network-less CA how to accomplish this ??? Can you
> sign CRLs with a certificate that is not the CA Cert ???

Since a suspended certificate is as unusable as a revoked one, it makes
no sense to me to permit _any_ differences between the creation of a
suspension and the creation of a revocation. Which means that there's
little point in supporting suspension at all.

Cheers,

Ben.

--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm

http://www.apache-ssl.org/ben.html

Y19100 no-prize winner!
http://www.ntk.net/index.cgi?back=2000/now0121.txt


Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09262 for <[e-mail]>; Tue, 25 Jan 2000 16:37:57 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id BAA20538; Wed, 26 Jan 2000 01:39:06 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2000 01:40:16 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: OCSP and CSL
References: <[e-mail]> <v04220806b4b3c9cb3dd3@[128.33.238.94]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0D3E4B191D405DFE248FBEC6"

This is a cryptographically signed message in MIME format.

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

Stephen Kent wrote:
> 
> Massimiliano,
> 
> Would not a CRL DP that holds only suspended certs achieve the effect
> you attribute to a CSL?
> 
> Steve

Yes, I think this is what we definetly need. What I was wondering is if available
software can disitinguish CSLs from CRLs ... As far as I know, actually Netscape
does not support CRLs with extentions. Am I wrong ???

Do you know of some software supporting extentions in CRLs (widely available) ???

To issue a CRL, you'd need the CA certificate/key, but in environment where you
have (for security reasons) a network-less CA how to accomplish this ??? Can you
sign CRLs with a certificate that is not the CA Cert ???

I was also thinking about the OCSP service: if I can remember well the possible states
for a given certificate can be Good/Revoked or Unknown only, right ??? What about,
if there is not yet, adding a 'Suspended' state ???

Thank you for the reply,

	Massimiliano Pala ([e-mail])
--------------ms0D3E4B191D405DFE248FBEC6
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI2MDA0MDE2WjAjBgkqhkiG9w0BCQQxFgQUBavnQre2uPy559RKME4/ctdBvIsw
DQYJKoZIhvcNAQEBBQAEgYCK6p09lB6ddyTjOj6vw/V376cxcoYUkbIv7rran6wxr7DEgD/b
xFNvq5I88r3uMSISTQ/57mFfZQyJvYir9FIOrXQ7EkF7lcGWiJOPcR+IGxIybQNMEJvzOdef
JRRnYX5TFOLdyfhxAaClOWoEu3T8NP7kWiY2sKH4MfxSAeezBA==
--------------ms0D3E4B191D405DFE248FBEC6--



Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09225 for <[e-mail]>; Tue, 25 Jan 2000 16:37:09 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id BAA20522; Wed, 26 Jan 2000 01:37:36 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2000 01:38:46 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Subject: Re: OCSP and CSL
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms00EA1B15840C540CFCB126A7"

This is a cryptographically signed message in MIME format.

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

Russ Housley wrote:
> 
> Massimiliano:
> 
> I do not think that we should do anything to encourage CAs to suspend
> certificates.  This feature adds significant complexity to the whole
> system, and we should discourage it's use.
> 
> Russ
> 

You are right saying that adding complexity should be discouraged, by the
way I suggested them because we need something like that (I am from the
OpenCA project). Let me explain in more details why I think something
similar could come in handy.

The CSLs, let's call them CSL to distinguish from CRLs, have sense in env
where there is a time gap between the 'request for cert revoking' by the
user and the effective revoking by the CA: this is obvious if you consider
structures where the main CA computer is disconnected from any network.

Would you allow a certificate to be used when a user says it could have
been compromised ? You can not either say it is revoked because it is not
(CRLs do not report it) and there is no way to verify it till the new
CRL is issued.

With some instrument like the proposed CSLs (that is only a proposal, I am
not saying it is the best or the only solution to the problem, I am obviously
open to EVERY comment... :-D and hopefully to some better solutions) you can
say, from the moment the user signals a danger the usage of the certificate
is compromised and that itself is to be considered in a 'freezed' state.

Am I completely out of the target ? What do you think about this problem ?
Thanks for the comments you sent.

C'you,

	Massimiliano Pala ([e-mail])
--------------ms00EA1B15840C540CFCB126A7
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI2MDAzODQ2WjAjBgkqhkiG9w0BCQQxFgQUZtU8EkIIKewMhUGKAW0/5dHWiPYw
DQYJKoZIhvcNAQEBBQAEgYCflcubd0gTM9gcO42NWmqoEgy2pdndZvq9qg2UE1+ZSsubs5S9
ZasrqJbki64wQzlzgBalaUvCOEDd9W3kkmY7R4A7s9yxXVrSxALPvggtV8JpD6lqF+0qjjgP
dU9UlSl8QNxH10Nc2K/XHqG3uWTTkon7+PtqoM8TQDvfeNobtg==
--------------ms00EA1B15840C540CFCB126A7--



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 OAA26795 for <[e-mail]>; Tue, 25 Jan 2000 14:19:09 -0800 (PST)
Received: from [128.33.238.32] (TC032.BBN.COM [128.33.238.32]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA15501; Tue, 25 Jan 2000 17:20:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220806b4b3c9cb3dd3@[128.33.238.94]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 25 Jan 2000 16:46:25 -0500
To: Massimiliano Pala <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: OCSP and CSL
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Massimiliano,

Would not a CRL DP that holds only suspended certs achieve the effect 
you attribute to a CSL?

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 OAA26598 for <[e-mail]>; Tue, 25 Jan 2000 14:17:39 -0800 (PST)
Received: from [128.33.238.32] (TC032.BBN.COM [128.33.238.32]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA15318; Tue, 25 Jan 2000 17:19:15 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220804b4b3bebca333@[128.33.238.94]>
In-Reply-To: <01ac01bf6333$18c419d0$[e-mail]>
References: <01ac01bf6333$18c419d0$[e-mail]>
Date: Tue, 25 Jan 2000 16:10:50 -0500
To: Pedro =?iso-8859-1?Q?F=E9lix?=  <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Binding between keys and schemes?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Prdro,

First, a certificate doesn't purport to characterize the capabilities 
of the subject wrt the algorithms with which a public key may be 
used.  Rather, a certificate expresses the algorithm with which the 
key may be used.  This is a fine distinction, but we have avoided 
loading other user crypto capability info into certs in the past, 
e.g., what symmetric crypto algorithms a user's S/MIME implementation 
supports.

If a single key can be used with various algorithms, a certificate is 
capable of expressing only one, as currently specified, and thus one 
might need to have multiple certificates, if multiple algorithms are 
to be employed.  One might imagine defining an algorithm ID that 
captures a set of algorithms with which a key may be used, by the 
subject.  Syntactically, that has been done in the past, e.g., in DMS 
certificates specified that the SubjectPublicKey field contained two 
keys, one for KEA and one for DSA.  It's a hack.  The deliberations 
that led to X.509 v3 made clear that putting two keys into this field 
was discouraged. Still, this example suggests that one might define 
an Algorithm ID that conveys a more complex notion of what 
algorithm(s) can be used with a key.

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 OAA26295 for <[e-mail]>; Tue, 25 Jan 2000 14:12:01 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (dial06.spyrus.com [207.212.34.126]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id OAA26780; Tue, 25 Jan 2000 14:09:55 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 25 Jan 2000 17:09:35 -0500
To: Massimiliano Pala <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: OCSP and CSL
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Massimiliano:

I do not think that we should do anything to encourage CAs to suspend 
certificates.  This feature adds significant complexity to the whole 
system, and we should discourage it's use.

Russ


At 06:51 PM 01/24/2000 +0100, Massimiliano Pala wrote:
>Hi all,
>
>(first of all I apologize for my english(?), now let's go on ... )
>
>working about an OCSP server to be included in the OpenCA package
>I found very strange the lack of some kind of CSL (Certificate
>Suspension List). If there is something similar I'm not aware of,
>please report it and ignore this mail ...
>
>For CSL I mean a sort of CRL (same structures, formats), but carrying
>a list of only suspended certificates: this is obviously useful for
>ocsp implementations and considering the fact that in most env you'll
>not be requested for certificate status changing very often, issuing
>this kind of lists, I think, could be useful.
>
>First of all the software can, with very few modification, support
>this kind of lists because them are built exactly like CRLs (but
>them carry informations only on suspension: this can occour for
>example when a certificate is requested for revokation but the request
>have not been processed by the CA (think about network disconnected
>CAs)). These lists can be signed by, let's say, the OCSP server
>(certificate assigned to the OCSP authority or another certificate
>issued for this porpouse and placed on a network-connected station) and
>issued whenever a new certificate is suspended or its state is
>changed to revoke/valid . When this last option happens the certificate
>simply do not appear on the suspension list.
>
>The correct status of a certificate, then, can be given by the
>couple CSL/CRL without having to support OCSP or other protocols and
>moreover the CSL are the same as CRLs so you don't have to rewrite
>most of the software ... think about Apache (that now correctly
>checks CRLs) ...
>
>Is there anything like this around ??? Do you think this could be
>useful or not ??? In case you approve I can take in charge of writing
>an initial rfc for publication if needed to ...
>
>Please report ANY comments :-D
>
>C'you,
>
>         Massimiliano Pala ([e-mail])



Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21648 for <[e-mail]>; Tue, 25 Jan 2000 09:59:01 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id JAA17688 for <[e-mail]>; Tue, 25 Jan 2000 09:57:40 -0800 (PST)
Received: by postal-gw1.verisign.com with Internet Mail Service (5.5.2650.21) id <CMBLW3N0>; Tue, 25 Jan 2000 09:59:47 -0800
Message-ID: <[e-mail]>
From: Warwick Ford <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: LAST CALL:draft-ietf-pkix-time-stamp-05.txt
Date: Tue, 25 Jan 2000 09:59:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

This document is hereby issued for 14-day WG Last Call.  Please submit any
comments to this list.

Warwick

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, January 07, 2000 3:39 AM
To: IETF-Announce; @imc.org
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Time
Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams,  P. Cain, D. Pinkas,  R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-05.txt
	Pages		: 20
	Date		: 06-Jan-00
	
A time stamping service allows to prove that a datum existed before
a particular time and can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). This document describes the format of a request sent to a
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was generated
during the validity period of the corresponding public key
certificate is given in an annex.

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


Received: from aci01-internal.americancentury.com ([e-mail] [207.19.50.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20219 for <[e-mail]>; Tue, 25 Jan 2000 08:41:59 -0800 (PST)
Received: by aci01-internal.americancentury.com; id KAA04806; Tue, 25 Jan 2000 10:42:52 -0600 (CST)
Received: from laptop-1.americancentury.com(10.122.30.128) by aci01.americancentury.com via smap (4.1) id xma004584; Tue, 25 Jan 00 10:42:28 -0600
From: "Robert Rowland" <[e-mail]>
To: "TJ Swalla" <[e-mail]>, <[e-mail]>
Subject: RE: access to IDC information
Date: Tue, 25 Jan 2000 10:40:56 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
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.00.2919.5600

well,,,
if you look at ibm's "redbook" website (www.redbooks.ibm.com) (which is
where they
sell/keep their published docs you may find some information that is
helpful.

They also have documents ( they run in the hundreds of pages )
on other possibly inter-related ( ldap, ... ) topics

-robert


-----Original Message-----
From: TJ Swalla [mailto:[e-mail]]
Sent: Tuesday, January 25, 2000 7:57 AM
To: [e-mail]
Subject: access to IDC information


I am in the process of trying to compile information for a research
paper at
Loyola University.  I have learned that IDC just published a paper
called
"PKI: Nothing but Pilots?" (IDC #W20448) which is the type of info I am
looking for.  The problem is that IDC said I must pay $4500 for the
paper and
I don't have that type of money.  Is there anyone who might be able to
get me
a discount, or any other solutions.  It would be greatly appreciated.

here is a link to their press release
http://www.idc.com/Data/Internet/Content/NET122199PR.htm

Thank you

TJ Swalla

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1



Received: from relay04.netaddress.usa.net (relay04.netaddress.usa.net [204.68.24.184]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA19233 for <[e-mail]>; Tue, 25 Jan 2000 07:54:52 -0800 (PST)
Received: (qmail 8036 invoked from network); 25 Jan 2000 15:56:32 -0000
Received: from nwcst323.netaddress.usa.net (204.68.23.68) by outbound.netaddress.usa.net with SMTP; 25 Jan 2000 15:56:32 -0000
Received: (qmail 11715 invoked by uid 60001); 25 Jan 2000 15:56:32 -0000
Message-ID: <[e-mail]>
Received: from 204.68.23.68 by nwcst323 for [205.212.224.52] via web-mailer(M3.4.0.33) on Tue Jan 25 15:56:32 GMT 2000
Date: 25 Jan 00 08:56:32 MST
From: TJ Swalla <[e-mail]>
To: [e-mail]
Subject: access to IDC information
X-Mailer: USANET web-mailer (M3.4.0.33)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA19234

I am in the process of trying to compile information for a research paper at
Loyola University.  I have learned that IDC just published a paper called
"PKI: Nothing but Pilots?" (IDC #W20448) which is the type of info I am
looking for.  The problem is that IDC said I must pay $4500 for the paper and
I don't have that type of money.  Is there anyone who might be able to get me
a discount, or any other solutions.  It would be greatly appreciated.

here is a link to their press release
http://www.idc.com/Data/Internet/Content/NET122199PR.htm

Thank you

TJ Swalla

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA02200 for <[e-mail]>; Mon, 24 Jan 2000 19:49:19 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Jan 2000 19:31:01 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <DFRQ0FSK>; Mon, 24 Jan 2000 19:31:01 -0800
Message-ID: <[e-mail]>
From: Jim Schaad <[e-mail]>
To: =?iso-8859-1?Q?=27Pedro_F=E9lix=27?= <[e-mail]>, Tolga Acar <[e-mail]>, [e-mail]
Cc: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: RE: Binding between keys and schemes?
Date: Mon, 24 Jan 2000 19:30:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF66E4.98F2C2AA"

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_01BF66E4.98F2C2AA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My personal opinion on this issue is that in the absense of other =
knowledge
PKCS1-v1_5 would be used.  If the S/MIME capabilities contained the OID =
for
OAEP, then it could be used instead.  The certificate does not state =
which
scheme is to be used (just as it does not state that 3DES or RC5 should =
be
the bulk encryption algorithm used).
=20
jim

-----Original Message-----
From: Pedro F=E9lix [mailto:[e-mail]]
Sent: Friday, January 21, 2000 2:26 AM
To: Tolga Acar; [e-mail]
Subject: Re: Binding between keys and schemes?



First of all, thanks for your reply.
=20
I apologise for not making my question clear.

When I asked about the binding between a key and a scheme, I was not
refering to the scheme used to sign the certificate.
=20
Let's supose that  ALICE, running protocol P, want's to send a PKCS#7
Envelope to BOB, and has a X.509 certificate of BOB's public key (with
rsaEncryption OID on the subjectPublicKeyInfo field). The certificate =
was
signed with scheme X (eg. DSA) and was correctly verified by ALICE =
using
that scheme.
Which ENCRYPTION scheme should ALICE use to build the Envelope? (
RSAES-PKCS1-v1_5, RSAES-OAEP , ...)
Probably ALICE would want to use the new RSAES-OAEP, but does BOB =
support
it?
If I understood you correctly, this binding between the key and the =
scheme
IS NOT made by a X.509 certificate (except when the retation is 1-1) =
and has
to be built by other means (possibly defined by the protocol P). I'm I
right?
=20
I assume that the source of my initial confusion comes from the fact =
that,
in PKCS#1, the same OID (rsaEncryption) is used to identify both a key =
and a
encryption scheme.
=20
=20
Once again, I thank you for your reply
=20
Best regards
=20
- Pedro Felix


------_=_NextPart_001_01BF66E4.98F2C2AA
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3DSHTML name=3DNERATOR 5.00.2314.1000?>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffff style=3D"ONT: " 10pt Arial; MARGIN-LEFT: 2px; =
MARGIN-TOP:=20
2px?>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D044222903-25012000>My=20
personal opinion on this issue is that in the absense of other =
knowledge=20
PKCS1-v1_5 would be used.&nbsp; If the S/MIME capabilities contained =
the OID for=20
OAEP, then it could be used instead.&nbsp; The certificate does not =
state which=20
scheme is to be used (just as it does not state that 3DES or RC5 should =
be the=20
bulk encryption algorithm used).</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D044222903-25012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D044222903-25012000>jim</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Pedro F=E9lix=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, January 21, 2000 2:26 =

  AM<BR><B>To:</B> Tolga Acar; [e-mail]<BR><B>Subject:</B> Re: =
Binding=20
  between keys and schemes?<BR><BR></DIV></FONT>
  <DIV><FONT face=3DArial size=3D2>
  <DIV><FONT face=3DArial size=3D2>First of all, thanks for your =
reply.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I apologise for not making my =
question=20
  clear.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>
  <DIV>
  <DIV>When I asked about the binding between a key and a scheme, I was =
not=20
  refering to the scheme used to sign the certificate.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Let's supose that&nbsp; ALICE, running protocol P, want's to =
send a=20
  PKCS#7 Envelope to BOB, and has a X.509 certificate of BOB's public =
key=20
  (with&nbsp;rsaEncryption OID on the subjectPublicKeyInfo field). The=20
  certificate was signed&nbsp;with scheme X (eg. DSA) and was correctly =
verified=20
  by ALICE using that scheme.</DIV>
  <DIV>Which&nbsp;ENCRYPTION scheme should ALICE use to build the =
Envelope? (=20
  RSAES-PKCS1-v1_5, RSAES-OAEP , ...)</DIV>
  <DIV>Probably ALICE would want to use the new RSAES-OAEP, but does =
BOB support=20
  it?</DIV>
  <DIV>If I understood you correctly, this binding between the key and =
the=20
  scheme&nbsp;IS NOT made by a X.509 certificate (except when the =
retation is=20
  1-1) and has to be built by other means (possibly defined by the =
protocol P).=20
  I'm I right?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I assume that the source of my initial confusion comes from the =
fact=20
  that, in PKCS#1, the same OID (rsaEncryption) is used to identify =
both&nbsp;a=20
  key and a encryption scheme.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Once again, I thank you for your reply</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Best regards</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>- Pedro=20
Felix</FONT></FONT></DIV></DIV></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BF66E4.98F2C2AA--


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 QAA13757 for <[e-mail]>; Mon, 24 Jan 2000 16:34:33 -0800 (PST)
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 TAA182276; Mon, 24 Jan 2000 19:35:03 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id TAA158720; Mon, 24 Jan 2000 19:36:07 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256871.00034B4F ; Mon, 24 Jan 2000 19:35:58 -0500
X-Lotus-FromDomain: IBMUS
To: Massimiliano Pala <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 24 Jan 2000 19:32:14 -0500
Subject: Re: OCSP and CSL
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Massimiliano Pala <[e-mail]>@toutatis.comune.modena.it on
01/24/2000 12:51:03 PM

Sent by:  [e-mail]


To:   [e-mail]
cc:
Subject:  OCSP and CSL



Hi all,

(first of all I apologize for my english(?), now let's go on ... )

working about an OCSP server to be included in the OpenCA package
I found very strange the lack of some kind of CSL (Certificate
Suspension List). If there is something similar I'm not aware of,
please report it and ignore this mail ...

For CSL I mean a sort of CRL (same structures, formats), but carrying
a list of only suspended certificates: this is obviously useful for
ocsp implementations and considering the fact that in most env you'll
not be requested for certificate status changing very often, issuing
this kind of lists, I think, could be useful.

[Tom Gindin] I believe that a CSL, in this sense, is probably just a CRL
whose issuingDistributionPoint extension contains an onlySomeReasons field
specifying the certificateHold bit and no other bit.  This doesn't require
any change to the standards.  However, it does bring up another point.  Why
is certificateHold included in ReasonFlags but not removeFromCRL?  If a
delta CRL is issued for a CRL partitioned by reason code, it seems to me
from the definition of issuingDistributionPoint that removeFromCRL could
only be included in a delta CRL with the onlySomeReasons field missing,
which goes against the point of having CRL's partitioned on a reason code
basis at all.  If it is assumed that entries with reason removeFromCRL are
permitted in any delta CRL whenever ReasonFlags contains certificateHold,
we should probably amend the IDP extension description to make this clear.

(snip)




Received: from sentry ([e-mail] [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA08428 for <[e-mail]>; Mon, 24 Jan 2000 10:18:14 -0800 (PST)
Received: by sentry; id NAA28263; Mon, 24 Jan 2000 13:21:05 -0500 (EST)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma028214; Mon, 24 Jan 00 13:20:35 -0500
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id NAA12482 for [e-mail]; Mon, 24 Jan 2000 13:16:24 -0500 (EST)
Date: Mon, 24 Jan 2000 13:16:24 -0500 (EST)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Last chance to register for NDSS 2000

L A S T   C H A N C E   -  R E G I S T E R   F O R   N D S S   2 0 0 0

THE INTERNET SOCIETY'S
Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 2-4, 2000
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Gene Tsudik, USC/Information Sciences Institute
		 Avi Rubin, AT&T Labs - Research

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss2000
REGISTER ONLINE ON OR BEFORE WEDNESDAY, JANUARY 26
REGISTER ONSITE AFTER WEDNESDAY, JANUARY 26

The 7th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at
Purdue University, an expert in information security, computer crime
investigation and information ethics.  Spaf (as he is known to his
friends, colleagues, and students) is director of the Purdue CERIAS
(Center for Education and Research in Information Assurance and
Security), and was the founder and director of the (now superseded)
COAST Laboratory. 

THIS YEAR'S TOPICS INCLUDE:
- Automated Detection of Buffer Overrun Vulnerabilities
- User-Level Infrastructure for System Call Interposition
- Optimized Group Rekey for Group Communication Systems
- IPSec-based Host Architecture for Secure  Internet Multicast
- The Economics of Security
- Automatic Generation of Security Protocols
- Security Protocols for SPKI-based Delegation Systems
- Secure Border Gateway Protocol (S-BGP)
- Analysis of a Fair Exchange Protocol
- Secure Password-Based Protocols for TLS
- Chameleon Signatures
- Lightweight Tool for Detecting Web Server Attacks
- Adaptive and Agile Applications Using Intrusion Detection
- Secure Virtual Enclaves
- Encrypted rlogin Connections Created With Kerberos IV
- Accountability and Control of Process Creation in Metasystems
- Red Teaming and Network Security

PRE-CONFERENCE TECHNICAL TUTORIALS:
- Network Security Protocol Standards, Dr. Stephen T. Kent
- Deployed and Emerging Security Systems for the Internet, Dr. Radia
  Perlman and Charlie Kaufman
- Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw
- Cryptography 101, Dr. Aviel D. Rubin
- Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel
  E. Geer, Jr.
- An Introduction to Intrusion Detection Technology, Mr. Mark Wood 

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA
  Phone: [phone]         Fax: [phone]
  E-mail: [e-mail]   URL: http://www.isoc.org/ndss2000/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at [phone] or send e-mail to [e-mail].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.



Received: from toutatis.comune.modena.it (monet.comune.modena.it [195.223.135.239]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA07789 for <[e-mail]>; Mon, 24 Jan 2000 09:49:04 -0800 (PST)
Received: from comune.modena.it (everian.comune.modena.it [192.168.5.122]) by toutatis.comune.modena.it (8.9.1a/8.9.1) with ESMTP id SAA11968 for <[e-mail]>; Mon, 24 Jan 2000 18:50:05 +0100 (MET)
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 24 Jan 2000 18:51:03 +0100
From: Massimiliano Pala <[e-mail]>
Organization: Comune di Modena
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: OCSP and CSL
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2DF8506888775C28A74B2BED"

This is a cryptographically signed message in MIME format.

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

Hi all,

(first of all I apologize for my english(?), now let's go on ... )

working about an OCSP server to be included in the OpenCA package
I found very strange the lack of some kind of CSL (Certificate
Suspension List). If there is something similar I'm not aware of,
please report it and ignore this mail ...

For CSL I mean a sort of CRL (same structures, formats), but carrying
a list of only suspended certificates: this is obviously useful for
ocsp implementations and considering the fact that in most env you'll
not be requested for certificate status changing very often, issuing
this kind of lists, I think, could be useful.

First of all the software can, with very few modification, support
this kind of lists because them are built exactly like CRLs (but
them carry informations only on suspension: this can occour for
example when a certificate is requested for revokation but the request
have not been processed by the CA (think about network disconnected
CAs)). These lists can be signed by, let's say, the OCSP server
(certificate assigned to the OCSP authority or another certificate
issued for this porpouse and placed on a network-connected station) and
issued whenever a new certificate is suspended or its state is
changed to revoke/valid . When this last option happens the certificate
simply do not appear on the suspension list.

The correct status of a certificate, then, can be given by the
couple CSL/CRL without having to support OCSP or other protocols and
moreover the CSL are the same as CRLs so you don't have to rewrite
most of the software ... think about Apache (that now correctly
checks CRLs) ... 

Is there anything like this around ??? Do you think this could be
useful or not ??? In case you approve I can take in charge of writing
an initial rfc for publication if needed to ...

Please report ANY comments :-D

C'you,

	Massimiliano Pala ([e-mail])
--------------ms2DF8506888775C28A74B2BED
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

MIIGCQYJKoZIhvcNAQcCoIIF+jCCBfYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BGowggRmMIIDTqADAgECAgEBMA0GCSqGSIb3DQEBBAUAMEAxIDAeBgNVBAMTF0NlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUMB4XDTAwMDEw
ODEzMTQxMFoXDTAxMDEwNzEzMTQxMFowfTELMAkGA1UEBhMCSVQxDzANBgNVBAoTBk9wZW5D
QTEYMBYGA1UECxMPUHJvamVjdCBNYW5hZ2VyMRowGAYDVQQDExFNYXNzaW1pbGlhbm8gUGFs
YTEnMCUGCSqGSIb3DQEJARYYbWFkd29sZkBjb211bmUubW9kZW5hLml0MIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQDD4B0j/dIU/BNfACreVXy/sS50Gs2GcQeAbZ1b4xyCXcMrbKKU
bELUkEm1FiICH1+RmxFnZ0F/qRxnQeN+MuCKyT5GUWE99hq3F8VDGG3TA4BeOBrNON1XsBmA
HGFHGTsx1O6yXf/MLu5h3evgm3m7BzTHX0GA4o2XlFzT7355xQIDAQABo4IBsDCCAawwCQYD
VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCYGCWCGSAGG+EIBDQQZ
FhdPcGVuQ0EgVXNlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUFuA3AT3C8B/v895AoTKVG6an
QDIwaAYDVR0jBGEwX4AUC0vTyLH0xspcz3nRq3y//JFIx3uhRKRCMEAxIDAeBgNVBAMTF0Nl
cnRpZmljYXRpb24gQXV0aG9yaXR5MQ8wDQYDVQQKEwZPcGVuQ0ExCzAJBgNVBAYTAklUggEA
MCMGA1UdEQQcMBqBGG1hZHdvbGZAY29tdW5lLm1vZGVuYS5pdDAJBgNVHRIEAjAAMDQGCWCG
SAGG+EIBBAQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDQGCWCG
SAGG+EIBAwQnFiVodHRwczovL3d3dy5vcGVuY2Eub3JnL2NnaS1iaW4vZ2V0Y3JsMDIGCWCG
SAGG+EIBBwQlFiNodHRwczovL3d3dy5vcGVuY2Eub3JnOjQ0NDMvcmVuZXdhbDANBgkqhkiG
9w0BAQQFAAOCAQEABBmB/B+v0OzbomKAXSzzfTpMYIwCYu1nFNpr0MOektBVt1BIrwlVSolz
wayqWAvIfwmNZy+l0rsTH4eRr7MUq18CnvwZOawzL/RintrPKEsUS4A7LZB754RXzu0DezdX
e7QNtMKrC7SnLaozXUbPxsA/8nRSMj8bAUPxkY8J4LK64a8dq65upRY0BV4gHvBqmCw7PpIk
4S14npKCvMbctuOs/aUshMko8y0l/Rzr4mb2Cophz28qpK9TTGkyf1zRJEOTWXiVqY6aTvWU
pO30kHTxYcxgDG4p5a5I4tgqs6UWx+S2tJXiP5CBPO9MLXbb5VuzTkqglDpTsL8eOkG7bTGC
AWcwggFjAgEBMEUwQDEgMB4GA1UEAxMXQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxDzANBgNV
BAoTBk9wZW5DQTELMAkGA1UEBhMCSVQCAQEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzEL
BgkqhkiG9w0BBwEwGwYJKoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUx
DxcNMDAwMTI0MTc1MTAzWjAjBgkqhkiG9w0BCQQxFgQUitfiUwztYI86FBYtXMSZx7jTv6Uw
DQYJKoZIhvcNAQEBBQAEgYAA4a0bk8M9nyGBB6cw3afEAEI307LKBOXNUpM9I3u2WqlxhiTu
rzhi4XBYzRk8SnXiMRiw5/U4pEmXP+D8dAid0HAZCj/aqeMcZcvt9YEZ0yd2ACg0+SB9P1Pf
yPhOhed1NKlPDM95KFyJAsHBmywco1pUh6biL94UcUvUpIGeqA==
--------------ms2DF8506888775C28A74B2BED--



Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA09617 for <[e-mail]>; Sun, 23 Jan 2000 14:10:15 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 Jan 2000 14:11:28 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21) id <DFRQ869M>; Sun, 23 Jan 2000 14:11:28 -0800
Message-ID: <[e-mail]>
From: Trevor Freeman <[e-mail]>
To: "Pkix List (E-mail)" <[e-mail]>
Subject: Some Issues and observations with the son of 2459
Date: Sun, 23 Jan 2000 14:11:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF65EE.CBDFC588"

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_01BF65EE.CBDFC588
Content-Type: text/plain;
	charset="iso-8859-1"

RFC 2459 chains vs. son of RFC 2459 chains
We will have two sets of semantics under which certificates can be issued -
RFC 2459, and son of RFC 2459, and two sets of rules for processing those
chains. In moving forward, two objectives which we must meet are:

*	When a new son of 2459 client is deployed into an existing 2459 PKI
it must not break with the deployed population of certificates
*	There must be no requirement to reissue certificates in order to
deploy the new clients.

At the root of the problem is the clarification of what a new son of 2459
client must do if it encounters a chain which does not comply with the more
restrictive son of 2459 policy rules. If that chain was issued under the new
rules, it is indeed a bad chain and verification should fail. If it was
build under the 2459 rules, it is a "legacy chain" which is still valid.
There must be some mechanism to indicate if a certificate was issued under
son of 2459 rules. A possible solution to this would be to assign a "policy
semantics version" OID which must be included in every non self signed
certificate issued under the new rules in the policy extension. A single
2459 certificate in a chain potentially downgrades the chain to 2459 rules.
We can continue to process policy as currently defined, but if we end up
with an empty set, and one of the certificates in the chain does not contain
the policy version OID, we return that verification was successful with an
empty policy set. There are other possibilities for how to distinguish the
certificates such as assigning a new OID to the policy extension and include
both extensions in issued certificates, but at this stage, they seem more
expensive so I would like to see a very strong case in there favour before I
would consider them.
Name Constraint Processing
The current draft does not deal with the case where a certificate contains a
name in an unconstrained namespace. The current wording in the draft in
effect means that if a namespace has not constrained, it is allowed. I would
prefer to move to a model where the CA must explicitly state which
namespaces it wishes to allow, and all others are rejected.
Another problem with Name constraints is the relationships between
namespaces is not considered. Many namespaces can be traced back to DNS
names or IP addresses. URIs are a case in point. The host potion of a URI
(e.g. the name between the second and third forward slashes) can be either a
DNS name or an IP address. When a restriction on a DNS name or IP address is
made, then any other form of that same address (i.e. the host address in a
URI) must conform to the larger rule. The same may equally be said of email
addresses.
EKU Policy
EKU is an extension of policy. Having let the genie out of the bottle, it
will take some time to get it back in. To be consistent with the new rule, I
propose to make it a requirement that under son of 2459 rules, any OID in
the EKU extension must also be present in the policy extension. Any
certificate issued under the new rules where this rule is not met, is to be
considered invalid. Application developers can now migrate to using the
policy extension in stead of the EKU extension, and in time the EKU
extension can be phased out. Policy in the EKU extension will be consistent
with the other policy requirements. In the mean time, existing applications
will not break.
Other Policy Qualifiers
There are only two defined policy qualifiers in the current draft. We have
encountered two instances where other qualifiers are useful. I offer this
observation, for others who may also find them useful and hence like them to
them being more generally used and therefore including them in the draft. 
The first is in restricting the scope of a RA by using a name constraint as
a qualifier on the RA policy OID. This allows the CA to verify the RAs
ability to act for the subject for any given policy. 
The other case is providing some hint to relative authentication strength of
a certificate. If a user has a medium and a strong authentication
certificate which can both be used fro the same application e.g. client
authentication, then it provides a hint which certificate to use to the
client . Having a policy qualifier with a integer for the relative values
allows the client to know which was issued  with the stronger authentication
policy without any other out of band information.
 
Trevor Freeman
Program Manager
Tel: [phone]
Pager: 800-759-8352, id#1631457
Pager email:  <mailto:[e-mail]> [e-mail]
 

------_=_NextPart_001_01BF65EE.CBDFC588
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000><STRONG>RFC 2459 
chains vs. son of RFC 2459 chains</STRONG></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>We will have two 
sets of semantics under which certificates can be issued - RFC 2459, and son of 
RFC 2459, and two sets of rules for processing those chains. In moving forward, 
two objectives which we must meet are:</SPAN></FONT></DIV>
<UL>
  <LI><FONT face=Arial size=2><SPAN class=359074222-14012000>When a new son of 
  2459 client is deployed into an existing 2459 PKI it must not break with the 
  deployed population of certificates</SPAN></FONT></LI>
  <LI><FONT face=Arial size=2><SPAN class=359074222-14012000>There must be no 
  requirement to reissue certificates in order to deploy the new 
  clients.</SPAN></FONT></LI></UL>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>
<DIV><SPAN class=359074222-14012000>At the root of the problem is the 
clarification of what a new son of 2459 client must do if it encounters a chain 
which does not comply with the more restrictive son of 2459 policy rules. If 
that chain was issued under the new rules, it is indeed a bad chain and 
verification should fail. If it was build under the 2459 rules, it is a "legacy 
chain" which is still valid.</SPAN></DIV></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>There must be some 
mechanism to indicate if a certificate&nbsp;was issued under son of 2459 rules. 
A possible solution to this would be to assign a "policy semantics version" OID 
which must be included in every non self signed certificate issued under the new 
rules in the policy extension. A single 2459 certificate in a chain 
potentially&nbsp;downgrades the chain to 2459 rules. We can continue to process 
policy as currently defined, but if we end up with an empty set,&nbsp;and one of 
the certificates in the chain does not contain the policy version OID, 
we&nbsp;return that verification was successful with an empty policy set. There 
are other possibilities for how to distinguish the certificates such 
as&nbsp;assigning a new OID to the policy extension and include both extensions 
in issued certificates, but at this stage, they seem more expensive so I would 
like to see a very strong case in there favour before I would consider 
them.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000><STRONG>Name 
Constraint Processing</STRONG></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>The current draft 
does not deal with the case where a certificate contains a name in an 
unconstrained namespace. The current wording in the draft in effect means that 
if a namespace has not constrained, it is allowed. I would prefer to move to a 
model where the CA must explicitly state which namespaces it wishes to allow, 
and all others are rejected.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>Another problem with 
Name constraints is the relationships between namespaces is not considered. Many 
namespaces can be traced back to DNS names or IP addresses. URIs are a case in 
point. The host potion of a URI (e.g. the name between the second and third 
forward slashes) can be either a DNS name or an IP address. When a restriction 
on a DNS name or IP address is made, then any other form of that same 
address&nbsp;(i.e.&nbsp;the host address in a URI) must conform to the larger 
rule. The same may equally be said of email addresses.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000><STRONG>EKU 
Policy</STRONG></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>EKU is an extension 
of policy. Having let the genie out of the bottle, it will take some time to get 
it back in. To be consistent with the new rule, I propose to make it a 
requirement that under son of 2459 rules, any OID in the EKU extension must also 
be present in the policy extension. Any certificate issued under the new rules 
where this rule is not met, is to be considered invalid. Application developers 
can now migrate to using the policy extension in stead of the EKU extension, and 
in time the EKU extension can be phased out. Policy in the EKU extension will be 
consistent with the other policy requirements. In the mean time, existing 
applications will not break.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000><STRONG>Other Policy 
Qualifiers</STRONG></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>There are only two 
defined policy qualifiers in the current draft. We have encountered two 
instances where other qualifiers are useful. I offer this observation, 
for&nbsp;others who may also find them useful and hence like them to them being 
more generally used and therefore including them in the draft. 
</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>The first is in 
restricting the scope of a RA by using a name constraint as a qualifier on the 
RA policy OID. This allows the CA to verify the RAs ability to act for the 
subject for&nbsp;any given policy. </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=359074222-14012000>The other case is 
providing some hint to relative authentication strength of a certificate. If a 
user has a medium and a strong authentication certificate which can both be used 
fro the same application e.g. client authentication, then it provides a hint 
which certificate to use to the client . Having a policy qualifier with a 
integer for the relative values allows the client to know which was issued&nbsp; 
with the stronger authentication policy without any other out of band 
information.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=359074222-14012000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><STRONG>Trevor 
Freeman</STRONG></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><STRONG>Program 
Manager</STRONG></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=1><STRONG>Tel: 
425-936-847</STRONG></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=1><STRONG>Pager: 800-759-8352, 
id#1631457</STRONG></FONT></DIV>
<DIV><STRONG><FONT color=#0000ff face=Arial size=1>Pager email: </FONT><A 
href="mailto:[e-mail]"><FONT face=Arial 
size=1>[e-mail]</FONT></A></STRONG></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01BF65EE.CBDFC588--


Received: from 5sigexch7.hq.5sigcmd.army.mil (5sigexch7.hq.5sigcmd.army.mil [147.40.43.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04447 for <[e-mail]>; Fri, 21 Jan 2000 05:58:08 -0800 (PST)
Received: by 5sigexch7.hq.5sigcmd.army.mil with Internet Mail Service (5.5.2650.10) id <Z03CYYB5>; Fri, 21 Jan 2000 14:58:32 +0100
Message-ID: <[e-mail]>
From: "Stringfield, Robert Mr." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Use of DOD PKI Cert with the  X.400 Address
Date: Fri, 21 Jan 2000 14:58:31 +0100
X-Mailer: Internet Mail Service (5.5.2650.10)

>  I am the PM for the DOD PKI MGS Pilot
> (http://www.5sigcmd.army.mil/pki/pki.htm) which is based in Germany.  If
> able to use  either the X.400 or SMTP with the DOD PKI Cert it would be of
> great benefit to the WarFighter because of restrictions between home and
> base sites.
> 
> Also I am looking into the tying of the cert to multiple email addresses
> which would be another 'huge' benefit.  Any advice would be extremely
> helpful or pointers to the correct information source.  Thanks..
> --bob
> 
> 	Robert L. Stringfield
> 	DMS/PKI 5th Signal Command
> 	DSN: 380-5857 FAX: [phone]
> 	mailto:[e-mail]
> 	http://www.5sigcmd.army.mil/DMS/dms.htm
> 	http://www.5sigcmd.army.mil/pki/pki.htm
> 	http://144.170.207.251/archives/index.html
> 	Truth:  We own the Night!!! - DeathStar Warriors
> 
> 


Received: from mail.isel.pt (aquario.isel.pt [193.137.220.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26971 for <[e-mail]>; Fri, 21 Jan 2000 02:22:31 -0800 (PST)
Received: from minho (dyn-96.cc.net.isel.pt [192.168.4.96]) by mail.isel.pt (8.9.3/8.9.3/PRNCAJ) with SMTP id KAA19201; Fri, 21 Jan 2000 10:22:56 GMT
Message-ID: <027601bf63f9$e3396820$[e-mail]>
From: =?iso-8859-1?Q?Pedro_F=E9lix?= <[e-mail]>
To: "Tolga Acar" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Binding between keys and schemes?
Date: Fri, 21 Jan 2000 10:25:35 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0273_01BF63F9.DAEEE8C0"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0273_01BF63F9.DAEEE8C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

First of all, thanks for your reply.

I apologise for not making my question clear.
When I asked about the binding between a key and a scheme, I was not =
refering to the scheme used to sign the certificate.

Let's supose that  ALICE, running protocol P, want's to send a PKCS#7 =
Envelope to BOB, and has a X.509 certificate of BOB's public key (with =
rsaEncryption OID on the subjectPublicKeyInfo field). The certificate =
was signed with scheme X (eg. DSA) and was correctly verified by ALICE =
using that scheme.
Which ENCRYPTION scheme should ALICE use to build the Envelope? ( =
RSAES-PKCS1-v1_5, RSAES-OAEP , ...)
Probably ALICE would want to use the new RSAES-OAEP, but does BOB =
support it?
If I understood you correctly, this binding between the key and the =
scheme IS NOT made by a X.509 certificate (except when the retation is =
1-1) and has to be built by other means (possibly defined by the =
protocol P). I'm I right?

I assume that the source of my initial confusion comes from the fact =
that, in PKCS#1, the same OID (rsaEncryption) is used to identify both a =
key and a encryption scheme.


Once again, I thank you for your reply

Best regards

- Pedro Felix

------=_NextPart_000_0273_01BF63F9.DAEEE8C0
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=3DSHTML name=3DNERATOR 5.00.2314.1000?>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffff style=3D"ONT: " 2px? MARGIN-TOP: 2px; =
MARGIN-LEFT: Arial;=20
10pt>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>First of all, thanks for your =
reply.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I apologise for not making my question=20
clear.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV>
<DIV>When I asked about the binding between a key and a scheme, I was =
not=20
refering to the scheme used to sign the certificate.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Let's supose that&nbsp; ALICE, running protocol P, want's to send a =
PKCS#7=20
Envelope to BOB, and has a X.509 certificate of BOB's public key=20
(with&nbsp;rsaEncryption OID on the subjectPublicKeyInfo field). The =
certificate=20
was signed&nbsp;with scheme X (eg. DSA) and was correctly verified by =
ALICE=20
using that scheme.</DIV>
<DIV>Which&nbsp;ENCRYPTION scheme should ALICE use to build the =
Envelope? (=20
RSAES-PKCS1-v1_5, RSAES-OAEP , ...)</DIV>
<DIV>Probably ALICE would want to use the new RSAES-OAEP, but does BOB =
support=20
it?</DIV>
<DIV>If I understood you correctly, this binding between the key and the =

scheme&nbsp;IS NOT made by a X.509 certificate (except when the retation =
is 1-1)=20
and has to be built by other means (possibly defined by the protocol P). =
I'm I=20
right?</DIV>
<DIV>&nbsp;</DIV>
<DIV>I assume that the source of my initial confusion comes from the =
fact that,=20
in PKCS#1, the same OID (rsaEncryption) is used to identify both&nbsp;a =
key and=20
a encryption scheme.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Once again, I thank you for your reply</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Pedro Felix</FONT></FONT></DIV></DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_0273_01BF63F9.DAEEE8C0--



Received: from arista.iris.com (arista.iris.com [198.112.211.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28529 for <[e-mail]>; Thu, 20 Jan 2000 14:05:12 -0800 (PST)
From: [e-mail]
Subject: NSPW 2000 Call For Papers
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.2  November 4, 1999
Message-ID: <[e-mail]>
Date: Thu, 20 Jan 2000 17:11:14 -0500
X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.2b |December 16, 1999) at 01/20/2000 05:06:52 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

========================================================================
                            Call For Papers
                  New Security Paradigms Workshop 2000
                    An ACM/SIGSAC sponsored workshop
                         19 - 21 September 2000
                   Ballycotton, County Cork, Ireland
                          http://www.nspw.org/
========================================================================

For eight years, the New Security Paradigms Workshop has provided a
productive and highly interactive forum in which innovative new
approaches (and some radical older approaches) to computer security have
been offered, explored, refined, and published. The workshop offers a
constructive environment where experienced researchers and practitioners
work alongside newer participants in the field.  The result is a unique
opportunity to exchange ideas.

New Security Paradigms Workshop (NSPW) 2000 will take place September 19
- 21, 2000 at the Bayview Hotel, Ballycotton, a 45 minute drive from the
Cork airport. In order to preserve the small, intimate nature of the
workshop, participation is limited to authors of accepted papers and
conference organizers. Because these are new paradigms, we cannot
predict what subjects will be covered. Any paper that presents a
significant shift in thinking about difficult security issues or builds
on a previous shift will be welcomed.

The New Security Paradigms Workshop is highly interactive in nature.
Authors are encouraged to present ideas that might be considered risky
in some other forum. All participants are charged with providing
feedback in a constructive manner. The resulting brainstorming
environment has proven to be an excellent medium for furthering the
development of these ideas. The proceedings, published after the
workshop, have consistently benefited from the inclusion of workshop
feedback.

To participate, please submit your paper, justification, and attendance
statement, preferably via e-mail, to both Program Chairs -- Cristina
Serban ([e-mail]) and Brenda Timmerman ([e-mail]) --
by Friday, March 31, 2000 (hardcopy submissions must be received by
Friday, March 24, 2000). Further details on the required format of
submissions follow.

1 - Your Paper
You should submit either a research paper, a 5 - 10 page position paper,
or a discussion topic proposal. Submissions of any type must not have
been published elsewhere. Discussion topic proposals should include an
in-depth description of the topic to be discussed, a convincing argument
that the topic will lead to a lively discussion, and any other
supporting materials.

Softcopy submissions should be in Postscript or ASCII format. Papers may
be submitted in hardcopy. To submit hardcopy, please mail 5 (five)
copies to Program co-chair Cristina Serban. Please allow adequate time
for delivery.

2 - Justification
You should describe, in one page or less, why your paper is appropriate
for the New Security Paradigms Workshop. A good justification will
describe the new paradigm being proposed, explain how it is a departure
from existing theory or practice, and identify those aspects of the
status quo it challenges or rejects.

3 - Attendance Statement
You should state how many authors wish to attend the workshop. Accepted
papers require the attendance of at least one author. In order to ensure
that all papers receive equally strong feedback, all attendees are
expected to stay for the entire duration of the workshop.

The program committee will referee the papers and notify the authors of
acceptance status by June 9, 2000. We expect to be able to offer a
limited number of scholarships. More information will be provided on our
web site (http://www.nspw.org/) as it becomes available.

Workshop Co-Chairs

Mary Ellen Zurko                 Steven J. Greenwald
Iris Associates                  2521 NE 135th Street
230 Nashua Rd.                   North Miami, FL 33181 USA
Groton, MA 01450 USA             e-mail: [e-mail]
e-mail: [e-mail]          voice: [phone]
voice: [phone]         fax [phone]
fax: [phone]

Program Committee Co-Chairs

Cristina Serban                  Brenda Timmerman
AT&T Labs                        California State University
307 Middletown-Lincroft Rd.      18111 Nordhoff St.
Lincroft, NJ 07738 USA           Northridge, CA 91330-8281 USA
e-mail:   [e-mail]        e-mail: [e-mail]
voice: [phone]         voice: [phone]
fax: [phone]           fax: [phone]

Program Committee
Bob Blakley, Tivoli
Heather Hinton, Tivoli
Erland Jonsson, Chalmers University of Technology
Clifford Kahn, EMC Corporation
Darrell Kienzle, The MITRE Corporation
Jun Li, UCLA
Catherine Meadows, Naval Research Laboratory
Susan Pancho, University of Cambridge
Dean Povey, DSTC
Thomas Riechmann, Siemens
Marvin Schaefer, ARCA Systems
John Michael Williams

Local Arrangements
Simon Foley (University College, Cork, Ireland) [phone]

Scholarships
Hilary Hosmer (Data Security Inc.) [phone]
John McHugh (SEI/CERT) [phone]

Publications
Marvin Schaefer (ARCA Systems) [phone]

Publicity
Crispin Cowan (WireX Communications, Inc.) [phone]

ACM-SIGSAC Chair
Ravi Sandhu (George Mason University) [phone]

Steering Committee
Bob Blakley, Steven J. Greenwald, Hilary Hosmer, Darrell Kienzle,
Catherine Meadows, Cristina Serban, Brenda Timmerman, Mary Ellen Zurko




Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA24216 for <[e-mail]>; Thu, 20 Jan 2000 09:26:25 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 20 Jan 2000 10:27:10 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Thu, 20 Jan 2000 10:25:57 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Binding between keys and schemes?
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_ECB55E7E.C8A989EC"

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.

--=_ECB55E7E.C8A989EC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There are two relevant OIDs
a. The OID encoded in the subjectPublicKeyInfo, which merely describeds =
how to interpret the public key in it,
b. the signature OID, that describes which algorithm is used to sign the =
whole certificate

These two OIDs don't have anything to do with each other - at least not =
necessarily.
In theory, you can put a custom encoded XYZ algorithm public key, and sign =
it with ABC algorithm with "a" key.
Following this, one can use a PKCS#1 encoded public key with more than one =
algorithm, with each algorithm having its own OID - not the key; and i =
don't see a problem here.
The signature algorithm describes the math and the encoding of the output =
from the math, not the key. Some of the signature algorithms may require =
the input key in a certain format - but this relation doesn't have to be =
bijective.

Thus,

1) a PKCS#1 version x.y encoded public key can be used in N number of =
different algorithms. And, this does not conflict with the key formatting, =
i.e., PKCS#1
2) A certificate's signature algorithm can be anything (see RFC ABCD for =
restrictions), and does not depend on the key format.=20

- Tolga


>>> Pedro F=E9lix <[e-mail]> 1/20/00 3:42:48 >>>
1) As defined by PKCS#1 v2.0 an RSA key can be used in two diferent
encryption schemes:
rsaEncryption (PKCS#1 v1.5 scheme) and the new OAEP based scheme
(id-RSAES-OAEP OID).
Is a PKIX certificate with rsaEncryption OID (on the subjectPublicKeyInfo)
binded only to the first scheme?

2) Probably in the future there will be various signature and encryption
schemes using the same type of key. As an example the P1363 draft 11 =
defines
two signature schemes IFSP-RSA1 and IFSP-RSA2 used with an Encoding method
(EMSA2) that can be updated in the future. They all use the same type of =
IF
(RSA) key.
How will an certificate manage this 1<->N relation between keys and =
schemes?
There will be a different certificate for each scheme or the same key
certificate will be used with different schemes?
If the second applies, how will the schemes capabilities of a certificate
subject be identified?

I gave a quick browse on the archives and didn't found any reference to =
this
subject?

I apologise if this question is off-topic or doesn't make sense in this
context!
I also thanks (in advance) any replies.

Pedro Felix
Centro de Calculo do Instituto Superior de Engenharia de Lisboa.

--=_ECB55E7E.C8A989EC
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="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff 
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>There are two relevant OIDs</DIV>
<DIV>a. The OID encoded in the subjectPublicKeyInfo, which merely describeds how 
to interpret the public key in it,</DIV>
<DIV>b. the signature OID, that describes which algorithm is used to sign the 
whole certificate</DIV>
<DIV>&nbsp;</DIV>
<DIV>These two OIDs don't have anything to do with each other - at least not 
necessarily.</DIV>
<DIV>In theory, you can put a custom encoded XYZ algorithm public key, and sign 
it with ABC algorithm with "a" key.</DIV>
<DIV>Following this, one can use a PKCS#1 encoded public key with more than one 
algorithm, with each algorithm having its own OID - not the key; and i don't see 
a problem here.</DIV>
<DIV>The signature algorithm&nbsp;describes the math and the encoding of the 
output from the math,&nbsp;not the key. Some of the signature algorithms may 
require the input key in a certain format - but this&nbsp;relation doesn't have 
to be bijective.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thus,</DIV>
<DIV>&nbsp;</DIV>
<DIV>1) a PKCS#1 version x.y encoded public key can be used in N number of 
different algorithms. And, this does not conflict with the key formatting, i.e., 
PKCS#1</DIV>
<DIV>2)&nbsp;A certificate's signature algorithm can be anything (see RFC ABCD 
for restrictions), and does not depend on the key format. </DIV>
<DIV>&nbsp;</DIV>
<DIV>- Tolga</DIV>
<DIV><BR><BR>&gt;&gt;&gt; Pedro Félix &lt;[e-mail]&gt; 1/20/00 3:42:48 
&gt;&gt;&gt;<BR>1) As defined by PKCS#1 v2.0 an RSA key can be used in two 
diferent<BR>encryption schemes:<BR>rsaEncryption (PKCS#1 v1.5 scheme) and the 
new OAEP based scheme<BR>(id-RSAES-OAEP OID).<BR>Is a PKIX certificate with 
rsaEncryption OID (on the subjectPublicKeyInfo)<BR>binded only to the first 
scheme?<BR><BR>2) Probably in the future there will be various signature and 
encryption<BR>schemes using the same type of key. As an example the P1363 draft 
11 defines<BR>two signature schemes IFSP-RSA1 and IFSP-RSA2 used with an 
Encoding method<BR>(EMSA2) that can be updated in the future. They all use the 
same type of IF<BR>(RSA) key.<BR>How will an certificate manage this 1&lt;-&gt;N 
relation between keys and schemes?<BR>There will be a different certificate for 
each scheme or the same key<BR>certificate will be used with different 
schemes?<BR>If the second applies, how will the schemes capabilities of a 
certificate<BR>subject be identified?<BR><BR>I gave a quick browse on the 
archives and didn't found any reference to this<BR>subject?<BR><BR>I apologise 
if this question is off-topic or doesn't make sense in this<BR>context!<BR>I 
also thanks (in advance) any replies.<BR><BR>Pedro Felix<BR>Centro de Calculo do 
Instituto Superior de Engenharia de Lisboa.<BR><BR><BR></DIV></BODY></HTML>

--=_ECB55E7E.C8A989EC--


Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20446 for <[e-mail]>; Thu, 20 Jan 2000 05:47:48 -0800 (PST)
From: [e-mail]
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id OAA17078; Thu, 20 Jan 2000 14:47:08 +0100
Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.8.8m2/NCO v2.06) with SMTP id OAA40188; Thu, 20 Jan 2000 14:47:02 +0100
Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C125686C.004B4561 ; Thu, 20 Jan 2000 14:42:09 +0100
X-Lotus-FromDomain: IBMIL@IBMDE
To: [e-mail], [e-mail], [e-mail], [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 20 Jan 2000 15:45:14 +0200
Subject: Trust Establishment on AlphaWorks
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

TrustEstablishment (available now on AlphaWorks at
http://www.alphaworks.ibm.com) is a set of Java packages that can be used to
solve the Trust Management problem. Below is a short description of the Trust
problem and how TE can be used to solve it. More info can be found at
http://www.hrl.il.ibm.com/TrustEstablishment. Any feedback is most appreciated.

Regards, Yosi Mass
Trust Establishment Project Manager,
IBM Haifa Research Lab, Tel Aviv Site
E-mail: [e-mail]
Tel [phone], Fax [phone]

    A new approach to the deployment of public key infrastructure is  presented,
   based on a separation between the issuing of certificates and the usage of
   certificates. Certificates are signed assertions by  the issuer about the
   subject of the certificate (holder of corresponding  private key), not
   necessarily identifying the subject. Typical use of  certificate is for
   access control decisions, to determine whether the  subject is allowed to
   perform a certain action (on some resource); this  decision is based on the
   policy of the owner of the resource. Issuers  do not need to be known to
   resource owners in advance; it is  sufficient that they, in turn, will
   provide sufficient certificates to be  considered a trusted authority
   according to the owner's policy. This  allows bottom-up, `grassroots`
   build-up of trusted issuers.

   Our approach extends, rather than replaces, existing role-based  access
   control mechanisms, by providing automated role assignment. Existing access
   control mechanisms use the identities to map the  subject to a given role,
   based on a static table. Our system maps the subject of the certificates to a
   role, based on the subject's certificates,  on a given role-assignment policy
   set by the owner of the resource,  and on the roles of the issuers of the
   certificates. The role is then fed  as input to the existing role-based
   access control mechanism. This  provides a simple, modular architecture and
   role-assignment policies.

    We describe an implementation called "Trust Establishment (TE)" ,  which can
   be used to provide a complete PKI-enabled web server (or  other e-commerce
   server), or to extend access control systems. A  central element in our
   implementation is a simple yet powerful  Certificate-based Role-Assignment
   Policy Language specified using  XML. We believe that the policy language is
   expressive enough to  allow complex policies, including e.g. non monotone
   (negative)  certificates while being simple enough to allow automated policy
   checking and processing. Processing of the policy is essential, to  ensure
   reasonable efficiency (e.g. in handling a new certificate or  revocation), to
   check policy e.g. for conflicts, to collect missing  certificates, to compose
   policies, and to allow subjects to select which  certificates to present. Our
   system includes an intelligent certificate collector that automatically
   collects missing certificates from peer  servers, allowing the use of
   standard browsers (that pass only one  certificate to the  server).

   Trust Establishment Software
   ========================

   The TE module is written in Java and therefore includes the cross platform
   advantages available to
   Java applications. The module also includes an API toolkit  that programmers
   can use to extend
   the access control abilities of existing applications or web servers.
   All certificates and signatures are implemented through the Zurich Crypto
   Framework package
   from ZRL. The TE software uses a reduced version that does not include
   encryption and therefore
   has no problems with export regulations.

   Certificate Format
   ===============

   The Trust Establishment module uses the X509 V3 certificate format . TE is
   designed to support
   other certificate types; this type was chosen since it is currently the most
   commonly used. The
   certificate subject and issuer are identified by X500 names, where X500
   defines a global directory
   for all names and DN is the distinguished name. The TE does not use these
   X500 names, but
   keeps a unique identifier for a subject/issuer which is derived from their
   public key and is kept in
   the standard extensions : issuer/subject altName.
   The TE module decides on the role for the key so it is not interested in the
   identity of the user;
    hence, the X500 names are not really important. TE uses them because they
   are obligatory for the
    X509 format.

    Related Documents
   =================

    For further information on Trust Establishment, see the following:

                   Trust Establishment home page at
http://www.hrl.il.ibm.com/TrustEstablishment

                   White paper accepted to the 2000 IEEE Symposium on Security
and Privacy available at
                   http://www.hrl.il.ibm.com/TrustEstablishment/paper.asp





Received: from wssone.bj.co.uk (wssone.bj.co.uk [194.72.164.250]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA17397 for <[e-mail]>; Thu, 20 Jan 2000 04:17:35 -0800 (PST)
Received: from 194.72.164.27 by wssone.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 20 Jan 00 12:28:04 -0000
X-Server-Uuid: 1407cc62-e1e1-11d2-808b-0060971f0dc2
Received: from piers2k (host212-140-125-183.host.btclick.com [212.140.125.183]) by bjex1.bj.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Z3MS55VF; Thu, 20 Jan 2000 12:16:36 -0000
Reply-to: [e-mail]
From: "Piers Chivers" <[e-mail]>
To: [e-mail]
Subject: SMIME conformance specs
Date: Thu, 20 Jan 2000 12:19:07 -0000
Message-ID: <000601bf6340$8d7476a0$1a01a8c0@piers2k>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
X-WSS-ID: 149820DE1401-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Hi,
Are there any publicly available docs that describe the conformance
requirements for a PKIX/SMIME compliant messaging client?

I know that the SMIME RFCs detail the protocol requirements for a conforming
app but I was thinking at the level of
"A conforming client must indicate to the user when a message fails a
signature validation" or "A user must be able to encrypt and/or sign an
outgoing message".

Thanks,
Piers




Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16735 for <[e-mail]>; Thu, 20 Jan 2000 03:58:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25176; Thu, 20 Jan 2000 06:59:22 -0500 (EST)
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-technr-00.txt
Date: Thu, 20 Jan 2000 06:59:22 -0500
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 Technical 
                          Requirements for a non-Repudiation Service
	Author(s)	: T. Gindin
	Filename	: draft-ietf-pkix-technr-00.txt
	Pages		: 7
	Date		: 19-Jan-00
	
This document describes those features of a service which processes
signed documents which must be present in order for that service to
constitute a 'technical non-repudiation' service.  A technical
non-repudiation service must permit an independent verifier to
determine whether a given signature was applied to a given data
object by the private key associated with a given valid certificate,
at a time later than the signature.  The features of a technical non-
repudiation service are expected to be necessary for a full non-
repudiation service, although they may not be sufficient.
This document is intended to clarify the definition of the
'non-repudiation' service in RFC 2459.  It should thus serve as a
guide to when the nonRepudiation bit of the keyUsage extension should
be set and to when a Certificate Authority is required to archive
CRL's.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-technr-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 mail.isel.pt (aquario.isel.pt [193.137.220.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12669 for <[e-mail]>; Thu, 20 Jan 2000 02:39:42 -0800 (PST)
Received: from minho (dyn-96.cc.net.isel.pt [192.168.4.96]) by mail.isel.pt (8.9.3/8.9.3/PRNCAJ) with SMTP id KAA26893 for <[e-mail]>; Thu, 20 Jan 2000 10:40:21 GMT
Message-ID: <01ac01bf6333$18c419d0$[e-mail]>
From: =?iso-8859-1?Q?Pedro_F=E9lix?= <[e-mail]>
To: <[e-mail]>
Subject: Binding between keys and schemes?
Date: Thu, 20 Jan 2000 10:42:48 -0000
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

1) As defined by PKCS#1 v2.0 an RSA key can be used in two diferent
encryption schemes:
rsaEncryption (PKCS#1 v1.5 scheme) and the new OAEP based scheme
(id-RSAES-OAEP OID).
Is a PKIX certificate with rsaEncryption OID (on the subjectPublicKeyInfo)
binded only to the first scheme?

2) Probably in the future there will be various signature and encryption
schemes using the same type of key. As an example the P1363 draft 11 defines
two signature schemes IFSP-RSA1 and IFSP-RSA2 used with an Encoding method
(EMSA2) that can be updated in the future. They all use the same type of IF
(RSA) key.
How will an certificate manage this 1<->N relation between keys and schemes?
There will be a different certificate for each scheme or the same key
certificate will be used with different schemes?
If the second applies, how will the schemes capabilities of a certificate
subject be identified?

I gave a quick browse on the archives and didn't found any reference to this
subject?

I apologise if this question is off-topic or doesn't make sense in this
context!
I also thanks (in advance) any replies.

Pedro Felix
Centro de Calculo do Instituto Superior de Engenharia de Lisboa.




Received: from popmail.udac.net (popmail.udac.net [193.44.79.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA10471 for <[e-mail]>; Thu, 20 Jan 2000 01:42:56 -0800 (PST)
Received: from HYDRA ([195.198.186.79]) by popmail.udac.net (8.9.3/8.9.3) with SMTP id KAA28097; Thu, 20 Jan 2000 10:45:45 +0100
Received: by HYDRA with Microsoft Mail id <01BF6332.34EFD230@HYDRA>; Thu, 20 Jan 2000 10:36:27 +0100
Message-ID: <01BF6332.34EFD230@HYDRA>
From: Anders Rundgren <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'SEIS-List'" <[e-mail]>, "'Henrik Bergman'" <[e-mail]>
Subject: US excport rules after Jan-12,2000
Date: Thu, 20 Jan 2000 10:36:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,
A few months I put questions regarding this in this list and apparently the september-1999
deal was impossible to "swallow" or "interpret" and therefore the US department of commerce
have made a new try.

http://204.193.246.62/public.nsf/docs/60D6B47456BB389F852568640078B6C0

It looks much better but does it allow all users (from all but the seven "bad" countries)

1. To download US versions of Internet Explorer or Navigator
2. To buy (over the net) US-issued e-mail certificates with 1024-bit keys
3. To buy US-produced smart cards (using ordinary mail order) containing strong crypto
4. To buy US versions of Windows, Solaris etc. with the same ease as you today buy export versions

If the answer is yes I would say that this would be the biggest boon to PKI since it
was invented!!!

Anders

A strange piece of the new deal is that government users are discriminated  Why?




Received: from www.cryptomathic.dk (cryptomathic.dk [194.239.238.251]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08934 for <[e-mail]>; Thu, 20 Jan 2000 01:19:06 -0800 (PST)
Received: from cryptomathic.com (fw.cryptomathic.dk [10.0.1.1]) by www.cryptomathic.dk (8.9.3/8.9.3) with ESMTP id KAA14385; Thu, 20 Jan 2000 10:42:00 +0100
Message-ID: <[e-mail]>
Date: Thu, 20 Jan 2000 10:20:30 +0100
From: Anette Byskov <[e-mail]>
Reply-To: [e-mail]
Organization: Cryptomathic
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>, Oliver Pfaff <[e-mail]>
Subject: Re: CRMF support
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Cryptomathic's CA product INCA also supports CRMF:
http://www.cryptomathic.dk/products/inca/inca.html

Oliver Pfaff wrote:
> 
> I'm trying to get an overview on vendors/systems that support CRMF as
> certificate request format. According to a quick Internet search,
> Netscape (CMS - Certificate Management System) and Baltimore (UniCERT)
> are supporting CRMF. Are there other vendors/systems supporting CRMF?
> Thanks,
> Oliver

-- 
Anette Byskov                          Cryptomathic A/S
Phone:  [phone]                Klostergade 28
Fax:    [phone]                DK-8000 Aarhus C
http://www.cryptomathic.com/           Denmark


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 KAA11335 for <[e-mail]>; Mon, 17 Jan 2000 10:23:46 -0800 (PST)
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 NAA221350; Mon, 17 Jan 2000 13:23:37 -0500
Received: from D51MTA05.pok.ibm.com (d51mta05.pok.ibm.com [9.117.200.33]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id NAA249368; Mon, 17 Jan 2000 13:24:40 -0500
Received: by D51MTA05.pok.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 85256869.00652195 ; Mon, 17 Jan 2000 13:24:37 -0500
X-Lotus-FromDomain: IBMUS
To: Oliver Pfaff <[e-mail]>
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 17 Jan 2000 13:18:20 -0500
Subject: Re: CRMF support
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

     IBM's Trust Authority also supports CMP, including CRMF.  Its home
page is http://www.ibm.com/software/security/trust/.

          Tom Gindin

Oliver Pfaff <[e-mail]> on 01/15/2000 09:13:12 AM

To:   [e-mail]
cc:
Subject:  CRMF support



I'm trying to get an overview on vendors/systems that support CRMF as
certificate request format. According to a quick Internet search,
Netscape (CMS - Certificate Management System) and Baltimore (UniCERT)
are supporting CRMF. Are there other vendors/systems supporting CRMF?
Thanks,
Oliver





Received: from hpheger3.nm.informatik.uni-muenchen.de ([e-mail] [129.187.214.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07242 for <[e-mail]>; Mon, 17 Jan 2000 06:22:16 -0800 (PST)
Received: (from vogt@localhost) by hpheger3.nm.informatik.uni-muenchen.de (8.9.3 (PHNE_18979)/8.8.6) id PAA03391 for [e-mail]; Mon, 17 Jan 2000 15:23:10 +0100 (MET)
Date: Mon, 17 Jan 2000 15:23:10 +0100 (MET)
Message-Id: <[e-mail]>
From: USM 2000 Organisation Committee <[e-mail]>
To: USM 2000 <[e-mail]>
Subject: USM 2000 - Last Call for Papers

(Please apologize, if you receive multiple copies of this CfP)

                     USM 2000: LAST CALL FOR PAPERS

                 3rd IFIP/GI International Conference on
                Trends towards a Universal Service Market

                            Munich, Germany
                         September 12-14, 2000 


General Information

USM 2000 is the third event in a series of international IFIP conferences
on Trends in Distributed Systems. It continues TreDS'96, held in Aachen,
Germany and TrEC'98 with special focus on Electronic Commerce in Hamburg,
Germany.

The technological progress in internet and telecommunication domains as
well as deregulation efforts of the telecommunication markets currently
under way in many countries enable an integration of data and
telecommunication. Distributed platforms get adapted to the needs of
telecommunication networks. This leads to a global distributed system with
millions of objects, running on top of a middleware kernel and interacting
with each other to provide services. USM 2000 brings together researchers,
service vendors and users in the field of universal service markets. USM
2000 takes place in Munich, Germany, the city of the famous Oktoberfest
which will start two days after the conference on September 16, 2000.


Topics

The USM 2000 considers services of a universal market in relation to
middleware, distributed applications and management. Areas of special
interest include:

* Component Based Systems, Service Creation
* Service Market Models, Accounting and Customer Care
* Quality of Service for Distributed Applications
* Trading, Brokering and Information Management
* Management of Virtual Networks
* Service and Application Management
* Ubiquitous Services and Nomadic Computing
* Distributed and Mobile Objects
* Agent Technology for Integrated Management 
* Advances in Middleware, e.g. CORBA, DCOM, Jini
* Telecommunication Architectures related to Distributed Systems
 

Submissions

You are encouraged to submit full technical papers describing original,
unpublished research or experience of about 12 pages. Extended abstracts
of 3-5 pages will be accepted for poster session papers. For submission 
guidelines please visit our web server. The proceedings will be published
in "Lecture Notes in Computer Science", Springer-Verlag.

Submissions due:         January 30th, 2000
Notice of Acceptance:    April 15th, 2000
Camera-ready Paper due:  June 1st, 2000


Further Information

Contact Person: Helmut Reiser - Phone (Fax): [phone] (~2147)

e-mail: [e-mail],
WWW:    http://usm2000.informatik.uni-muenchen.de/

Address: Ludwig Maximilians University
	 Institute for Computer Science
	 Oettingenstr. 67
	 D-80538 Munich
	 GERMANY


Conference Chairs

Claudia Linnhoff-Popien and Heinz-Gerd Hegering, LMU Munich


Program Committee

Sebastian Abeck, Uni Karlsruhe, Germany
Andrew T. Campbell, Center for Telecommunications Research, Columbia Uni New York, USA
John Dilley, Hewlett Packard, Palo Alto, USA
Kurt Geihs, Uni Frankfurt, Germany
Bernd Heinrichs, Cisco Systems Europe, Düsseldorf, Germany
Yigal Hoffner, IBM Zurich Research Laboratory, Switzerland
Axel Küpper, RWTH Aachen, Germany
Lea Kutvonen, Uni Helsinki, Finland
Winfried Lamersdorf, Uni Hamburg, Germany
Luigi Logrippo, Uni Ottawa, Canada
Michael Merz, Ponton, Hamburg, Germany
Zoran Milosevic, DSTC Brisbane, Australia
Elie Najm, Ecole Nationale Superieure des Telecommunications, Paris, France
Bernhard Neumair, DeTeSystem, Germany
Jerome Rolia, Uni Ottawa, Canada
Alexander Schill, TU Dresden, Germany
Doug Schmidt, ARL St. Louis, USA
Gerd Schürmann, GMD FOKUS, Germany
Morris Sloman, Imperial College, London, UK
Otto Spaniol, RWTH Aachen, Germany
Michael Stal, Siemens ZT, München, Germany
Ralf Steinmetz, TU Darmstadt, Germany
Volker Tschammer, GMD FOKUS, Berlin, Germany


Conference Organisation

Helmut Reiser (Chair), Christian Ensel, Markus Garschhammer, Rainer Hauck,
Bernhard Kempter, Annette Kostelezky, Igor Radisic, Holger Schmidt, Gerald
Vogt, LMU Munich


Sponsors

Ludwig-Maximilians-University (LMU)
International Federation for Information Processing (IFIP)
German Informatics Society (GI)
Computing Centre of the Bavarian Academy of Sciences (LRZ)
BMW AG
DG Bank
Bavaria's Software Initiative
Munich Network Management Team (MNM)
and others



Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01689 for <[e-mail]>; Sat, 15 Jan 2000 09:55:13 -0800 (PST)
Received: from cyclonecommerce.com ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Sat, 15 Jan 2000 09:56:04 -0800
Message-ID: <[e-mail]>
Date: Sat, 15 Jan 2000 10:59:08 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Oliver Pfaff <[e-mail]>
CC: [e-mail]
Subject: Re: CRMF support
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Cyclone Commerce (www.cyclonecommerce.com) supports CRMF in our Crossworks
Security Framework.

Timothy Fisher
[e-mail]
www.cyclonecommerce.com

Oliver Pfaff wrote:

> I'm trying to get an overview on vendors/systems that support CRMF as
> certificate request format. According to a quick Internet search,
> Netscape (CMS - Certificate Management System) and Baltimore (UniCERT)
> are supporting CRMF. Are there other vendors/systems supporting CRMF?
> Thanks,
> Oliver



Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29090 for <[e-mail]>; Sat, 15 Jan 2000 06:12:36 -0800 (PST)
X-Envelope-Sender-Is: [e-mail] (at relayer goliath.siemens.de)
Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.9.3/8.9.3) with ESMTP id PAA12776 for <[e-mail]>; Sat, 15 Jan 2000 15:13:25 +0100 (MET)
Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail2.siemens.de (8.9.3/8.9.3) with ESMTP id PAA14484 for <[e-mail]>; Sat, 15 Jan 2000 15:13:25 +0100 (MET)
Received: from mchp.siemens.de (m68939pp.mchp.siemens.de [139.23.202.121]) by mail-k.mchp.siemens.de (8.9.3/8.9.3) with ESMTP id PAA05778 for <[e-mail]>; Sat, 15 Jan 2000 15:13:23 +0100 (MET)
Message-ID: <[e-mail]>
Date: Sat, 15 Jan 2000 15:13:12 +0100
From: Oliver Pfaff <[e-mail]>
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: CRMF support
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm trying to get an overview on vendors/systems that support CRMF as
certificate request format. According to a quick Internet search,
Netscape (CMS - Certificate Management System) and Baltimore (UniCERT)
are supporting CRMF. Are there other vendors/systems supporting CRMF?
Thanks,
Oliver


Received: from cybergateway.net ([206.104.28.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29253; Fri, 14 Jan 2000 06:21:32 -0800 (PST)
From: [e-mail]
Received: from 206.104.28.14 [152.172.118.203] by cybergateway.net (SMTPD32-5.01) id A4879CD01FE; Fri, 14 Jan 2000 08:55:35 +0100
Received: from  [e-mail] by  [e-mail] (8.8.5/8.6.5) with SMTP id GAA07984 for < [e-mail]>; Fri, 14 Jan 2000 07:38:29 -0600 (EST)
Date: Fri, 14 Jan 00 07:38:29 EST
To: [e-mail]
Subject: New USA and International Merchant Accounts
Message-ID: <>
Reply-To: [e-mail]
Comments: Authenticated sender is < [e-mail]>

NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW NEW
U.S.A. and INTERNATIONAL MERCHANT ACCOUNTS FOR THE WORLD.

Click below to Apply

http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D

ARE YOU REALLY AN E-COMMERCE MERCHANT?
Increase your revenues by up to 1500% by accepting credit cards and
electronic
checks.
Increase your customer base 200- 400% with instant access to the World.

ARE YOU PAYING TOO MUCH?
Discount rates start at 2.1%
Transaction fees start at 25 cents.

DO YOU WAIT TOO LONG FOR YOUR MONEY?
Funds available in 24-48 hours anywhere in the world

DO YOU HAVE DIFFICULTY GETTING MERCHANT ACCOUNTS
99% of all applications are approved.

ARE YOU LIMITED BY WHAT YOU CAN ACCEPT?
Mastercard, Visa, Discover, Amex and Checks (USA checks only)
All cards from ALL COUNTRIES - Including Eastern Europe and Asia

- - - - - - - - - -
-
Click HERE to APPLY.

http://hypermart.com@3462929566/%63ar%64%73%65%72%76%69%63%65/%64%65%66%61u%6C%74%2Eh%74%6D#@3626198025/%63%61%72d%73%65%72%76%69%63%65/d%65fa%75%6C%74%2E%68%74%6D#@3462929566/ca%72d%73%65%72%76%69%63%65%32/%69%6E%64%65%78%2E%68%74%6D@3491382728/%63a%72d%73e%72%76%69%63%65/%64e%66%61%75%6C%74%2E%68t%6D
-

NOTE: THIS IS NOT AN APPLICATION FOR A PERSONAL CREDIT CARD BUT FOR A
MERCHANT
ACCOUNT.

- - - - - - - - - -




-
 To be removed from our mailing list, call [phone] Clearly spell your email address
and you will be removed.








111
 1
111

T


Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22014 for <[e-mail]>; Thu, 13 Jan 2000 06:02:18 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11291 for <[e-mail]>; Thu, 13 Jan 2000 06:02:57 -0800 (PST)
Received: from saguaro.East.Sun.COM (saguaro.East.Sun.COM [129.148.75.130]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA03869 for <[e-mail]>; Thu, 13 Jan 2000 09:02:54 -0500 (EST)
Received: (from aha@localhost) by saguaro.East.Sun.COM (8.9.1b+Sun/8.9.1) id JAA21180; Thu, 13 Jan 2000 09:02:53 -0500 (EST)
From: Anne Anderson <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 13 Jan 2000 09:02:53 -0500 (EST)
To: [e-mail]
Subject: Need certificate with CRLDistributionPoints extension
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid

Does anyone have a certificate containing a CRLDistributionPoints
extension that I could test against?  I'm having trouble separating
what needs to be explicit encoding and what needs to be implicit
encoding in the distributionPoint option.

Anne
-- 
Anne H. Anderson             Email: [e-mail]
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: [phone]
Burlington, MA 01803-0902 USA  Fax: [phone]


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA17464 for <[e-mail]>; Mon, 10 Jan 2000 22:10:56 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJL4TLB>; Mon, 10 Jan 2000 22:04:55 -0800
Message-ID: <[e-mail]>
From: Ambarish Malpani <[e-mail]>
To: "'Timothy Fisher'" <[e-mail]>, John Herendeen <[e-mail]>
Cc: "Sweigert, David" <[e-mail]>, Petra Wuensche <[e-mail]>, [e-mail], Khaja Ahmed <[e-mail]>, Venky Nakhate <[e-mail]>
Subject: RE: OCSP
Date: Mon, 10 Jan 2000 22:04:47 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

Hi Tim,
    Yes, we do make our ocsp server available for testing.

You can get instructions on how to reach it by going to:
http://www.valicert.com/ocsp

Unfortunately, the CA Delegated Trust mode of OCSP won't quite
work, because the delegated cert has expired.... :-(

Will try to fix that some time.
Please let me know how it goes.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833


> -----Original Message-----
> From: Timothy Fisher [mailto:[e-mail]]
> Sent: Monday, January 10, 2000 9:32 AM
> To: John Herendeen
> Cc: Sweigert, David; Petra Wuensche; [e-mail]
> Subject: Re: OCSP
> 
> 
> Do they make it available for testing?
> 
> Tim
> 
> John Herendeen wrote:
> 
> > Try
> >
> > www.valicert.com
> >
> > their ValiCert Enterprise VA is an OCSP server
> >
> > John Herendeen
> >
> > -----Original Message-----
> > From: Timothy Fisher [mailto:[e-mail]]
> > Sent: Monday, January 10, 2000 11:56 AM
> > To: Sweigert, David
> > Cc: Petra Wuensche; [e-mail]
> > Subject: Re: OCSP
> >
> > Do either of those vendors have an OCSP server available for testing
> > with though?
> >
> > Tim
> >
> > "Sweigert, David" wrote:
> >
> > > Verisign actively supports OCSP, as well as E-LOCK Technologies.
> > >
> > > -----Original Message-----
> > > From: Petra Wuensche [mailto:[e-mail]]
> > > Sent: Saturday, January 08, 2000 12:33 PM
> > > To: [e-mail]
> > > Subject: OCSP
> > >
> > > Hello!
> > >
> > > I'm a student in Graz (Austria), university of  technology. I'm
> > > working at a project where I have to implement OCSP.
> > > I'd now need a possibility to test my work. So could you tell me a
> > > server, which uses OCSP?
> > >
> > > Thanks in advance,
> > >
> > > Petra Wuensche
> 


Received: from seine.valicert.com (corporate-gw.valicert.com [63.65.221.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15161 for <[e-mail]>; Mon, 10 Jan 2000 15:24:21 -0800 (PST)
Received: by seine.valicert.com with Internet Mail Service (5.5.2650.21) id <CPJL4TBQ>; Mon, 10 Jan 2000 15:18:21 -0800
Message-ID: <[e-mail]>
From: Khaja Ahmed <[e-mail]>
To: Petra Wuensche <[e-mail]>, [e-mail]
Subject: RE: OCSP
Date: Mon, 10 Jan 2000 15:18:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF5BC0.FBB1657E"

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_01BF5BC0.FBB1657E
Content-Type: text/plain;
	charset="iso-8859-1"

Petra,

ValiCert runs an OCSP responder that may be used by third parties to test
their OCSP implementation.  This is intended as a reference site.  The OCSP
responder is ocsptest1.valicert.com.  You may find more details about this
on www.valicert.com. 

Khaja
__________________________________________________________________

Khaja E. Ahmed, Director of Engineering; Core Product Development
ValiCert Inc., 1215 Terra Bella Ave, Mountain View, CA 94043
Phone/Fax :      [phone] (Work) ; 650.254.2148 (Fax)
Email/Web : 	[e-mail] ; http://www.valicert.com/
Directions  : 	NW Corner of Shoreline & Terra Bella, West of 101
___________________________________________________________________


-----Original Message-----
From: Petra Wuensche [mailto:[e-mail]]
Sent: Saturday, January 08, 2000 9:33 AM
To: [e-mail]
Subject: OCSP


Hello!

I'm a student in Graz (Austria), university of  technology. I'm
working at a project where I have to implement OCSP.
I'd now need a possibility to test my work. So could you tell me a
server, which uses OCSP?

Thanks in advance,

Petra Wuensche



------_=_NextPart_000_01BF5BC0.FBB1657E
Content-Type: application/octet-stream;
	name="KhajaEAhmed.vcf"
Content-Disposition: attachment;
	filename="KhajaEAhmed.vcf"

BEGIN:VCARD
VERSION:2.1
N:Ahmed;Khaja;E.;;
FN:Khaja E. Ahmed
ORG:ValiCert, Inc.;Engineering
TITLE:Director Of Engineering; Core Products
TEL;WORK;VOICE:[phone]
TEL;HOME;VOICE:[phone]
TEL;CELL;VOICE:[phone]
TEL;WORK;FAX:[phone]
ADR;WORK:;Mounatain View;1215 Terra Bella Av.;Mountain View;CA;94043-1833;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Mounatain View=0D=0A1215 Terra Bella Av.=0D=0AMountain View, CA 94043-1833=
=0D=0AUnited States of America
URL:
URL:http://www.valicert.com/
ROLE:Engineering
EMAIL;PREF;INTERNET:[e-mail]
REV:19991118T230251Z
END:VCARD

------_=_NextPart_000_01BF5BC0.FBB1657E--


Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13862 for <[e-mail]>; Mon, 10 Jan 2000 13:31:13 -0800 (PST)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id NAA17334 for <[e-mail]>; Mon, 10 Jan 2000 13:31:09 -0800 (PST)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA00718 for <[e-mail]>; Mon, 10 Jan 2000 13:31:09 -0800
X-Virus-Scanned:  Mon, 10 Jan 2000 13:31:09 -0800 Nokia Silicon Valley AntiVirus Appliance
Received: from <[e-mail]> (dhcp-15-43.iprg.nokia.com [205.226.15.43]) by darkstar.iprg.nokia.com  SMTP/WTS (12.69) xma000471; Mon, 10 Jan 00 13:31:03 -0800
Message-ID: <[e-mail]>
Date: Mon, 10 Jan 2000 13:30:30 -0800
From: Tom Tang <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: subscribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

subscribe



Received: from surf2.ameritraininc.com (host29.cynet.net [207.224.29.29] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13564 for <[e-mail]>; Mon, 10 Jan 2000 13:17:11 -0800 (PST)
Received: from WIN2KTEST (netwalkr2.erols.com [216.164.109.18]) by surf2.ameritraininc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CN9BQAT3; Mon, 10 Jan 2000 16:25:27 -0500
From: "Chris" <[e-mail]>
To: <[e-mail]>
Subject: 
Date: Mon, 10 Jan 2000 16:20:35 -0500
Message-ID: <000501bf5bb0$890dadd0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BF5B86.A037A5D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600

This is a multi-part message in MIME format.

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

 
 
Subscribe

------=_NextPart_000_0006_01BF5B86.A037A5D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01BF5B86.9F70FA70">
<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Template>Normal</o:Template>
  <o:Revision>1</o:Revision>
  <o:TotalTime>1</o:TotalTime>
  <o:Created>2000-01-10T21:19:00Z</o:Created>
  <o:Pages>1</o:Pages>
  <o:Company>Me</o:Company>
  <o:Lines>1</o:Lines>
  <o:Paragraphs>1</o:Paragraphs>
  <o:Version>9.2720</o:Version>
 </o:DocumentProperties>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:black;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>Subscribe</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_0006_01BF5B86.A037A5D0--



Received: from saqr.astrid.net ([209.19.106.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13053 for <[e-mail]>; Mon, 10 Jan 2000 12:41:34 -0800 (PST)
Received: from xetex.com (adsl-63-194-208-146.dsl.snfc21.pacbell.net [63.194.208.146]) by saqr.astrid.net (8.9.3/8.9.3) with ESMTP id MAA06242; Mon, 10 Jan 2000 12:46:35 -0800 (PST)
Message-ID: <[e-mail]>
Date: Mon, 10 Jan 2000 12:40:59 -0800
From: Ed Posnak <[e-mail]>
Organization: Xetex Corporation
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Timothy Fisher <[e-mail]>
CC: John Herendeen <[e-mail]>, "Sweigert, David" <[e-mail]>, Petra Wuensche <[e-mail]>, [e-mail], "Hicks, G Mack" <[e-mail]>
Subject: Re: OCSP
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Timothy Fisher wrote:

> Do they make it available for testing?

There is an OCSP responder available for test at
http://ocsp.xetex.com/servlet/ocsp.  In order to get interesting
responses, you will want to get our  issuer name & key hash, or CA and
end-entity certs.  If anyone is interested, please contact me and I will
provide these.

ejp






Received: from atdev1.alphatrust.com ([209.39.43.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12774 for <[e-mail]>; Mon, 10 Jan 2000 12:31:55 -0800 (PST)
Received: by ATDEV1 with Internet Mail Service (5.5.2448.0) id <ZD5AV7SH>; Mon, 10 Jan 2000 14:36:29 -0600
Message-ID: <9E60D6A452AAD211904E00105A1973FD072ADE@ATDEV1>
From: "Bill Brice (listserv)" <[e-mail]>
To: "'Timothy Fisher'" <[e-mail]>, John Herendeen <[e-mail]>
Cc: "Sweigert, David" <[e-mail]>, Petra Wuensche <[e-mail]>, [e-mail]
Subject: RE: OCSP
Date: Mon, 10 Jan 2000 14:36:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"

John & Petra,

You are welcome to validate against our OCSP server at:
http://validate.alphatrust.com

If you would like a copy of a revoked cert to test, please
let me know off list. Thanks.

Bill Brice
http://alphatrust.com

-----Original Message-----
From: Timothy Fisher [mailto:[e-mail]]
Sent: Monday, January 10, 2000 11:32 AM
To: John Herendeen
Cc: Sweigert, David; Petra Wuensche; [e-mail]
Subject: Re: OCSP


Do they make it available for testing?

Tim

John Herendeen wrote:

> Try
>
> www.valicert.com
>
> their ValiCert Enterprise VA is an OCSP server
>
> John Herendeen
>
> -----Original Message-----
> From: Timothy Fisher [mailto:[e-mail]]
> Sent: Monday, January 10, 2000 11:56 AM
> To: Sweigert, David
> Cc: Petra Wuensche; [e-mail]
> Subject: Re: OCSP
>
> Do either of those vendors have an OCSP server available for testing
> with though?
>
> Tim
>
> "Sweigert, David" wrote:
>
> > Verisign actively supports OCSP, as well as E-LOCK Technologies.
> >
> > -----Original Message-----
> > From: Petra Wuensche [mailto:[e-mail]]
> > Sent: Saturday, January 08, 2000 12:33 PM
> > To: [e-mail]
> > Subject: OCSP
> >
> > Hello!
> >
> > I'm a student in Graz (Austria), university of  technology. I'm
> > working at a project where I have to implement OCSP.
> > I'd now need a possibility to test my work. So could you tell me a
> > server, which uses OCSP?
> >
> > Thanks in advance,
> >
> > Petra Wuensche


Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10668 for <[e-mail]>; Mon, 10 Jan 2000 09:28:30 -0800 (PST)
Received: from cyclonecommerce.com ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Mon, 10 Jan 2000 09:28:56 -0800
Message-ID: <[e-mail]>
Date: Mon, 10 Jan 2000 10:32:04 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: John Herendeen <[e-mail]>
CC: "Sweigert, David" <[e-mail]>, Petra Wuensche <[e-mail]>, [e-mail]
Subject: Re: OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Do they make it available for testing?

Tim

John Herendeen wrote:

> Try
>
> www.valicert.com
>
> their ValiCert Enterprise VA is an OCSP server
>
> John Herendeen
>
> -----Original Message-----
> From: Timothy Fisher [mailto:[e-mail]]
> Sent: Monday, January 10, 2000 11:56 AM
> To: Sweigert, David
> Cc: Petra Wuensche; [e-mail]
> Subject: Re: OCSP
>
> Do either of those vendors have an OCSP server available for testing
> with though?
>
> Tim
>
> "Sweigert, David" wrote:
>
> > Verisign actively supports OCSP, as well as E-LOCK Technologies.
> >
> > -----Original Message-----
> > From: Petra Wuensche [mailto:[e-mail]]
> > Sent: Saturday, January 08, 2000 12:33 PM
> > To: [e-mail]
> > Subject: OCSP
> >
> > Hello!
> >
> > I'm a student in Graz (Austria), university of  technology. I'm
> > working at a project where I have to implement OCSP.
> > I'd now need a possibility to test my work. So could you tell me a
> > server, which uses OCSP?
> >
> > Thanks in advance,
> >
> > Petra Wuensche



Received: from indy.gradient.com (indy.gradient.com [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10474 for <[e-mail]>; Mon, 10 Jan 2000 09:24:47 -0800 (PST)
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 MAA28867; Mon, 10 Jan 2000 12:23:58 -0500 (EST)
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2448.0) id <ZLM5ZPWL>; Mon, 10 Jan 2000 12:22:40 -0500
Message-ID: <[e-mail]>
From: John Herendeen <[e-mail]>
To: "'Timothy Fisher'" <[e-mail]>, "Sweigert, David" <[e-mail]>
Cc: Petra Wuensche <[e-mail]>, [e-mail]
Subject: RE: OCSP
Date: Mon, 10 Jan 2000 12:22:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"

Try 

www.valicert.com

their ValiCert Enterprise VA is an OCSP server

John Herendeen



-----Original Message-----
From: Timothy Fisher [mailto:[e-mail]]
Sent: Monday, January 10, 2000 11:56 AM
To: Sweigert, David
Cc: Petra Wuensche; [e-mail]
Subject: Re: OCSP


Do either of those vendors have an OCSP server available for testing
with though?

Tim

"Sweigert, David" wrote:

> Verisign actively supports OCSP, as well as E-LOCK Technologies.
>
> -----Original Message-----
> From: Petra Wuensche [mailto:[e-mail]]
> Sent: Saturday, January 08, 2000 12:33 PM
> To: [e-mail]
> Subject: OCSP
>
> Hello!
>
> I'm a student in Graz (Austria), university of  technology. I'm
> working at a project where I have to implement OCSP.
> I'd now need a possibility to test my work. So could you tell me a
> server, which uses OCSP?
>
> Thanks in advance,
>
> Petra Wuensche


Received: from mail.rdc1.az.home.com ([e-mail] [24.1.240.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09988 for <[e-mail]>; Mon, 10 Jan 2000 08:52:41 -0800 (PST)
Received: from cyclonecommerce.com ([24.1.214.107]) by mail.rdc1.az.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <[e-mail]>; Mon, 10 Jan 2000 08:53:06 -0800
Message-ID: <[e-mail]>
Date: Mon, 10 Jan 2000 09:56:14 -0700
From: Timothy Fisher <[e-mail]>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Sweigert, David" <[e-mail]>
CC: Petra Wuensche <[e-mail]>, [e-mail]
Subject: Re: OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Do either of those vendors have an OCSP server available for testing
with though?

Tim

"Sweigert, David" wrote:

> Verisign actively supports OCSP, as well as E-LOCK Technologies.
>
> -----Original Message-----
> From: Petra Wuensche [mailto:[e-mail]]
> Sent: Saturday, January 08, 2000 12:33 PM
> To: [e-mail]
> Subject: OCSP
>
> Hello!
>
> I'm a student in Graz (Austria), university of  technology. I'm
> working at a project where I have to implement OCSP.
> I'd now need a possibility to test my work. So could you tell me a
> server, which uses OCSP?
>
> Thanks in advance,
>
> Petra Wuensche



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07514 for <[e-mail]>; Mon, 10 Jan 2000 06:22:01 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA13813; Mon, 10 Jan 2000 15:22:18 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 10 Jan 2000 15:22:17 +0100 (MET)
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 PAA19758; Mon, 10 Jan 2000 15:22:17 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA05387; Mon, 10 Jan 2000 15:22:16 +0100 (MET)
Date: Mon, 10 Jan 2000 15:22:16 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: TSP-05
Cc: [e-mail]

> > 
> 
> I can't find a definition for id-kp-timeStamping .
> 
Oops, sorry for the previous mail. Please ignore it, the
value is defined in rfc2459 


Received: from Newman.GSC.GTE.Com ([e-mail] [192.160.62.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06481 for <[e-mail]>; Mon, 10 Jan 2000 05:25:41 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 2405"@gscex01.ndhm.gsc.gte.com [155.95.162.170]) by Newman.GSC.GTE.Com (PMDF V5.2-30 #38015) with ESMTP id <[e-mail]> for [e-mail]; Mon, 10 Jan 2000 08:26:03 EST
Received: by GSCEX01.gsc.gte.com with Internet Mail Service (5.5.2448.0) id <CN994B40>; Mon, 10 Jan 2000 08:26:04 -0500
Content-return: allowed
Date: Mon, 10 Jan 2000 08:26:00 -0500
From: "Sweigert, David" <[e-mail]>
Subject: RE: OCSP
To: Petra Wuensche <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-type: text/plain;	charset="iso-8859-1"

Verisign actively supports OCSP, as well as E-LOCK Technologies.



-----Original Message-----
From: Petra Wuensche [mailto:[e-mail]]
Sent: Saturday, January 08, 2000 12:33 PM
To: [e-mail]
Subject: OCSP


Hello!

I'm a student in Graz (Austria), university of  technology. I'm
working at a project where I have to implement OCSP.
I'd now need a possibility to test my work. So could you tell me a
server, which uses OCSP?

Thanks in advance,

Petra Wuensche




Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05634 for <[e-mail]>; Mon, 10 Jan 2000 04:28:31 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA11706; Mon, 10 Jan 2000 13:28:53 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 10 Jan 2000 13:28:52 +0100 (MET)
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 NAA19378; Mon, 10 Jan 2000 13:28:51 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA05352; Mon, 10 Jan 2000 13:28:51 +0100 (MET)
Date: Mon, 10 Jan 2000 13:28:51 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: TSP-05
Cc: [e-mail]

> Note: At this time one OID value (for the ASN1 module) is still
> missing but will likely be obtained before the end of the last call.
> 

I can't find a definition for id-kp-timeStamping .

  The TSA MUST sign all time stamp messages with one or more keys 
  reserved specifically for that purpose.  The corresponding certificate 
  MUST contain only one instance of the extended key usage field 
  extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID 
  having value id-kp-timeStamping. This extension MUST be critical.

 


Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA11126 for <[e-mail]>; Sun, 9 Jan 2000 04:05:08 -0800 (PST)
Received: from secude.com ([141.12.156.32]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id NAA18168 for <[e-mail]>; Sun, 9 Jan 2000 13:04:56 +0100 (MET)
Message-ID: <[e-mail]>
Date: Sat, 08 Jan 2000 17:38:52 +0100
From: Harald Giehl <[e-mail]>
Organization: SECUDE GmbH
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: unsubscribe
Content-Type: multipart/mixed; boundary="------------A3BEC50B90E854C960C82118"

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

unsubscribe

--------------A3BEC50B90E854C960C82118
Content-Type: text/x-vcard; charset=us-ascii;
 name="giehl.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Harald Giehl
Content-Disposition: attachment;
 filename="giehl.vcf"

begin:vcard 
n:Giehl;Harald
tel;fax:+49 61 51 - 88 00 6 26
tel;work:+49 61 51 - 88 00 60
x-mozilla-html:FALSE
url:http://www.secude.com
org:SECUDE Sicherheitstechnologie Informationssysteme GmbH
adr:;;Landwehrstraße 50a;Darmstadt;;64293;Germany
version:2.1
email;internet:[e-mail]
x-mozilla-cpt:;-1
fn:Harald Giehl
end:vcard

--------------A3BEC50B90E854C960C82118--




Received: from ns1.tu-graz.ac.at (ns1.tu-graz.ac.at [129.27.2.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12092 for <[e-mail]>; Sat, 8 Jan 2000 08:31:01 -0800 (PST)
Received: from oben (isdn091.tu-graz.ac.at [129.27.240.91]) by ns1.tu-graz.ac.at (8.9.3/8.9.3) with SMTP id RAA09058 for <[e-mail]>; Sat, 8 Jan 2000 17:31:13 +0100 (MET)
Message-ID: <007001bf59fe$63ccbab0$0100a8c0@oben>
From: "Petra Wuensche" <[e-mail]>
To: <[e-mail]>
Subject: OCSP
Date: Sat, 8 Jan 2000 17:32:37 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

Hello!

I'm a student in Graz (Austria), university of  technology. I'm
working at a project where I have to implement OCSP.
I'd now need a possibility to test my work. So could you tell me a
server, which uses OCSP?

Thanks in advance,

Petra Wuensche





Received: from energy.ogu.edu.tr ([e-mail] [193.140.141.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA09477 for <[e-mail]>; Sat, 8 Jan 2000 03:48:43 -0800 (PST)
From: [e-mail]
Received: from energy.ogu.edu.tr (98C9FD37.ipt.aol.com [152.201.253.55]) by energy.ogu.edu.tr (8.8.8/8.8.4) with SMTP id NAA03408; Sat, 8 Jan 2000 13:42:58 +0200
Date: Sat, 08 Jan 00 01:43:26 EST
To: [e-mail]
Subject: A Search Engine Just For You !
Message-ID: <>

This e-mail is to inform you of a new search engine for adult web sites:
http://www.adultfairlinks.com.

Fairlinks is being built at this time and will be launched in a few months.
We are contacting webmasters now so you can take a look at the site and give
us any input you may have.  This site will be unique since it will be a TRUE
SEARCH ENGINE FOR ADULT SITES.  There will be no banner ads, no support from
any adult site.  All categories will rotate so that each site will be at the
top.  Two thirds of all money collected will then be used to promote
Fairlinks.  Most advertising will be done off the web with plans already
made to market the site on the Internet.  We are going to pool thousands of
adult sites together to form a partnership that will make a formidable force
and to have funds for national advertising.

Please take a look, join in and get your site promoted as it should be!
http://www.adultfairlinks.com








 To be removed, call [phone] and  Clearly spell your email address
and you will be removed.




Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14452 for <[e-mail]>; Fri, 7 Jan 2000 15:45:40 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA14003 for <[e-mail]>; Sat, 8 Jan 2000 12:45:49 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <94728874918687>; Sat, 8 Jan 2000 12:45:49 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: TSP-05
Sender: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 8 Jan 2000 12:45:49 (NZDT)
Message-ID: <[e-mail]>

Peter Sylvester <[e-mail]> writes:
 
>The main change is that 
>
>  DEFINITIONS EXPLICIT TAGS ::=
>
>With that the EXPLICIT in 
>
>     extensions   [3] EXPLICIT Extensions    OPTIONAL
>
>seems to be redundant to me? 
 
Given that it's usual to use global implicit tags, isn't it kind of risky to 
use a setting which is the opposite to what everyone is expecting?  If you 
drop the global EXPLICIT it'll be the same as the normal default, and the 
redundancy will go away.
 
Peter.



Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07830 for <[e-mail]>; Fri, 7 Jan 2000 06:47:30 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA16653; Fri, 7 Jan 2000 15:47:39 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 7 Jan 2000 15:47:39 +0100 (MET)
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 PAA08934; Fri, 7 Jan 2000 15:47:38 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA03927; Fri, 7 Jan 2000 15:47:37 +0100 (MET)
Date: Fri, 7 Jan 2000 15:47:37 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP-05

Can you explain what you mean by: 

    Conforming timestamping requesters MUST be able to recognize 
    version 1 Timestamp tokens with all the optional fields present, 
    but are not mandated to understand the semantics of any extension, 
    if present.

especially for critical extensions. 

Do you think about an actual requestor be a program that even regards
the result? Ffor example a mail relay that adds a time stamp as a
countersignature to an smime message while relaying it.
 
In this case the requestor may be configured to not even look at the
content and just verify the signature of the trustworthy tsa (and maybe
the document type returned)




Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05730 for <[e-mail]>; Fri, 7 Jan 2000 06:27:43 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <C3TZZDCB>; Fri, 7 Jan 2000 09:27:23 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Vagueness in empty CRLs
Date: Fri, 7 Jan 2000 09:27:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

David I agree with everything you said, and I'm certainly not going 
to bet against your wager and lose my $0.50 :-)  

I'm wondering if it would be useful to try to get a phrase added 
to 509 that "strongly recommends" that an empty SEQUENCE never be 
used. That might be helpful for guiding future implementations 
while still not breaking backward compatibility if David does 
lose his $0.50 wager. Do you think this 
is a "not worth the trouble" suggestion or something that would be 
good to try? I don't know how the 509 group would feel about it, since
we're now at the DAM stage, but I could see a phrase of this sort 
being proposed as a clarification. 

Sharon 

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Thursday, January 06, 2000 10:11 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: Vagueness in empty CRLs
> 
> 
> 
> > From: "Phillip M Hallam-Baker" <[e-mail]
> >
> > > [From Sharon Boeyen]
> > > However, the proposal to be to make that same restriction 
> in X.509 itself
> > > does concern me a bit, primarily from the standpoint of backward
> > compatibility
> > > but also because we don't have a thorough way to ensure 
> that making the
> > change
> > > wouldn't break some existing systems and environments 
> outside PKIX.
> > 
> > Given the choice between ASN.1 DER purity and backwards 
> compatibility, give
> > me compatibility every time.
> > 
> > I have never accepted that the DER rules met a real need 
> and hearing the
> > argument again a fiftieth time is unlikely to convince me. 
> 
> 
> I must have missed something, Phill -- who said anything 
> about BER vs. DER?
> 
> The issue is the encoding of a CRL which has no entries; the choices
> are 1) an empty SEQUENCE and 2) an absent SEQUENCE .  Both options are
> legal in both BER and DER - there is nothing in X.690 section 10 or 11
> which requires that empty optional sequences be elided.  This 
> is appropriate
> because in some cases there is a semantic difference between empty and
> absent.
> 
> In the case of CRLs however, there is no semantic difference, just two
> different ways of saying "here's a CRL with no entries".  You 
> may believe
> that canonical encodings have no benefit; I believe they do.
>  
> With regards to backwards compatibility, existing decoding software is
> not an issue; the only issue is whether "new" decoders would be broken
> by old encoders or old CRLs.  Paul H. asked that question in the PKIX
> context; if a change were made to X.509 the question would have to be
> asked in a much larger context and answered to the 
> satisfaction of every
> voting body.  I agree with Sharon that there is no way to be 
> 100% sure,
> but I would wager $0.50 that as of yesterday there was no CRL on earth
> (excluding deliberately-created test vectors) which has "no entries"
> represented as a zero-length SEQUENCE.
> 
> And I agree with Sharon's position that it is appropriate for the PKIX
> profile to restrict X.509, as it already does by adding a SIZE
> constraint to Extensions.
> 
> I disagree with Sharon's comment:
> 
> > If we do go ahead with a proposed change to 509, I'd prefer 
> it to be a
> > text clarification rather than a restructuring of the ASN.1, again
> > because of backward compatibility.
> 
> There is no clarification possible; either both representations are
> allowed or only one is allowed.  It doesn't matter whether 
> the protocol
> is specified in prose, in ASN.1 comments, or in ASN.1 syntax, 
> the protocol
> is as it is.  If the ASN.1 is not changed, redundant text could be
> added to say that both cases are legal, but I don't believe 
> there would
> be any value in adding such text.  I do believe that adding text to
> allow only the absent sequence while leaving the ASN.1 unchanged would
> *not* be a clarification, it would be an obfuscation.  The text (if
> present) and the syntax should agree, regardless of which outcomes are
> chosen for X.509 and for the PKIX profile.
> 
> I recommend that PKIX add a SIZE constraint to 
> revokedCertificates, but
> take no position with respect to X.509.
> 


Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05663 for <[e-mail]>; Fri, 7 Jan 2000 06:27:13 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA16080; Fri, 7 Jan 2000 15:27:17 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Fri, 7 Jan 2000 15:27:16 +0100 (MET)
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 PAA08767; Fri, 7 Jan 2000 15:27:16 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA03913; Fri, 7 Jan 2000 15:27:15 +0100 (MET)
Date: Fri, 7 Jan 2000 15:27:15 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP-05

Happy new year to all,

The main change is that 

  DEFINITIONS EXPLICIT TAGS ::=

With that the EXPLICIT in 

     extensions   [3] EXPLICIT Extensions    OPTIONAL

seems to be redundant to me? 

Anyway, what is the purpose of that particular EXPLICIT
and the global one? 

Is it a requirement to be able to decode a time stamp
without knowing the syntax?  




Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24273 for <[e-mail]>; Fri, 7 Jan 2000 04:25:33 -0800 (PST)
Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id NAA34066 for <[e-mail]>; Fri, 7 Jan 2000 13:25:57 +0100
Message-ID: <[e-mail]>
Date: Fri, 07 Jan 2000 13:25:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull
X-Mailer: Mozilla 4.06 [fr] (Win95; I)
MIME-Version: 1.0
To: IETF-PXIX <[e-mail]>
Subject: TSP-05
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The latest draft is available at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-05.txt

A few indications about the main changes:

The error codes have been expanded to allow for a better indication
about the reason of an error.

A BOOLEAN has been added in the request so that it now become
possible to ask for the inclusion or the exclusion of the TSA
certificate in the response.

The syntax of Accuracy has been changed so that it now becomes
possible to have a precision of e.g. 1,5 seconds (this was not
possible with the previous syntax !)

An appendix (D) that contains the ASN1 module has been added.

With this changes, I believe that the document is now ready for last
call.

Denis

Note: At this time one OID value (for the ASN1 module) is still
missing but will likely be obtained before the end of the last call.


Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17163 for <[e-mail]>; Fri, 7 Jan 2000 03:39:17 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14115; Fri, 7 Jan 2000 06:39:25 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-05.txt
Date: Fri, 07 Jan 2000 06:39:24 -0500
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 Time Stamp 
                          Protocols (TSP)
	Author(s)	: C. Adams,  P. Cain, D. Pinkas,  R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-05.txt
	Pages		: 20
	Date		: 06-Jan-00
	
A time stamping service allows to prove that a datum existed before
a particular time and can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). This document describes the format of a request sent to a
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was generated
during the validity period of the corresponding public key
certificate is given in an annex.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-time-stamp-05.txt".

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-time-stamp-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10083 for <[e-mail]>; Thu, 6 Jan 2000 07:47:13 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Thu, 06 Jan 2000 07:47:55 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Vagueness in empty CRLs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:11 AM 1/6/00 -0500, David P. Kemp wrote:
>I agree with Sharon that there is no way to be 100% sure,
>but I would wager $0.50 that as of yesterday there was no CRL on earth
>(excluding deliberately-created test vectors) which has "no entries"
>represented as a zero-length SEQUENCE.

You might owe me $0.50, depending on your definition of "yesterday". Oscar, 
a very capable open-source CA product (see <http://oscar.dstc.qut.edu.au/>, 
was generating empty CRLs with the zero-length SEQUENCE in version 3.1.3. 
3.1.4 was issued last night that fixed this. Oscar is produced in 
Australia, so it was "today" there when it was "last night" here...

Again, I think their reading of RFC 2459 was reasonable although not what 
the majority of people would have thought reading it. We have so many cases 
of "put a NULL in" or "must not put a NULL in" that we should be clear 
wherever we can.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09280 for <[e-mail]>; Thu, 6 Jan 2000 07:12:10 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id KAA13229; Thu, 6 Jan 2000 10:12:39 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id KAA13225; Thu, 6 Jan 2000 10:12:39 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id KAA19488; Thu, 6 Jan 2000 10:11:43 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id KAA01484; Thu, 6 Jan 2000 10:11:06 -0500 (EST)
Message-Id: <[e-mail]>
Date: Thu, 6 Jan 2000 10:11:06 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Vagueness in empty CRLs
To: [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: XECOMPCxtTxRR0t/uVjklw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

> From: "Phillip M Hallam-Baker" <[e-mail]
>
> > [From Sharon Boeyen]
> > However, the proposal to be to make that same restriction in X.509 itself
> > does concern me a bit, primarily from the standpoint of backward
> compatibility
> > but also because we don't have a thorough way to ensure that making the
> change
> > wouldn't break some existing systems and environments outside PKIX.
> 
> Given the choice between ASN.1 DER purity and backwards compatibility, give
> me compatibility every time.
> 
> I have never accepted that the DER rules met a real need and hearing the
> argument again a fiftieth time is unlikely to convince me. 


I must have missed something, Phill -- who said anything about BER vs. DER?

The issue is the encoding of a CRL which has no entries; the choices
are 1) an empty SEQUENCE and 2) an absent SEQUENCE .  Both options are
legal in both BER and DER - there is nothing in X.690 section 10 or 11
which requires that empty optional sequences be elided.  This is appropriate
because in some cases there is a semantic difference between empty and
absent.

In the case of CRLs however, there is no semantic difference, just two
different ways of saying "here's a CRL with no entries".  You may believe
that canonical encodings have no benefit; I believe they do.
 
With regards to backwards compatibility, existing decoding software is
not an issue; the only issue is whether "new" decoders would be broken
by old encoders or old CRLs.  Paul H. asked that question in the PKIX
context; if a change were made to X.509 the question would have to be
asked in a much larger context and answered to the satisfaction of every
voting body.  I agree with Sharon that there is no way to be 100% sure,
but I would wager $0.50 that as of yesterday there was no CRL on earth
(excluding deliberately-created test vectors) which has "no entries"
represented as a zero-length SEQUENCE.

And I agree with Sharon's position that it is appropriate for the PKIX
profile to restrict X.509, as it already does by adding a SIZE
constraint to Extensions.

I disagree with Sharon's comment:

> If we do go ahead with a proposed change to 509, I'd prefer it to be a
> text clarification rather than a restructuring of the ASN.1, again
> because of backward compatibility.

There is no clarification possible; either both representations are
allowed or only one is allowed.  It doesn't matter whether the protocol
is specified in prose, in ASN.1 comments, or in ASN.1 syntax, the protocol
is as it is.  If the ASN.1 is not changed, redundant text could be
added to say that both cases are legal, but I don't believe there would
be any value in adding such text.  I do believe that adding text to
allow only the absent sequence while leaving the ASN.1 unchanged would
*not* be a clarification, it would be an obfuscation.  The text (if
present) and the syntax should agree, regardless of which outcomes are
chosen for X.509 and for the PKIX profile.

I recommend that PKIX add a SIZE constraint to revokedCertificates, but
take no position with respect to X.509.



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 RAA09548 for <[e-mail]>; Wed, 5 Jan 2000 17:47:50 -0800 (PST)
Received: from [128.33.238.33] (TC033.BBN.COM [128.33.238.33]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id UAA23925; Wed, 5 Jan 2000 20:47:00 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <v04220800b499a3d074a3@[128.33.238.33]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <004901bf57ce$5ceeda20$[e-mail]> <[e-mail]>
Date: Wed, 5 Jan 2000 20:45:29 -0500
To: Paul Koning <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Vagueness in empty CRLs
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Folks,

We're not debating a generic change re adherence to DER.  We're just 
debating details of CRL encoding conventions.  I agree with Sharon's 
analysis and suggest that we adopt that approach to dealing with this 
ambiguity.

Steve


Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07349 for <[e-mail]>; Wed, 5 Jan 2000 14:55:38 -0800 (PST)
Received: from xedia.com by dfw7sosrv11.alter.net with SMTP  (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQhwsx27762; Wed, 5 Jan 2000 22:54:37 GMT
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA16220; Wed, 5 Jan 00 17:52:09 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id RAA14467; Wed, 5 Jan 2000 17:54:35 -0500
Date: Wed, 5 Jan 2000 17:54:35 -0500
Message-Id: <[e-mail]>
From: Paul Koning <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Vagueness in empty CRLs
References: <[e-mail]> <004901bf57ce$5ceeda20$[e-mail]>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid

>>>>> "Phillip" == Phillip M Hallam-Baker <[e-mail]> writes:

 Phillip> Given the choice between ASN.1 DER purity and backwards
 Phillip> compatibility, give me compatibility every time.

That makes sense.

 Phillip> Regardless, we might well wish to consider that PKIX
 Phillip> implementations should be restrictive in what they create
 Phillip> and persmissive in what they accept.

Definitely.  That's the IETF protocol design rule.

 Phillip> If there is a possible confusion we should perhaps state
 Phillip> that implementations MUST issue the pukah DER form and
 Phillip> SHOULD accept anything that is legal BER.

I'd say that's going too far.  "Permissive" doesn't mean (to me) that
you should accept a large superset of the supposed protocol at great
expense in complexity.  It means things like:

1. Don't do value checking if it serves no purpose other than to
complain about "the wrong value".
2. Assume reserved fields can be any old value, not just zero.
3. *if it is no particular effort to do so* don't assume tagged field
to be in a particular order

But it doesn't mean that you should accept the full gruesome
flexibility of BER.  Relaxing some of the DER rules (e.g., on
ordering) may be a good thing.  But a big argument for the
"permissive" rule is to make things simpler, not to make them more
complex. 

	paul
 


Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07024 for <[e-mail]>; Wed, 5 Jan 2000 14:43:21 -0800 (PST)
Received: from postal-gw1.verisign.com (mailhost1.verisign.com [208.206.241.101]) by caladan.verisign.com (8.9.3/BCH1.7) with ESMTP id OAA11235; Wed, 5 Jan 2000 14:40:23 -0800 (PST)
Received: from pbaker-pc.verisign.com ([192.168.7.110]) by postal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CMBLR362; Wed, 5 Jan 2000 14:42:23 -0800
From: "Phillip M Hallam-Baker" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "'David P. Kemp'" <[e-mail]>, <[e-mail]>
Cc: "'Hoyt Kesterson'" <[e-mail]>
Subject: RE: Vagueness in empty CRLs
Date: Wed, 5 Jan 2000 17:44:02 -0500
Message-ID: <004901bf57ce$5ceeda20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

> However, the proposal to be to make that same restriction in X.509 itself
> does concern me a bit, primarily from the standpoint of backward
compatibility
> but also because we don't have a thorough way to ensure that making the
change
> wouldn't break some existing systems and environments outside PKIX.

Given the choice between ASN.1 DER purity and backwards compatibility, give
me compatibility every time.

I have never accepted that the DER rules met a real need and hearing the
argument again a fiftieth time is unlikely to convince me. I must admit
though that I am amazingly sensitive on this point having heard at length
the same argument in the context of XML documents. Strikes me that people
are going to want such a capability about as often as they stick $100 bills
into the office shredder and stick them back together with Scotch tape.

Regardless, we might well wish to consider that PKIX implementations should
be restrictive in what they create and persmissive in what they accept.

If there is a possible confusion we should perhaps state that
implementations
MUST issue the pukah DER form and SHOULD accept anything that is legal BER.


	Phill



Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04547 for <[e-mail]>; Wed, 5 Jan 2000 11:43:59 -0800 (PST)
Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id <Z6J0H1F2>; Wed, 5 Jan 2000 14:43:30 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'David P. Kemp'" <[e-mail]>, [e-mail]
Cc: "'Hoyt Kesterson'" <[e-mail]>
Subject: RE: Vagueness in empty CRLs
Date: Wed, 5 Jan 2000 14:43:28 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"

The ASN.1 in X.509 is the way it is, at least in part, for purposes 
of backward compatibility with v1 CRLs. I don't see any need to change 
that because the PKIX profile is accommodated with the current ASN.1.

On the topic of how to issue a CRL that contains zero revocation notices, 
X.509 currently allows two ways. Either the optional revokedCertificates
element
can be absent, or it can be present with an empty SEQUENCE. That also is
nothing
new, but has been allowed since the early days of v1 CRLs. 

My understanding is that the PKIX profile mandates that the issuance of a
CRL that 
contains no revocation notices be done by omiting the revokedCertificates
element. 
I have no problem with that either because it is a profile.

However, the proposal to be to make that same restriction in X.509 itself
does concern
me a bit, primarily from the standpoint of backward compatibility but also
because 
we don't have a thorough way to ensure that making the change wouldn't break
some existing
systems and environments outside PKIX. 

While this would probably be a useful thing to do, we need to remember that
PKIX is 
not the only group that is using and profiling X.509. I suppose we can check
the profiles 
and groups we are aware of (e.g. FPKI, SEIS, TC 68, ANSI, WAP etc) and if
all we know 
about uses the same method, we could raise a defect against X.509 to modify
it. I'm not saying 
I'm opposed to that, but am raising the point that PKIX is not the only
environment of concern.

If we do go ahead with a proposed change to 509, I'd prefer it to be a text 
clarification rather than a restructuring of the ASN.1, again because of
backward
compatibility.

Sharon 

> -----Original Message-----
> From: David P. Kemp [mailto:[e-mail]]
> Sent: Tuesday, January 04, 2000 1:41 PM
> To: [e-mail]
> Subject: Re: Vagueness in empty CRLs
> 
> 
> It should also be clearer in X.509-Y2K.  Perhaps the definition of
> revokedCertificates in CertificateList could be changed from:
> 
>     revokedCertificates ::= SEQUENCE OF SEQUENCE {
>         serialNumber        CertificateSerialNumber,
>         revocationDate      Time,
>         crlEntryExtensions  Extensions OPTIONAL } OPTIONAL,
>     ...
> 
> to:
> 
>     revokedCertificates ::= SEQUENCE SIZE(1..MAX) OF CrlEntry 
> OPTIONAL,
>     ...
> 
>     CrlEntry ::= SEQUENCE {
>         serialNumber        CertificateSerialNumber,
>         revocationDate      Time,
>         crlEntryExtensions  Extensions OPTIONAL }
> 
> 
> I notice that the size constraint for Extensions is present 
> in RFC 2459
> but not in X.509, so updating X.509 is not a strict 
> prerequisite.  Still,
> it would be nice if X.509 were clarified.
> 
> Dave
> 
> 
> 
> > Date: Tue, 04 Jan 2000 11:56:00 -0500
> > To: Paul Hoffman / IMC <[e-mail]>
> > From: Russ Housley <[e-mail]>
> > Subject: Re: Vagueness in empty CRLs
> > Cc: [e-mail]
> > 
> > I wrote this sentence.  I meant (a).  If you think it is 
> necessary, we can 
> > add a few words to remove the ambiguity in the next version.
> > 
> > Russ
> > 
> > 
> > At 04:56 PM 01/03/2000 -0800, Paul Hoffman / IMC wrote:
> > >RFC 2459, section 5.1.2 says:
> > >
> > >    Optional fields include lists of revoked certificates and CRL
> > >    extensions.  The revoked certificate list is optional 
> to support the
> > >    case where a CA has not revoked any unexpired 
> certificates that it
> > >    has issued.
> > >
> > >This could be read two ways:
> > >
> > >a) If there are no revoked certs, do not include the optional field
> > >
> > >b) If there are no revoked certs, you can include and 
> empty optional field 
> > >because it is, after all, optional
> > >
> > >At least one developer has coded only for (a). Do people 
> have a strong 
> > >feeling one way or another? Either way, I think this 
> should be clearer in 
> > >2459bis.
> > >
> > >--Paul Hoffman, Director
> > >--Internet Mail Consortium
> > 
> 


Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA11768 for <[e-mail]>; Tue, 4 Jan 2000 23:22:11 -0800 (PST)
Received: from l-mhs1.lannion.cnet.fr ([161.104.1.59]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C16YJN2W; Wed, 5 Jan 2000 08:22:47 +0100
Received: from lsun607 (lsun607.lannion.cnet.fr [161.104.14.41]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C1XLNSS8; Wed, 5 Jan 2000 08:21:59 +0100
Sender: dubuisso
Message-ID: <[e-mail]>
Date: Wed, 05 Jan 2000 08:21:52 +0100
From: Olivier DUBUISSON <[e-mail]>
Organization: France Telecom - Cnet - DTL/MSV - Lannion
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: "David P. Kemp" <[e-mail]>
CC: [e-mail]
Subject: Re: Vagueness in empty CRLs
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David P. Kemp wrote:
> 
> It should also be clearer in X.509-Y2K.  Perhaps the definition of
> revokedCertificates in CertificateList could be changed from:
> 
>     revokedCertificates ::= SEQUENCE OF SEQUENCE {
>         serialNumber        CertificateSerialNumber,
>         revocationDate      Time,
>         crlEntryExtensions  Extensions OPTIONAL } OPTIONAL,
>     ...
> 
> to:
> 
>     revokedCertificates ::= SEQUENCE SIZE(1..MAX) OF CrlEntry OPTIONAL,
>     ...

A minor point: this should read:
  .......
  revokedCertificates SEQUENCE SIZE(1..MAX) OF CrlEntry OPTIONAL,
  .......
because "revokedCertificates" is a component defined in a SEQUENCE
type and not a type assignment (in which case it should begin with an
upper-case letter).

Another minor point: it is better not to used "..." to mean "etc"
inside SEQUENCE types because "..." could be interpreted as an
extension marker ;-)

Happy new year.
-- 
Olivier DUBUISSON
                       France Telecom - Branche Developpement
   _/_/_/_/       Centre National d'Etudes des Telecommunications
  _/_/_/_/     DTL/MSV - Piece WF025 - 22307 Lannion Cedex - France
 _/_/_/_/         tel: [phone] - fax: [phone]
                   --> Site ASN.1 : http://asn1.elibel.tm.fr/ <--


Received: from dell_srv.bankers.org (l85.ip.quake.net [198.68.224.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13986 for <[e-mail]>; Tue, 4 Jan 2000 12:43:26 -0800 (PST)
Received: by DELL_SRV with Internet Mail Service (5.5.2232.9) id <CJ69JAQM>; Tue, 4 Jan 2000 12:41:18 -0800
Message-ID: <2F05D61D07F4D111A96900A0C90CD468259AE1@DELL_SRV>
From: Peter Yeatrakas <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 
Date: Tue, 4 Jan 2000 07:59:57 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"

subscribe


Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12099 for <[e-mail]>; Tue, 4 Jan 2000 10:44:33 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA21999; Tue, 4 Jan 2000 13:42:01 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA21994; Tue, 4 Jan 2000 13:42:00 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA25525; Tue, 4 Jan 2000 13:41:06 -0500 (EST)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id NAA00805; Tue, 4 Jan 2000 13:40:30 -0500 (EST)
Message-Id: <[e-mail]>
Date: Tue, 4 Jan 2000 13:40:30 -0500 (EST)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: Re: Vagueness in empty CRLs
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: fqlBkbMe4DO0FnMwnvK8Kg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc

It should also be clearer in X.509-Y2K.  Perhaps the definition of
revokedCertificates in CertificateList could be changed from:

    revokedCertificates ::= SEQUENCE OF SEQUENCE {
        serialNumber        CertificateSerialNumber,
        revocationDate      Time,
        crlEntryExtensions  Extensions OPTIONAL } OPTIONAL,
    ...

to:

    revokedCertificates ::= SEQUENCE SIZE(1..MAX) OF CrlEntry OPTIONAL,
    ...

    CrlEntry ::= SEQUENCE {
        serialNumber        CertificateSerialNumber,
        revocationDate      Time,
        crlEntryExtensions  Extensions OPTIONAL }


I notice that the size constraint for Extensions is present in RFC 2459
but not in X.509, so updating X.509 is not a strict prerequisite.  Still,
it would be nice if X.509 were clarified.

Dave



> Date: Tue, 04 Jan 2000 11:56:00 -0500
> To: Paul Hoffman / IMC <[e-mail]>
> From: Russ Housley <[e-mail]>
> Subject: Re: Vagueness in empty CRLs
> Cc: [e-mail]
> 
> I wrote this sentence.  I meant (a).  If you think it is necessary, we can 
> add a few words to remove the ambiguity in the next version.
> 
> Russ
> 
> 
> At 04:56 PM 01/03/2000 -0800, Paul Hoffman / IMC wrote:
> >RFC 2459, section 5.1.2 says:
> >
> >    Optional fields include lists of revoked certificates and CRL
> >    extensions.  The revoked certificate list is optional to support the
> >    case where a CA has not revoked any unexpired certificates that it
> >    has issued.
> >
> >This could be read two ways:
> >
> >a) If there are no revoked certs, do not include the optional field
> >
> >b) If there are no revoked certs, you can include and empty optional field 
> >because it is, after all, optional
> >
> >At least one developer has coded only for (a). Do people have a strong 
> >feeling one way or another? Either way, I think this should be clearer in 
> >2459bis.
> >
> >--Paul Hoffman, Director
> >--Internet Mail Consortium
> 



Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11137; Tue, 4 Jan 2000 09:47:06 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Tue, 04 Jan 2000 09:47:22 -0800
To: Russ Housley <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Vagueness in empty CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:56 AM 1/4/00 -0500, Russ Housley wrote:
>I wrote this sentence.  I meant (a).  If you think it is necessary, we can 
>add a few words to remove the ambiguity in the next version.

I think it's necessary. And easy.

--Paul Hoffman, Director
--Internet Mail Consortium



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 IAA10370; Tue, 4 Jan 2000 08:59:52 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (russ-35.spyrus.com [207.212.35.226]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA16158; Tue, 4 Jan 2000 08:56:57 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 04 Jan 2000 11:56:00 -0500
To: Paul Hoffman / IMC <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Vagueness in empty CRLs
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I wrote this sentence.  I meant (a).  If you think it is necessary, we can 
add a few words to remove the ambiguity in the next version.

Russ


At 04:56 PM 01/03/2000 -0800, Paul Hoffman / IMC wrote:
>RFC 2459, section 5.1.2 says:
>
>    Optional fields include lists of revoked certificates and CRL
>    extensions.  The revoked certificate list is optional to support the
>    case where a CA has not revoked any unexpired certificates that it
>    has issued.
>
>This could be read two ways:
>
>a) If there are no revoked certs, do not include the optional field
>
>b) If there are no revoked certs, you can include and empty optional field 
>because it is, after all, optional
>
>At least one developer has coded only for (a). Do people have a strong 
>feeling one way or another? Either way, I think this should be clearer in 
>2459bis.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium



Received: from smtp.seeder.net.tw (smtp.seeder.net [202.43.64.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA24876 for <[e-mail]>; Mon, 3 Jan 2000 17:39:42 -0800 (PST)
From: [e-mail]
Received: from babu ([210.61.251.92]) by smtp.seeder.net.tw with SMTP (IPAD 2.5) id 4092100 ; Tue, 04 Jan 2000 09:41:44 +0800
Message-ID: <003801bf5654$ab940770$[e-mail]>
To: <[e-mail]>
Subject: Fw: MS and NS certificate format for SSL and S/MIME
Date: Tue, 4 Jan 2000 09:40:20 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01BF5697.B7540310"
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

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01BF5697.B7540310
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Hello,
   Does anybody know where can  I find the documents or URL that explain =
what extensions to Mircosoft and Netscape expects in certificates for =
SSL and S/MIME purpose? I want to know which certificate extensions =
should be used for MS and NS applications, such as browser and email ap, =
exactly?

Best Regrards,
James Lam.

------=_NextPart_000_0035_01BF5697.B7540310
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hello,</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp; Does anybody know where can&nbsp; I =
find&nbsp;the=20
documents or URL that explain what extensions to Mircosoft and Netscape =
expects=20
in certificates for SSL and S/MIME purpose? I want to know which =
certificate=20
extensions should be used for MS and NS applications,&nbsp;such as =
browser and=20
email ap, exactly?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Best Regrards,</FONT></DIV>
<DIV><FONT size=3D2>James Lam.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0035_01BF5697.B7540310--



Received: from v4j31 (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA24231 for <[e-mail]>; Mon, 3 Jan 2000 16:56:07 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Mon, 03 Jan 2000 16:56:06 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Vagueness in empty CRLs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

RFC 2459, section 5.1.2 says:

    Optional fields include lists of revoked certificates and CRL
    extensions.  The revoked certificate list is optional to support the
    case where a CA has not revoked any unexpired certificates that it
    has issued.

This could be read two ways:

a) If there are no revoked certs, do not include the optional field

b) If there are no revoked certs, you can include and empty optional field 
because it is, after all, optional

At least one developer has coded only for (a). Do people have a strong 
feeling one way or another? Either way, I think this should be clearer in 
2459bis.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from sentry ([e-mail] [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21224 for <[e-mail]>; Mon, 3 Jan 2000 12:35:09 -0800 (PST)
Received: by sentry; id PAA28438; Mon, 3 Jan 2000 15:36:10 -0500 (EST)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma028428; Mon, 3 Jan 00 15:35:40 -0500
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id PAA00881 for [e-mail]; Mon, 3 Jan 2000 15:34:25 -0500 (EST)
Date: Mon, 3 Jan 2000 15:34:25 -0500 (EST)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Jan. 6th early registration deadline for ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000)

S A V E   $ 7 0   O F F   R E G I S T R A T I O N   F E E ! !
R E G I S T E R   B Y   J A N U A R Y   6 ,   2 0 0 0 

THE INTERNET SOCIETY'S
Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 2-4, 2000
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Gene Tsudik, USC/Information Sciences Institute
		 Avi Rubin, AT&T Labs - Research

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss2000
EARLY REGISTRATION DISCOUNT DEADLINE:  January 6, 2000

The 7th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at
Purdue University, an expert in information security, computer crime
investigation and information ethics.  Spaf (as he is known to his
friends, colleagues, and students) is director of the Purdue CERIAS
(Center for Education and Research in Information Assurance and
Security), and was the founder and director of the (now superseded)
COAST Laboratory. 

THIS YEAR'S TOPICS INCLUDE:
- Automated Detection of Buffer Overrun Vulnerabilities
- User-Level Infrastructure for System Call Interposition
- Optimized Group Rekey for Group Communication Systems
- IPSec-based Host Architecture for Secure  Internet Multicast
- The Economics of Security
- Automatic Generation of Security Protocols
- Security Protocols for SPKI-based Delegation Systems
- Secure Border Gateway Protocol (S-BGP)
- Analysis of a Fair Exchange Protocol
- Secure Password-Based Protocols for TLS
- Chameleon Signatures
- Lightweight Tool for Detecting Web Server Attacks
- Adaptive and Agile Applications Using Intrusion Detection
- Secure Virtual Enclaves
- Encrypted rlogin Connections Created With Kerberos IV
- Accountability and Control of Process Creation in Metasystems
- Red Teaming and Network Security

PRE-CONFERENCE TECHNICAL TUTORIALS:
- Network Security Protocol Standards, Dr. Stephen T. Kent
- Deployed and Emerging Security Systems for the Internet, Dr. Radia
  Perlman and Charlie Kaufman
- Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw
- Cryptography 101, Dr. Aviel D. Rubin
- Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel
  E. Geer, Jr.
- An Introduction to Intrusion Detection Technology, Mr. Mark Wood 

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA
  Phone: [phone]         Fax: [phone]
  E-mail: [e-mail]   URL: http://www.isoc.org/ndss2000/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at [phone] or send e-mail to [e-mail].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.