Subject: Re: Certificate suspension

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 24 Jan 2008 10:46:18 +0100

Russ and Todd,

I do not share your opinions.

>The U.S. Treasury does not support suspension mainly due to obvious 
>issues encountered with digital signature related transactions, and 
>future validation of those transactions.  The problem is, if you are 
>willing to honor signatures produced using certificates from an 
>infrastructure that does support suspension, you wind up in the same 
>boat.  It has been a topic of much debate.

At the very begining, I was reluctant to support suspension, but there is no security flaw 
both for authentication and for non repudiation.

In general, if a relying party application does not support suspension, 
then it will treat suspension as (definitively) revoked.

In the case of non repudiation (which mandates the use of either a time-stamping or 
a time-marking mechanism) there is however a slight difference:

 - If the relying party application supports suspension, the (electronic) signature will be considered 
   as (temporary) invalid. In some cases, it MAY try again *at a later time* to gather new revocation 
   information which demonstrate that the electronic signature is *now* valid. These applications 
   may thus know when it is no more necessary to attempt to validate temporary invalid signatures. 

 - If the relying party application does not support suspension, 
   the (electronic) signature will usually be considered as (definitiveley) invalid. 

   However, this class of applications could be designed to support suspension, without supporting 
   the suspension extension. The relying party application MAY attempt to validate at a later time,
   e.g. two or three days later, electronic signatures that were invalid because the signer's certificate 
   was revoked. So they may end up  with the same result, but not necessarilly within the same time frame.

Denis 

>Russ Housley wrote:
 
>> I have said many times that I wish we had deprecated certificate 
>> suspension in RFC 2459 and all of its successors.  As you say, it is 
>> riddled with difficulties, and those have been discussed many times over 
>> the years.
>> 
>> When we were working on RFC 2459 someone from the financial community 
>> argued that it was needed.  So, it was not deprecated.   You can look at 
>> the archives for the recurring discussion.
>> 
>> Russ
>> 
>-- 
>Regards,
>
>Todd E. Johnson

---

From: "Todd E. Johnson" <[email-masked]>
Date: Thu, 24 Jan 2008 17:41:45 -0500

Thanks for the insight.

Personally, I believe it is the "temporary" that is the cause of 
discomfort.  As you already know, the CA is effectively saying "We can 
not guarantee proof of possession of the private key to this end 
entity", and then it is removed without applications ever knowing.  This 
is of course, only by personal experience.

Rather, I would be more comfortable if something like invalidityDate 
were added, only in the form of a date range, so the CA then says "We 
can not guarantee proof of possession of the private key to this end 
entity between the dates of [beginHold] and [endHold].  Further, 
eliminate the ability for the CA to remove the entry from the CRL, but 
allow for replacement in the event it is actually revoked in the future.

I don't feel the CA should not be in the business of suspending a 
certificate to deny access to applications.  I feel that that is more 
the application/authorization responsibility.  (i.e., certificate vs. 
key suspension)

Perhaps this seems a bit like a Rube Goldberg process, but in the end, 
it gives a true technical capability to accept, or outright deny as 
revoked depending on the application/business needs.  That's only my 
opinion though.  And of course, everybody has one ;)

-- 

Regards,

Todd E. Johnson

---

From: "Todd E. Johnson" <[email-masked]>
Date: Thu, 24 Jan 2008 19:04:21 -0500

Hrm...

1,$s/don't feel the CA should not be/don't feel the CA should be/

-- 

Regards,

Todd E. Johnson

---

From: "Bechlaghem, Malek" <[email-masked]>
Date: Sat, 26 Jan 2008 12:57:40 +0400

Hello there,

While I do agree that the semantic of processing a digital signature is
difficult for a relying party when the signer certificate is suspended,
I would like to point out to at least one area where certificate
suspension does have a practical use.

Having been involved in few ID card issuing projects worldwide, my
experience from these is that eID card lifecycle processes tend to be
coupled to certificate lifecycle processes. In other terms, when an ID
card holder suspects that his card is lost or stolen, we call a helpdesk
that suspend his ID card for a defined period of time. This results in
the card certificates revoked with status on-hold (i.e. suspended). If
the guy founds his card, he calls the same helpdesk that will activate
his card back which results in his certificates un-suspended.

This is at least one practical use of using certificate
suspension-unsuspension. As for the relying-party application, it shall
be developed according so that it interprets the certificate on-hold
status which should not be difficult any way.

Hope this helps.
Regards,
Malek.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Todd E. Johnson
Sent: Friday, January 25, 2008 1:42 AM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: Certificate suspension

Thanks for the insight.

Denis Pinkas wrote:
>  - If the relying party application supports suspension, the
(electronic) signature will be considered 

-- 

Regards,

Todd E. Johnson

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

---

From: Alfredo Esposito <[email-masked]>
Date: Sat, 26 Jan 2008 17:13:54 +0100

The point is the usage of certificate. For authentication purposes,
suspension is fine. If my certificate is suspended "now", "now" I can
not authenticate myself to, say, my workstation. If the purpose is non
repudiation (digital signature has a handwritten signature) the legal
value of a document signed during the suspension period is not trivial
to assess

Bechlaghem, Malek wrote:

Hello there,

Hope this helps.
Regards,
Malek.

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

Thanks for the insight.

Denis Pinkas wrote:

Russ and Todd,

At the very begining, I was reluctant to support suspension, but there

is no security flaw

In general, if a relying party application does not support

suspension,

In the case of non repudiation (which mandates the use of either a

time-stamping or

as (temporary) invalid. In some cases, it MAY try again *at a later

time* to gather new revocation

information which demonstrate that the electronic signature is

*now* valid. These applications

may thus know when it is no more necessary to attempt to validate

temporary invalid signatures.

- If the relying party application does not support suspension,
the (electronic) signature will usually be considered as

(definitiveley) invalid.

However, this class of applications could be designed to support

suspension, without supporting

the suspension extension. The relying party application MAY attempt

to validate at a later time,

e.g. two or three days later, electronic signatures that were

invalid because the signer's certificate

was revoked. So they may end up with the same result, but not

necessarilly within the same time frame.

Denis

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 26 Jan 2008 21:34:15 +0100

Alfredo,
The problem you are referring is relevant regardless if you support certificate suspension or not since a valid certificate may
indeed be in the wrong hands without the legitimate user knowing or having reported it.

Since the majority of signatures these days are performed in on-line scenarios, certificate suspension for signatures and
authentication is essentially the same thing.

Regarding legality the fact is that people are actually convicted based on IP address associations and e-mail addresses.

The difference between signatures and authentication is that only the latter cannot be revoked which is why authentication remains
the most critical operation regardless of its legal status.

I wouldn't outlaw certificate suspension, it seems appropriate in an on-line world.

thanks
Anders Rundgren

----- Original Message ----- 
From: Alfredo Esposito
To: Bechlaghem, Malek
Cc: Todd E. Johnson ; Denis Pinkas ; [email-masked]
Sent: Saturday, January 26, 2008 17:13
Subject: Re: Certificate suspension

The point is the usage of certificate. For authentication purposes, suspension is fine. If my certificate is suspended "now", "now"
I can not authenticate myself to, say, my workstation. If the purpose is non repudiation (digital signature has a handwritten
signature) the legal value of a document signed during the suspension period is not trivial to assess

Bechlaghem, Malek wrote:
Hello there,

Hope this helps.
Regards,
Malek.

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

Thanks for the insight.

Denis Pinkas wrote:

Russ and Todd,

is no security flaw

suspension,

time-stamping or

(definitiveley) invalid.

Denis

---

From: "Todd E. Johnson" <[email-masked]>
Date: Sat, 26 Jan 2008 17:05:18 -0500

Then there are those signatures which are kept long term, say, one that 
is used to initiate a financial instruction after proper validation, and 
authorization, occurs.  The problem in this example is, the signature is 
archived, and may require validation in the future due to an audit, 
litigation, etc.  This may be years depending on the application's 
business requirements, or law.

To be specific, my only issue with supporting suspension are with 
certificates which assert the nonRepudiation bit.

Otherwise, I understand the usefulness of having the ability to suspend 
certificates which assert only the digitalSignature bit.

These can be settled by policy in isolated implementations.  It becomes 
problematic when honoring credentials from other implementations which 
do not align with your policy.

Only subtle changes could be adopted, allowing for respect of the 
current law internationally (which some appear to require suspension) 
maintaining the technical ability to suspend, and the technical ability 
to not honor the credential by a digital signature centric business 
application if desired.

-- 

Regards,

Todd E. Johnson

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 26 Jan 2008 15:35:09 -0800

I have been skim reading this thread for a while.

Please note that suspension does not get in the way of non-repudiation;
it simply increases software complexity on the part of relying parties
trying to sort out time of signature application.

Also, note that there are lots of other issues for preservation of
signatures for long term.  I encourage you to follow the developments of
the IETF LTANS WG for that.  Again, for the long term, with properly
archived revocation information, signature verification in the future
can be securely sorted out using LTANS developed RFCs and I-Ds whether
suspension is used or not.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Todd E. Johnson
Sent: Saturday, January 26, 2008 5:05 PM
To: Anders Rundgren
Cc: Alfredo Esposito; Bechlaghem, Malek; Denis Pinkas; [email-masked]
Subject: Re: Certificate suspension

Anders Rundgren wrote:
> Alfredo,
> The problem you are referring is relevant regardless if you support
certificate suspension or not since a valid certificate may
> Since the majority of signatures these days are performed in on-line
scenarios, certificate suspension for signatures and
> Regarding legality the fact is that people are actually convicted
based on IP address associations and e-mail addresses.
> 
> The difference between signatures and authentication is that only the
latter cannot be revoked which is why authentication remains

-- 

Regards,

Todd E. Johnson

---

From: Stephen Wilson <[email-masked]>
Date: Sun, 27 Jan 2008 12:06:17 +1100

Anders Rundgren wrote:
> Alfredo, The problem you are referring is relevant regardless if you
>  support certificate suspension or not since a valid *certificate*
> [emphasis added] may indeed be in the wrong hands ...

You mean private key I think, not certificate.

> ...  without the legitimate user knowing or having reported it.
> 
> scenarios, certificate suspension for signatures and authentication
> is essentially the same thing.

I disagree with the emphasis on on-line signing.  Even if it
were empirically true, a prevalence of on-line PKI applications is not
reflective of the unique value of PKI -- which is that signatures can be
verified off-line, and retrospectively -- and we should therefore NOT
bake into our standards and conventions any dependence on, or
presumption of, certificates being used on-line.

> based on IP address associations and e-mail addresses.

I agree that we should not over-do "legality" since there are indeed all
sorts of ways to find someone legally liable (or not) for things that
happen electronically.

[BTW the richness of IT forensics is one reason I think that
"non-repudiation" is such a red herring and such an albatross around our
necks (pardon the mixed marine metaphor! And pardon the alliteration!!).

[If I create a digital signature using complex software as part of a
transaction, and there follows some sort of court case, I do not believe
that the outcome will depend much at all on whether the NR bit is
asserted.  A reductio ad absurdum helps underscore the futility of
"non-repudiation": Imagine I make a credit card payment over the
Internet, and then change my mind about the purchase.  I could try to
deny making the payment, and to bolster my case, I could say to a judge
"Look Your Honour, there was no 'non-repudiation' in the transaction
technology, therefore I can repudiate it!".  Fat chance!!  So if the
absence of an NR bit will not help me win the case, the presence of an
NR bit cannot be defining of a legal position either.]

> latter cannot be revoked which is why authentication remains the 
> most critical operation regardless of its legal status.

I don't understand the idea that 'authentication cannot be revoked'.

> I wouldn't outlaw certificate suspension, it seems appropriate in an

If there is any case for a credential being suspended for a period of
time, with the expectation of it being un-suspended, then I say let's
suspend the key, and not worry about the certificate.

Looking at the off-line world of PKI, I remain won over by the argument
that the possibility of a certificate being suspended, and then
re-instated some time later (and then suspended again and reinstated
...) makes it very difficult to take a signature created at some time in
the past and determine from CRLs and delta CRLs whether or not the
certificate was valid at that time.

Another scenario advanced in favour of suspension is when the key owner
has misplaced their key but thinks it might still turn up.  But this
introduces too much wiggle room into Required Revocation.
Conventionally, most Certificate Policies insist that if one even
suspects possible private key compromise, revocation is required.  It
seems to me very difficult to characterise in a Policy any middle ground
that would allow a user some shade of doubt.  Tellingly, you cannot
"suspend" a credit card if it is misplaced (not in Australia at any
rate).  I misplaced a card once, and called my bank to have it put on
hold while I looked for it.  But the operator asked me "Is your card
lost, or is it not?".  There was no middle ground, I had to either
cancel the card, or wear the consequences of it being misused while not
under my control.

I cannot see why digital certificates would ever be any different.

Cheers,

Stephen Wilson.
www.lockstep.com.au.

---

From: Eric Norman <[email-masked]>
Date: Sat, 26 Jan 2008 20:20:20 -0600

On Jan 26, 2008, at 7:06 PM, Stephen Wilson wrote:

>  I could try to
...

>  makes it very difficult to take a signature created at some time in

Since we're talking about court cases here, it's not obvious to me that
the court would even care about whether certificates used for signing
were valid at signing time.  The only things a court might care about
is whether the signer had the *intent* to sign, or the signature was
under duress, or something like that.

I have a suspicion, and hope, that these attempts to design "electronic
justice" result in nothing more than discussions on mailing lists.

Eric Norman

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 Jan 2008 09:53:07 +0200

> under duress, or something like that.

I don't think you can prove duress, no matter how much cryptography or  
certificate policy you throw at it. The only claim that's relevant to  
certificates in court is a claim that "some other dude" signed this  
transaction. As long as I signed it, it makes no difference if the  
certificate is suspended, revoked, expired or in its "not before"  
period.

> justice" result in nothing more than discussions on mailing lists.

Eventually it can be hoped that signatures done with a certificate  
that was already revoked (and deployed in the CRL) should not be  
binding.
Same should go for certificates that were suspended at the time, and  
not subsequently re-enabled.

---

From: Stephen Wilson <[email-masked]>
Date: Mon, 28 Jan 2008 12:19:15 +1100

> justice" result in nothing more than discussions on mailing lists.

I don't know about hoping these discussions go nowhere ;-)

But I agree with the implication that 'designing electronic justice' is 
problematic.  In my view, too many of the PKI-in-court discussions seem 
to be devoid of context.  Famously, Jane Winn years ago lampooned the 
idea of forming contracts on line using digital signatures -- but I 
think she was looking at the special case (the very special case) of 
stranger-to-stranger business.

Certificate subjects tend not to use their keys in a vacuum; when they 
sign things, there is plenty of context apart from their certificate. To 
imagine that a court case might turn on the certificate and private key 
alone I think is utterly academic.

It is better to realise that certificates are always used as part of 
some defined scheme (we should heed the practical experience that all 
most if not all successful individual certificate programs are "closed" 
or vertical).  Certificates are not usually presented to Relying Parties 
by total strangers (and if they are, they should be ignored, just as we 
would tend to ignore an unexpected order sent to us by an unknown party 
on plain paper, even if it is signed by hand).  Instead certificates are 
generally used to automate transactions between parties that either 
already know each other, or else recognise one another's credentials and 
capacity to act in the transaction at hand.  There isn't a lot of 
"serious" use of certificates in vanilla e-mail applications.  Rather, 
"serious" certificates are used in the context of special purpose 
software (e.g. medical software applications, e-conveyancing, government 
forms, trade documentation etc.) or are embedded in dedicated systems 
like smartcards, e-passports, set-top boxes, and Skype.

In these sorts of contexts, I think that when disputes get as far as a 
court, they are usually concerned with much more prosaic matters, like 
product failures, product liability, user interface design, and contracts.

Cheers,

Stephen Wilson
www.lockstep.com.au.