Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)

From: [email-masked]
Date: Wed, 5 Feb 2003 08:37:46 -0700

i would claim in order to activate a digital signature, that the user needs
to perform the RA function ... sending a signed message ... nominally
containing a copy of the public key and some other identification
information ... and this needs to be done regardless of whether the private
kye originates with the user or is pushed out to the user. in the pre-push
case,  just because a private key push agency .... also acting as a CA,
happens to pre-push a copy of the certificate prior to the RA function is
an anomoly of the process.

in effect, what binds/activiates the digital signature process is the RA
operation .... not the certificate .... the existance of a certificate is
an implementation anomoly of the overall business process.

my bias has always been that the digital signature binding process is
represented by the binding in the RA process .... independent of any
existance of a certificate used in scenarios for trusted key distribution
for offline environments ... aka the RA binding for the digital signature
proccess is independent of the existance of a certificate as one means of
representing that the RA business process has occured. in my AADS claims,
online metthods of indicating that valid RA process has been satisfied can
be superior to generation of certificates as a representation of a valid RA
business process.

I would claim that the direct equating of certificates to valid digital
signatures contributes to the confusion. the RA binding process is what is
used for establishing the basis for valid digital signatures. certificates
(should be) just one method of representing that such a RA binding business
process has occured.  The confusion isn't that an agency can generate a
private key and a certificate and push both out to the end user .... the
confusion is the automatic acceptance that because a certificate exists ...
it is equivalent to a valid digital signature binding process; the
certificate should be just considered one way of representing  a RA-binding
process having been performaned.

of course, random refs:
http://www.garlic.com/~lynn/index.html#aads

as noted in other recent threads there is sometimes confusion of asymmetric
cryptography with the business processes of information hiding/secrecy and
the business process of digital signature authentication. frequently for
digital signatures, the business process may require that the private key
never be known by anybody (and can only exist in a unique hardware token)
.... while at the same time information hiding/secrecy will require private
keys be escrowed (access to valuable corporate assets only accessable via a
specific private key will mandate escrow for business continuity purposes).
the technology is the same in both business processes .... but there are
different secrecy requirements with regard to the treatment of the private
key.

asymmetric crypto vis-a-vis public key business process ... hiding/secrecy
and authentication/digital signature:
http://www.garlic.com/~lynn/2001g.html#14 Public key newbie question
http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure)
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#78 Does Diffie-Hellman  schema
belong to Public Key schema family?
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using
passwords ?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and
hashing
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry
vs. Government
http://www.garlic.com/~lynn/2003.html#19 Message
(authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003b.html#30 Public key encryption
http://www.garlic.com/~lynn/2003b.html#41 Public key encryption
http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for
use with Outlook

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

[email-masked] on 2/4/2003 7:02 pm wrote:

Olaf,

><SNIP>
>
>In Germany the german signature law is identifying a fourth case:
>
>4. the cert is in the repository, but not active yet (cert invalid, maybe
>valid in the future)
>
>This case is required (by law) if a CA issues not only certificates but
>private keys as well to the end user. Think of a bank producing and
>delivering a smartcard with keys and certificates on it to you. As long as
>you did not confirm the receipt of the card to the CA the CA must protect
>you by having the certificate "on hold" so during transport no valid
>signatures can be created. This may be handled by an "onHold" status on a
>CRL but is currently deployed in Germany using white list technology.

This seems an unnecessary complication. The CA could simply wait to
post the cert to a directory until the user acknowledges receipt.
I'm not in favor of adding complexity when there are other, simpler
solutions to a problem.

>The second reason why german electronic signature technology is requiring
a
>white list check is another obligation by law, namely that it is not
>allowed to render correctly issued user certificates invalid due to a CA
>key compromise (or any other kind of CA ceases operation). This is again
>achieved with white list technology and status information signed by a key
>with independent security. RTCS would fit well in here.

My response to Simon addresses this issue, i.e., German law seems to
have mandated a solution to a problem that is not technically
justified, given the alternatives. PKIX is not in the habit of
setting standards to accommodate national level laws that may be ill
advised.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 10 Feb 2003 16:03:20 +1300

[Apologies for the late reply, I've got a large pile of conference papers to
 work through]

[email-masked] writes:

>The main difference between RTCS and standard OCSP is that RTCS is answering
>a different question and thus is providing different information. It is a
>white list check and a black list check. It answers the question "Is this
>certificate issued correctly AND not revoked ?"

I want to emphasise yet again that it does this purely because that's all that
an authenticated dictionary is capable of.  This is not a Conspiracy to
Undermine PKIX or a Communist Plot to Annoy Denis, it works that way because
that's all the technology allows - if you're running queries straight from a
live CA store (or more likely a snapshot thereof), all you can say is
"present" or "not present".  The converse holds from a CRL-based source.

>The debate will probably continue on the topic "Do we really need a white
>list check?". In the common PKIX (and X.509) paradigm "CA key security is
>perfect" the answer probably is "no".  A certificate carrying a signature of
>a trusted CA is valid, no need to ask the CA again.

I wasn't really that concerned with CA key compromise (if that happens in an
X.509 PKI, you're pretty much screwed no matter what), but more with things
like manufactured-cert and -CRL attacks.  This is fairly simple with most
widely-used PKI software:

- Implicit universal cross-certification in MSIE/Netscape/CryptoAPI/etc means
  any CA can issue certs claiming to be from any other CA.  Since the other CA
  never issued them (it doesn't even know that they exist), they can't be
  invalidated via a CRL.

- In practice it's even easier than that.  From the NANOG list:

   It's even worse, a fake certificate from a man in the middle causes a
   trustworthy warning! If a certificate is not co-signed by any of the
   Browser compiled-in authorities, the Browsers will just ask: "...do you
   want to trust <company>". The hacker is completely free to fill in
   <company> when he creates his own certificate on the server side (using
   plain openssl). This will be the only popup as the fake certificate will
   match the faked URL.

   Did M$ expect people to say "no" to the fake question "Do you want to trust
   Citibank" when they are in fact trying to connect to the real Citibank
   site? The default behavior of a browser should be to reject unsigned
   certificates and not even ask the question. Currently, there is even no
   warning that <company> was learned from an unsigned certificate.

- Someone else (who probably doesn't want his name dragged into this) has
  pointed out that this can be extended, via section 4.2.1.14 of RFC 3280,
  into a manufactured-CRL attack in which you can revoke any arbitrary cert
  (including the other CA's root).

These are attacks that RTCS will help with, not specifically CA key compromise
(or sale to a third party, which is a far more common occurrence).

>In Germany the german signature law [...]

I ploughed through the exact text for this on the weekend.  By coincidence the
status values appear to be identical to the RTCS ones.  I'd never read that
text until a few days ago, so RTCS was no attempt to copy the German law
requirements.

Peter.