Subject: RE: President Clinton digital signing

From: [email-masked]
Date: Tue, 22 Aug 2000 11:58:07 -0400

GSA has no reluctance to embracing OCSP, and is moving in that direction.
However, when CAM development was begun OCSP was not yet a standard.  We
held several industry forums and asked the attendees whether we should
ascribe to OCSP or develop something generic.  The unanimous response was
to do something generic, since they did not want to be tied to a specific
solution.  We listened.  Since then OCSP became a standard, and now, of
course, there has been an about-face on everyone's opinion.  The CAM will
embrace OCSP in its future development.

Thanks

Judy Spencer

[email-masked]@flashcom.net> on 08/22/2000 11:19:12 AM

Please respond to [email-masked]

Sent by:  "Jeff Spinney" <[email-masked]>

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

Subject:  RE: President Clinton digital signing

this is very interexting, can somebody please comment on why the US govt
(GSA, at least) doesnt seem to want to embrace OCSP as a validation
mechanism for ACES (and other programs)??   the 'CAM' as they call it sems
to be an alternative mechanism....a duplication of much of the work OCSP
has
already worked through...

-j

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 8:52 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: President Clinton digital signing

Terri suggests that the real significance of the certificate and smart card
used by President Clinton is that they were obtained through the Access
Certificates for Electronic Services (ACES) contract at GSA.  Through the
use of a Certificate Arbitrator Module (CAM), which is effectively a parser
and validation tool (offered to public domain by GSA), multiple CA's are
made available to the government applications.

More info at

http://www.gsa.gov/aces/

To me, though, the most significant thing is that the E-Sign bill was
signed, regardless of the technology utilized.

Cheers,

---

From: "Morrill, Dan" <[email-masked]>
Date: Tue, 22 Aug 2000 10:21:16 -0700

For specific information about the CAM and its status, please check out

http://cam.fts.gsa.gov/

Cheers,
r/
Dan

-----Original Message-----
From: Tom Strickland [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 09:18 AM
To: [email-masked]; [email-masked]
Subject: Re: President Clinton digital signing

You are correct to ask "why the US govt (GSA, at least) dosent seem to want
to
embrace OCSP as a validation mechanism for ACES (and other programs)??".
You have to remember that ACES does have built in OCSP. The product that
they
chose includes an OCSP "real time" responder, not antiquated CRLs.

Please review the following URLs to see how and why Xcert was chosen:

ACES announcement:
http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html

Reference to digital signature law:
http://www.xcert.com/resources/esign/index.html

Sentry CA functionality:
http://www.xcert.com/software/sentryca.html

Scalability to manage over 8 million certs on one CA and box:
http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html

has

---

From: Philip Hallam-Baker <[email-masked]>
Date: Tue, 22 Aug 2000 18:07:35 -0700

> signed, regardless of the technology utilized.

And it was totally illogical to use a digital signature for the purpose.

The act is now effectively a self-signed cert! The validity of the 
authentication on the act is established through a circular reference
to the act itself.

		Phill

---

From: [email-masked]
Date: Wed, 23 Aug 2000 06:59:47 -0400

At the time of the Presidential signing, only Digital Signature Trust had
completed the exhaustive certification and accreditation process required
by GSA in order to receive authorization to issue ACES certificates (AT&T
has now been certified, ORC is still in the process).  The DST ACES
solution that was certified uses the XCERT product (this was a decision
made by DST, not mandated by the government).  Therefore, on June 29, under
the ACES contract, only DST was authorized to issue certificates, and the
system certified to issue those certificates utilized the XCERT CA.

Judy Spencer
GSA

"Al Arsenault" <[email-masked]> on 08/22/2000 03:00:23 PM

To:   "Tom Strickland" <[email-masked]>
cc:   [email-masked], "[email-masked]" <[email-masked]>,
      [email-masked], [email-masked]

Tom Strickland wrote:
<gratuitous shot at CRLs snipped>
><long list of URLs snipped>

That's all fine and dandy, but I thought that the question was:

"Why was a DST/XCert certificate selected for use, vice something from
one of the other ACES contractors?"

Since IIRC DST had the first ACES contract, I can certainly see giving
them this task. But was there any special reason DST chose XCert, since
DST provides certificates using most if not all of the major CA
providers' equipments?

          Al Arsenault
          Chief Security Architect
          Diversinet Corp.

---

From: [email-masked]
Date: Wed, 23 Aug 2000 09:37:06 -0400

Right on Philip (as usual)!  But it seems unlikely that the bill was not
"signed" twice, one being a wet signature (with no photo op).  Does anyone
know for sure?

Bill Flanigan

-----Original Message-----
From: Philip Hallam-Baker [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 9:08 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: President Clinton digital signing

[snip]

		Phill

---

From: Ambarish Malpani <[email-masked]>
Date: Wed, 23 Aug 2000 08:40:49 -0700

Hi Liaquat,
    CRLs *don't* have to only be issued periodically. It is
perfectly reasonable to issue new CRLs on demand (i.e. whenever
a new revocation even happens) in addition to issuing the regular
periodic CRLs.

Regards,
Ambarish

Hi Tom,
    I am not sure I buy the DoS attack. There are a few ways around
it:
a. Make sure the OCSP server and CA are both behind a firewall
with a fat pipe between them.

b. You can have the OCSP server ping the CRL database periodically
and stop responding if it can't reach it within say a 5 second
interval. This still allows you to ensure that you have the latest
data (within 5 seconds), but still allows you to process pretty
large numbers of OCSP requests.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: Liaquat Khan [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2000 7:00 AM
> To: [email-masked]
> Tom,
> I generally agree with you, but I think the issue of 
> launching a DoS attack
> on CRLs has been mixed in with the periodic nature of CRLs.  
> There are two
> separate risks:
> 
> 1) a CRL has expired and a new one has not been generated in 
> time (e.g. due
> to a DoS attack).  In this case the relying party should not 
> really depend
> on the CRL as it should be obvious from reading the available 
> CRL that it is
> out of date.  Therefore, certificates may have been revoked 
> in the meantime
> but there is no fresh CRL to check, so you abort the 
> transaction.  This is
> DoS.
> 
> 2) a certificate is revoked but the next CRL is not due to be 
> issued until
> later.  Therefore, this scenario is not related to a DoS attack.  To
> overcome this you need to ensure that CRLs are issued with a 
> frequency which
> is acceptable.  By using OCSP, it doesn't necessarily mean 
> this issue goes
> away...you will still need to work out how long it will take 
> from the time a
> decision is made to revoke a certificate to the time that the 
> OCSP server
> becomes aware of this (e.g. note that the OCSP server may be fed using
> periodic CRLs).
> 
> Regards,
> Liaquat Khan
> Technical Manager
> Global Trust Authority (GTA)
> 
> 
> 
> A relying
> ----- Original Message -----
> From: Tom Strickland <[email-masked]>
> To: Liaquat Khan <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 23, 2000 1:31 PM
> > Liaquat,
> > You bring up a very good point, DoS attacks are a risk in each
> environment.
> > However if your environment has critical need for current 
> data (such as a
> bank
> > or government), then a CRL has a higher risk.
> >
> > Example: If a company does not have a requirement for 
> current information,
> a CRL
> > is sufficient. If a company requires real time data (i.e. a bank or
> government)
> > due to high value transactions or security, then I would 
> highly recommend
> OCSP.
> > The risk is if you use CRLs for the latter, the company may 
> get a false
> sense of
> > security believing their "high value" transactions are 
> guarded by real
> time
> > data. If the batch CRL is latent, you may continue 
> processing utilizing
> old
> > data. The risk is a cert believed to be revoked may still 
> be considered
> good in
> > the system exposing the company to potential fraud or negligence.
> >
> > In an OCSP environment, if you must trust real time data and someone
> executes a
> > DoS attack, the responder may slow down or worst case, stop 
> working. This
> is an
> > added value because I would rather slow down or stop 
> processing than to
> rely on
> > old data. The risk here is slower response time but 
> guaranteed accurate
> > information.
> >
> > This is a question that each company must answer by 
> performing a risk
> assessment
> > to determine their acceptable level of "pain", risk and exposure.
> >
> > I am not trying to be confrontational in my recent 
> "typings". I am just
> trying
> > to bring added value to everyone here. As an auditor that 
> has performed
> audits
> > on several PKI environments, I am just trying to help 
> elevate certain
> risks that
> > sometimes get overlooked.
> >
> > Best regards,
> >
> > Tom
> >
> > Liaquat Khan wrote:
> >
> > > You have to assume that access to the server which issues CRLs is
> protected
> > > from denial of service attacks.  For example, generally 
> only trusted
> > > operators can authorise the generation of CRLs, after having their
> > > identities authenticated by the server.  Also access to 
> the CRL issuer
> has
> > > to be protected through firewalls, etc.
> > >
> > > If an attacker can perform a DoS attack on a CRL issuer, 
> what is there
> to
> > > stop him/her launching a similar attack on an OCSP server (e.g. by
> issuing
> > > an extremely large amount of OCSP requests)?
> > >
> > > Regards,
> > > Liaquat Khan
> > > Technical Manager
> > > Global Trust Authority (GTA)
> > >
> > > ----- Original Message -----
> > > From: Tom Strickland <[email-masked]>
> > > To: Ambarish Malpani <[email-masked]>
> > > Cc: <[email-masked]>; <[email-masked]>
> > > Sent: Wednesday, August 23, 2000 5:11 AM
> > > > Hello Ambarish,
> > > > Thanks for your reply. I agree that OCSP services are 
> by far better
> than
> > > > CRLs. In general, as everyone knows, a CRL is a batch 
> job that updates
> a
> > > > database over certain intervals. From an audit 
> standpoint, one of the
> many
> > > > issues with CRLs is that they can be beat. For example, 
> it is very
> easy to
> > > > perform any series of denial of service attacks against 
> the server.
> This
> > > > could cause longer than expected delays in the 
> execution of the batch
> job
> > > > or worse, prevent the batch job from running causing latent (or
> corrupted)
> > > > CRL publishing. Also, if someone is savvy enough, they 
> could also
> issue
> > > > hundreds of back to back CRL job requests resulting in 
> multiple jobs
> > > > waiting on shared services again causing problematic 
> CRLs. I know this
> may
> > > > sound farfetched but they are risks to be considered.
> > > >
> > > > As you may guess I am not a proponent of CRLs for 
> obvious reasons. I
> have
> > > > heard claims by some that their products are OCSP compliant. In
> reality it
> > > > is just a batch job publishing to a database but still they have
> inherent
> > > > CRL batch job latency.
> > > >
> > > > As for the CAM, I am not familiar enough with that to 
> argue for or
> against
> > > > its use. I do know however that the Xcert product has a non
> proprietary
> > > > real time OCSP LDAP out of the box resulting in a more 
> robust product.
> > > Note
> > > > that the Sentry CA product can publish CRLs to non OCSP 
> products to
> offer
> > > > backwards compatibility when needed. Also, the Sentry 
> product can
> import
> > > > other vendors CRLs and place them in the real time OCSP LDAP.
> > > >
> > > > Also one of the several reasons that Sentry CA was 
> chosen was due to
> its
> > > > ability to cross certify against other CAs (cross 
> certification). It
> is
> > > > very easy to setup trust to another company's CA 
> allowing multiple CAs
> or
> > > > PKI vendors within a central Sentry OCSP environment.
> > > >
> > > > Best regards,
> > > >
> > > > Tom
> > > >
> > > >
> > > > Ambarish Malpani wrote:
> > > >
> > > > > Hi Tom,
> > > > >
> > > > > It really isn't that hard to set up quite a few of the CAs to
> > > > > create a new CRL whenever a new revocation happens.
> > > > >
> > > > > Think of this CRL as a snapshot of the CA's 
> revocation database
> > > > > and the publishing of a new CRL as a trigger to tell the OCSP
> > > > > server that the snapshot has changed.
> > > > >
> > > > > Really, an OCSP server can be set up to be as current 
> as any other
> > > > > software to provide revocation information, either 
> with or without
> > > > > CRLs.
> > > > >
> > > > >     It is completely unclear to me why the CAM solution is any
> > > > > more real time than OCSP. I believe the real reason for the
> > > > > CAM solution was just that OCSP didn't exist as a 
> standard till
> > > > > late in the ACES project as indicated by the mails from both
> > > > > Judith and Tim. I have a suspicion that it still 
> might be faster
> > > > > and cheaper for ACES to go with OCSP, rather than try 
> to stick to
> > > > > a non-standard protocol.
> > > > >
> > > > > Regards,
> > > > > Ambarish
> > > > >
> > > >
> > 
> ---------------------------------------------------------------------
> > > > > Ambarish Malpani
> > > > > Architect
> 650.567.5457
> > > > > ValiCert, Inc.
> [email-masked]
> > > > > 339 N. Bernardo Ave.
> http://www.valicert.com
> > > > > Mountain View, CA 94043
> > > > >
> > > > > > Sent: Tuesday, August 22, 2000 9:18 AM
> > > > > > You are correct to ask "why the US govt (GSA, at least)
> > > > > > dosent seem to want to
> > > > > > You have to remember that ACES does have built in OCSP. The
> > > > > > product that they
> > > > > > Please review the following URLs to see how and why 
> Xcert was
> chosen:
> > > > > >
> > > > > > ACES announcement:
> > > > > > 
> > > > > > to be an alternative mechanism....a duplication of much of
> > > > > the work OCSP has

---

From: Khaja Ahmed <[email-masked]>
Date: Wed, 23 Aug 2000 12:44:23 -0400

Liaquat,

You are quite right.  In fact, this is the easiest (perhaps only standard
based) way of capturing authoritative snapshots that can then be used for
archiving - for 7 yr record keeping requirements, etc.  If a certificate was
suspended for a week and during that period no OCSP request was made on the
status of this certificate you would still have a record of this in
archives.  This can be invaluable for future dispute resolution proceedings
for example.

For this reason many PKIs mandate that CRLs be generated on every revocation
event in addition to periodic CRL publishing.

Khaja
=========================================== 

Khaja E. Ahmed 
Chief Technology Officer 

Identrus, LLC. 
16th Floor 
140 E 45th St. 
New York, NY 10017 USA 
Telephone: 01.212.622.0673 
Fax: 01.212.622.9196 

[email-masked] 
Cell Phone: 01.925.989.6564 
Home office: 01.925.462.0453
============================================ 

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 8:02 AM
To: [email-masked]
Subject: Re: President Clinton digital signing

Tom,

Isn't it a good idea to generate CRLs anyway, even if you are using OCSP?
The main reason I have in mind is so that the CRL acts as a historical
record of when the certificate was revoked.
On the other hand, an OCSP response would only be sent subsequent to
receiving an appropriate OCSP request message.

Regards,
Liaquat Khan
Technical Manager

----- Original Message -----
From: Tom Strickland <[email-masked]>
To: Sam Schaen <[email-masked]>
Cc: Liaquat Khan <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 23, 2000 2:20 PM
Subject: Re: President Clinton digital signing

> If you are using a mixture or hybrid OCSP environment to perform checking
with an import
> of CRL data, yes the result could be the same.
>
> However, if you are using a true OCSP LDAP environment (i.e. no CRLs),
part of your
> system may slow down due to the DoS but the validity would always be
accurate.
>
> In the Sentry product, each Registration Authority (RA) has a built in
real time OCSP
> LDAP. This allows a complete OCSP enterprise without the need for any CRLs
(unless you
> want to cross certify a CRL from other non OCSP PKI vendors). This means
that your risk
> of DoS attacks may only slow down one leg (RA) or department of your PKI
environment,
> not the whole enterprise ensuring accurate real time information.
>
> Sam Schaen wrote:
>
> > If the DoS prevents the OCSP responder from receiving a CRL from which
it determines
> > validity status, the result is the same.
> >
> > Tom Strickland wrote:
> >
> > > Liaquat,
> > >
environment.
> > > However if your environment has critical need for current data (such
as a bank
> > > Example: If a company does not have a requirement for current
information, a CRL
government)
> > > due to high value transactions or security, then I would highly
recommend OCSP.
> > > The risk is if you use CRLs for the latter, the company may get a
false sense of
> > > security believing their "high value" transactions are guarded by real
time
> > > data. If the batch CRL is latent, you may continue processing
utilizing old
> > > data. The risk is a cert believed to be revoked may still be
considered good in
executes a
> > > DoS attack, the responder may slow down or worst case, stop working.
This is an
> > > added value because I would rather slow down or stop processing than
to rely on
> > > old data. The risk here is slower response time but guaranteed
accurate
> > > information.
> > >
> > > This is a question that each company must answer by performing a risk
assessment
> > > I am not trying to be confrontational in my recent "typings". I am
just trying
> > > to bring added value to everyone here. As an auditor that has
performed audits
> > > on several PKI environments, I am just trying to help elevate certain
risks that
protected
> > > > from denial of service attacks.  For example, generally only trusted
> > > > identities authenticated by the server.  Also access to the CRL
issuer has
> > > > If an attacker can perform a DoS attack on a CRL issuer, what is
there to
issuing
> > > > > Thanks for your reply. I agree that OCSP services are by far
better than
> > > > > CRLs. In general, as everyone knows, a CRL is a batch job that
updates a
> > > > > database over certain intervals. From an audit standpoint, one of
the many
> > > > > issues with CRLs is that they can be beat. For example, it is very
easy to
> > > > > perform any series of denial of service attacks against the
server. This
> > > > > could cause longer than expected delays in the execution of the
batch job
corrupted)
> > > > > CRL publishing. Also, if someone is savvy enough, they could also
issue
> > > > > hundreds of back to back CRL job requests resulting in multiple
jobs
> > > > > waiting on shared services again causing problematic CRLs. I know
this may
> > > > > As you may guess I am not a proponent of CRLs for obvious reasons.
I have
reality it
inherent
> > > > > CRL batch job latency.
> > > > >
> > > > > As for the CAM, I am not familiar enough with that to argue for or
against
proprietary
> > > > > real time OCSP LDAP out of the box resulting in a more robust
product.
> > > > Note
> > > > > that the Sentry CA product can publish CRLs to non OCSP products
to offer
> > > > > backwards compatibility when needed. Also, the Sentry product can
import
> > > > > Also one of the several reasons that Sentry CA was chosen was due
to its
> > > > > ability to cross certify against other CAs (cross certification).
It is
> > > > > very easy to setup trust to another company's CA allowing multiple
CAs or
> > > > > > Think of this CRL as a snapshot of the CA's revocation database
> > > > > > Really, an OCSP server can be set up to be as current as any
other
> > > > > > software to provide revocation information, either with or
without
> > > > > > CAM solution was just that OCSP didn't exist as a standard till
> > > > > > Judith and Tim. I have a suspicion that it still might be faster
> > > > > > and cheaper for ACES to go with OCSP, rather than try to stick
to
650.567.5457
[email-masked]
http://www.valicert.com

---

From: [email-masked]
Date: Wed, 23 Aug 2000 12:55:14 -0400

The e-signing of the bill was a demonstration of the technology.  You're
right.  The bill was officially signed with a pen and then a wax seal was
applied.  I'm having a little trouble with your "circular reference"
statement and that the bill is a "self-signed certificate".  Perhaps you'd
be willing to explain your reasoning to me more fully.

Judy Spencer

"Flanigan, William, CIV,BMDO/DSC" <[email-masked]> on
08/23/2000 09:37:06 AM

To:   "'Philip Hallam-Baker'" <[email-masked]>
cc:   [email-masked], [email-masked],
      "[email-masked]'" <[email-masked]>, [email-masked]

Bill Flanigan

-----Original Message-----
From: Philip Hallam-Baker [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 9:08 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: President Clinton digital signing

[snip]

              Phill

---

From: Khaja Ahmed <[email-masked]>
Date: Wed, 23 Aug 2000 13:03:24 -0400

Re Steve's point that CRLs can be replicated at any number of servers...

It is also possible to have a number of OCSP servers that get CRLs fed to
them based on which they respond to OCSP requests.  Unless I am much
mistaken, nothing in the OCSP protocol prevents an OCSP server from having a
distributed / widely replicated presence.

While this is more expensive** than having CRLs available at multiple
servers it offers the advantages that are associated with getting OCSP
responses rather than CRLs to a relying party.  In some cases this may be
quite acceptable.

Khaja

** An OCSP server has security requirements and performance requirements
that do not get imposed on a web server that simply has a CRL available for
download. 

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 7:03 AM
To: Tom Strickland
Cc: [email-masked]
Subject: Re: President Clinton digital signing

Tom,

>Hello Ambarish,
>
>Thanks for your reply. I agree that OCSP services are by far better than
>CRLs.

I think this is an over generalization, i.e., OCSP is bettr in some 
cases, but not in all cases.

>In general, as everyone knows, a CRL is a batch job that updates a
>database over certain intervals. From an audit standpoint, one of the many
>issues with CRLs is that they can be beat. For example, it is very easy to
>perform any series of denial of service attacks against the server.

Which server? A directory?  A CRL has the advantage that it can be 
replicated at any numnber of servers, without imbuing these serves 
with trust (re integrity and authenticity).  While it is certainly 
true that one can engage in  a DoS attack against directories, the 
same is also true for OCSP servers. I don't think we have enough 
experience with both types of servers to determine if one is more 
susceptible than the other, as a class, or if it's just an issue of 
implementation and local management quality.

>This
>could cause longer than expected delays in the execution of the batch job
>or worse, prevent the batch job from running causing latent (or corrupted)
>CRL publishing.

Batch job?  Now it sounds like your talking about a CA preparing a 
CRL.  A CA component generating a CRL need not be online and thus 
need not be very susceptible to DoS attacks, so I'm puzzled by this 
line of reasoning.

>Also, if someone is savvy enough, they could also issue
>hundreds of back to back CRL job requests resulting in multiple jobs
>waiting on shared services again causing problematic CRLs. I know this may

CRL job requests?  I've been involved with the design of several CAs 
over time and none offered an external interface which could be 
manipulated inthe fashion you suggest.

>As you may guess I am not a proponent of CRLs for obvious reasons. I have
>heard claims by some that their products are OCSP compliant. In reality it
>is just a batch job publishing to a database but still they have inherent
>CRL batch job latency.

The latency issue re CRLs is a red herring, in almost all cases. The 
time required to generate a CRL is fairly small for almost any PKI of 
a reasonable size.  The external, non-technical factors associated 
with deciding that a compromise has occurred or that an attribute has 
changed and thus a cert should be revoked almost always swamp the CRL 
production activity.

>As for the CAM, I am not familiar enough with that to argue for or against
>its use. I do know however that the Xcert product has a non proprietary
>real time OCSP LDAP out of the box resulting in a more robust product. Note
>that the Sentry CA product can publish CRLs to non OCSP products to offer
>backwards compatibility when needed. Also, the Sentry product can import

Oh, OCSp and LDAP?  That combination suggests an DoS opportunity that 
might be the sum of the two server interfaces :-).

>Also one of the several reasons that Sentry CA was chosen was due to its
>ability to cross certify against other CAs (cross certification). It is
>very easy to setup trust to another company's CA allowing multiple CAs or

No more product endorsements, OK?

Steve

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 23 Aug 2000 11:03:10 -0600

I believe that the bill was in fact signed twice, once with a pen, but I also believe that the concern about circularity is a red herring. 

I would argue that it is the President's approval , rather than his signature, that causes a Bill to become law. His signature is but one of many means of evidencing and memorializing that approval -- witnesses, photo ops, etc., could very reasonably be considered evidence of such approval as well, and would actually be far more compelling than the mechanical pen signature that I understand is routinely used for bills of less than stellar significance. 

In any case, because he didn't veto the bill and return it to the Congress, it would have become binding within ten days in any case, except if it had occurred at the end of the Congressional term (a "pocket veto"), which was not the case. 

So it would have become the law of the land no matter how it was signed, or absent any signature at all. 

Article I, Section 7 of the Constitution of the United states reads as follows: 

Section. 7. All Bills for raising Revenue shall originate in the 
House of Representatives; but the Senate may propose or concur with 
amendments as on other Bills. 
Every Bill which shall have passed the House of Representatives 
and the Senate, shall, before it become a law, be presented to the 
President of the United States: If he approve he shall sign it, but if 
not he shall return it, with his Objections to that House in which it 
shall have originated, who shall enter the Objections at large on their 
Journal, and proceed to reconsider it. If after such Reconsideration two 
thirds of that House shall agree to pass the Bill, it shall be sent, 
together with the Objections, to the other House, by which it shall 
likewise be reconsidered, and if approved by two thirds of that House, 
it shall become a Law. But in all such Cases the Votes of both Houses 
shall be determined by Yeas and Nays, and the Names of the Persons 
voting for and against the Bill shall be entered on the Journal of each 
House respectively. If any Bill shall not be returned by the President 
within ten Days (Sundays excepted) after it shall have been presented to 
him, the Same shall be a Law, in like Manner as if he had signed it, 
unless the Congress by their Adjournment prevent its Return, in which 
Case it shall not be a Law 
Every Order, Resolution, or Vote to which the Concurrence of the 
Senate and House of Representatives may be necessary (except on a 
question of Adjournment) shall be presented to the President of the 
United States; and before the Same shall take Effect, shall be approved 
by him, or being disapproved by him, shall be repassed by two thirds of 
the Senate and House of Representatives, according to the Rules and 
Limitations prescribed in the Case of a Bill. 

The merits of the bill, however, are a different issue. 

Bob 

>>>< [email-masked] > 08/23/00 07:37AM >>> 

Right on Philip (as usual)! But it seems unlikely that the bill was not "signed" twice, one being a wet signature (with no photo op). Does anyone know for sure? 
Bill Flanigan 
-----Original Message----- 
From: Philip Hallam-Baker [ mailto:[email-masked] 
Sent: Tuesday, August 22, 2000 9:08 PM 
To: ' [email-masked]' ; [email-masked] 
Cc: [email-masked] ; [email-masked] 
Subject: RE: President Clinton digital signing 
[snip] 

Phill

---

From: Mathew Butler <[email-masked]>
Date: Wed, 23 Aug 2000 11:25:42 -0700

The question is, "Is there some certification authority that was designated
by [whoever has the power to make the designation, be it Congress or the GSA
or the GAO or whoever], that signed the certificate that President Clinton
used to sign the bill, in order to ensure the authenticity and integrity of
the signature [in order to make it legally binding]?"

I know that there is nothing in law (even with the signing of this bill)
that allows the President to ratify a bill with anything other than a
physical signature and seal.  Therefore, the entire question is completely
ludicrous in the first place, as the answer is patently "No".

However, there's a few questions I have... what CA -did- sign the
certificate that President Clinton used?  Is there an actual copy of the
electronically signed version of the bill, including signature, online that
we can look at?  Also, can we get a copy of the certificate that he used,
along with the entire certificate chain to the certificate for the root?

(Rather than spamming the list, is there a URL on the GSA's website that
would provide access to this information?)

Thanks!

-Mat Butler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 9:55 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: President Clinton digital signing

Judy Spencer

Bill Flanigan

-----Original Message-----
From: Philip Hallam-Baker [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 9:08 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: President Clinton digital signing

[snip]

              Phill

---

From: Philip Hallam-Baker <[email-masked]>
Date: Wed, 23 Aug 2000 16:44:44 -0700

>I believe that the bill was in fact signed twice, once with a pen, but
I also believe that >the concern about circularity is a red herring. 

It was a humorous observation I didn't expect you folk to make a federal
case out of it!

The bill had to be signed twice because the whole premise of the act was
legitimizing the use of digital signatures. If the digital signature
alone was sufficient to sign an act of Congress then they were good
enought for government work without the act. If the act was essential
but only signed with a signature that was invalid absent the act there
would be a circularity of reference.

I agree that from that point of view, the bill itself was probably
unnecessary to the extent that we all know that English Common Law (and
its colonial derrivatives) is very tolerant of what is recognized as a
'signature'.

There was actually an English Constitutional crisis when one of the
Stuart Kings absconded, chucking the great seal of office in the Thames
during his escape in an attempt to prevent parliament doing anything in
his absence. But for the chance recovery of the seal by a fisherman the
paliamentary faction would doubtless have decided that some arcane
ceremony involving the parliamentary maces and such sanctified a new
seal...

In the case of the US Constitution however, the act didn't actually need
signing at all - absent a veto the bill would have become law in any
case.

	Phill

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 23 Aug 2000 17:24:02 -0700

>It was a humorous observation I didn't expect you folk to make a federal

:)

And I enjoyed the story of the Stuart King.

But for the sake of "formalism" (and curiosity) doe anyone know just
what CA has certified this key?  Or what the precise DN looks like?

More to the point, was the entire exercise of signing with this key
just a cute charade, or does the U.S. President (now, officially)
have a digital key with which to sign "documents of the office", and
if so, what are the attributes of the corresponding certificate?

(It must expire soon ;)

The question of "who certifies the President's digital signature"
is an interesting one, in my view, not only now but in general.

___tony___

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

---

From: Mathew Butler <[email-masked]>
Date: Wed, 23 Aug 2000 18:05:41 -0700

This is why I wanted the certificates all the way up to the root, as well as
the signed digital representation of the bill.

-Mat

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 5:57 PM
To: Mathew Butler; Philip Hallam-Baker; 'Bob Jueneman';
[email-masked]; Philip Hallam-Baker
Cc: [email-masked]
Subject: RE: President Clinton digital signing

At 05:27 PM 8/23/00 -0700, Mathew Butler wrote:
>There is no digital key that can sign "documents of office".  The
>legislation changed how certain high-value monetary transactions can be
>signed -- it didn't modify how the president does his job.

Understood, thank you.

The "act" of digitally signing the bill in question was an empty gesture,
so to speak.  Out of curiosity, was it accomplished with an entirely
arbitrary "signing key" (a string of zeros, perhaps) or was the (empty)
formalism carried further (formal parameters, certificate, etc.)?

Is the signature formally (if not legally) verifiable?

___tony___

---

From: [email-masked]
Date: Wed, 23 Aug 2000 23:01:22 EDT

Dear Friends,

The use of the dst or abaecom ca generated certificate to sign the bill 
electronically was certainly meaningful in a politically symbolic sense, but 
not the legal signature that transformed the bill into law.  The President 
used his pen first and will continue to do so because of tradition.

I suggest that the technical issues involved in the signing are not only not 
really meaningful, but also not interesting.  We passed the bill we wanted by 
ignoring the technology and focusing on the issues that are meaningful to 
politicians and ordinary people.   I repeately said, "This effort is not 
about technology or technology vendors.  This effort is about the freedom to 
contract and the right to expect contracts to be enforced."  I argued that 
the Federal and state governments should not interfere with voluntary 
contracts and should instead support and enforced such arrangements.  We won 
on this basis without having to explain how the crypto or biometrics might 
work.

The push to get where we are has taken a lot of time and effort, and I am 
proud to say that at no time has political fundraising or partisan politics 
played a role in the outcome.  We won this one on the strength of our 
arguments and the soundness of our strategy.

The path to legal certainty was a long one and the strategy required 
collaboration between a number of old Washington hands running both strategy 
and interference to prevent less fair and less reasonable approaches from 
gaining ground.

I have been lobbying on these issues for nearly a decade and was pleased to 
see the basic underpinnings for a supportive legal infrastructure for 
electronic commerce created.   (I worked at the US Treasury and the American 
Bankers Association doing technology strategy, policy, and standards for the 
industry)

HISTORY OF THE EFFORT

The federal government has had the power to determine itself what forms of 
legal arrangements can bind the executive, legislative, and judiciary 
branches to writings or agreements of any sort.   

Quite some time ago the Executive Branch (administrative, not political 
officers) exercising its legitimate sovereignty published a policy that 
clearly supported electronic authentication as a legitimate contracting 
mechanism that could bind the government and contractors to agreements.  
(this was not a spontaneous act)

We followed up by pushing for and getting reduced regulatory overhead on an 
agency by agency and department by department basis.

A little later the Government Paperwork Elimination Act reinforced and 
broadened the Federal legal infrastructure's support for electronic 
agreements between the government, individuals, and firms.  (this incremental 
bit of legislation was critical to positioning the next and later steps)

We again broadened and further supported the legal framework for electronic 
commerce by passing the most recent act, which provides for purely voluntary 
and arbitrary agreements between contracting parties.

We have a bit of fine tuning to go and more to do.  Some part of  e-enabling 
commerce still requires that we push policy changes, but much more work is 
required to make the technologies offered as solutions meet the practical 
requirements of the real world.

I suggest that the arrogance of technologists and technology vendors is the 
greatest obstacle to adoption and acceptance that PKI faces.  We have the 
basic supportive legal infrastructure built (effective in october).   I am 
looking foward to addressing the challenges presented by both the lack of a 
sufficiently supportive technological infrastructures and the lack of support 
for the deployment of the technology on a business case basis as well as a 
whole host of other business issues. 

I hope that each of you can help to make PKI more practical so that we can 
get pragmatists to see its value, buy it, pay for it, use it, and recommend 
it to each other.

aloha...kawika

kawika daguio
301 332 5224

---

From: [email-masked]
Date: Wed, 23 Aug 2000 13:14:45 -0700

a number of financial infrastructures not only need real-time status  ... but
also things like real time inforatmion, no single point of failrues and some
even five nines availability. also looking at it from a transaction flow aspect,
the transaction has to hit the account record (for other real time informaiton
reasons ... like account balance) ... and involve an infrastructure that have
existing business infrastructures with both authentication and authorization.
For these types of financial infrastructures ... they need to control their own
infrastructure including things like RAs ... where they do the public key
registration in the account record ... and returning a copy of relying-party
only certificate to the account holder (for liability and privacy reasons).

The interesting thing is that these protocols appends a copy of the certificate
to a signed message that is sent to the financial institution ... when the
financial institution has the original of the certificate in the account record
(an account record that has to be read in any case to perform the financial
ttransaction).

The simpler process is to recognize that it is superfulous and redundant to
return a copy of a certificate (appended to every signed message) sent to a
financial institution, a financial insitution that will be reading a record
containing the original of the certificate. Since the master account record with
not only real-time status as well real-time information is being read as part of
executing the operation ... it not only eliminates the extraneous transmission
of appended certificates, eliminates requirements for both CRL & OCSP checking,
minimizes points of failures, and improves availability.

misc. refs:

http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#128
http://www.garlic.com/~lynn/ansiepay.htm#aadsnew2
http://www.garlic.com/~lynn/aepay2.htm#position

mapping of the draft x9.59 financial standard to existing online networks:

http://www.garlic.com/~lynn/8583flow.htm

Tom Strickland <[email-masked]> on 08/23/2000 05:31:12 AM
......

Example: If a company does not have a requirement for current information, a CRL
is sufficient. If a company requires real time data (i.e. a bank or government)
due to high value transactions or security, then I would highly recommend OCSP.
The risk is if you use CRLs for the latter, the company may get a false sense of
security believing their "high value" transactions are guarded by real time
data. If the batch CRL is latent, you may continue processing utilizing old
data. The risk is a cert believed to be revoked may still be considered good in
the system exposing the company to potential fraud or negligence.

In an OCSP environment, if you must trust real time data and someone executes a
DoS attack, the responder may slow down or worst case, stop working. This is an
added value because I would rather slow down or stop processing than to rely on
old data. The risk here is slower response time but guaranteed accurate
information.

---

From: [email-masked]
Date: Thu, 24 Aug 2000 07:19:17 -0400

The certificate used by the President was signed by the ACES CA.  ACES is a
GSA-sponsored governmentwide pki capability that includes the issuance of
certificates under a Certificate Policy developed by the General Services
Administration, Office of Governmentwide Policy.  We do have a copy of the
electronically signed bill and the signature can be verified.  It is not
available on line at this time, but it should be made available in the next
few weeks.  Ditto the certificate used by the President.  I will let you
know when it is available.

Judy Spencer
Office of Information Security
General Services Administration

"Mathew Butler" <[email-masked]> on 08/23/2000 02:25:42 PM

To:   "[email-masked]'" <[email-masked]>,
      [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked]

by [whoever has the power to make the designation, be it Congress or the

Thanks!

-Mat Butler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 9:55 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

Judy Spencer

Bill Flanigan

-----Original Message-----
From: Philip Hallam-Baker [mailto:[email-masked]]
Sent: Tuesday, August 22, 2000 9:08 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: President Clinton digital signing

[snip]

              Phill