Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt

From: "Pope, Nick" <[email-masked]>
Date: Thu, 17 Sep 2009 13:05:45 +0100

Peter,

This makes a judgement to say that there are definitely no risks and we are
only doing this because some (implied "stupid") government agencies consider
there is.

Um... that will go down well.

I would not agree that we could state categorically that this has no
purpose.  The paper presented at ACNS 2005:
 http://www.springerlink.com/content/y6ck2w9b857kew6c/
(unfortunately only the first page is available for free download)
has lead to suggestions that there is a need to protect the public key
certificate as cannot guarantee the public key given a private key.

Nick

> -----Original Message-----
> From: Peter Gutmann [mailto:[email-masked]]
> Sent: 17 September 2009 11:11
> To: Stefan Santesson
> Cc: Pope, Nick; [email-masked] '; 'Peter Sylvester '; 'pkix ';
> [email-masked] '
> Subject: Re: [pkix] WGLC draft-ietf-pkix-rfc3161-update-03.txt
> 
> Stefan Santesson <[email-masked]> writes:
> 
> > I think one reason why some governments make requirements like this is
> > because documents like the one we just write is not clear on the reason
> why
> > we add such a feature.
> >
> > There is an increased risk that other governments or organizations
> otherwise
> > will read this new draft and believe that they have to use ESSCertIDv2
> with a
> > strong hash because it is required to mitigate known threats.
> 
> I agree that this is a serious problem, users won't understand the feature
> but
> will mandate it just because it's in the spec.  So if it's really felt
> necessary to add it, why not just add some text that summarises the
> discussion
> on the list, something like "This facility serves no identifiable purpose
> but
> was added because some regulatory agencies may mandate it".  This should
> satisfy both camps, it points out that it doesn't address any identifiable
> threat or issue, but also defines the format for people who want to use it
> anyway.
> 
> Peter.
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".

---

From: Martin Rublik <[email-masked]>
Date: Thu, 17 Sep 2009 14:14:46 +0200

> certificate as cannot guarantee the public key given a private key.

I guess full text can be found here
http://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf

Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 17 Sep 2009 14:26:36 +0200

Nick,

I had a long discussion with Julien (co author of the referenced document)
and neither he could identify a realistic threat unless we introduce a
trusted "bad" CA that can issue trusted certificates with malicious content
(in line with Denis argument)

In our discussion however, conceded also that it is hard to prove that there
will never be a threat, and that we should do the update of ESSCertIDv2.

/Stefan

On 09-09-17 2:05 PM, "Pope, Nick" <[email-masked]> wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Thomas Pornin <[email-masked]>
Date: Thu, 17 Sep 2009 17:54:43 +0200

> http://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf

I can confirm that.

I have not closely followed the issue discueesed here, hence I am
speaking "generally". The core meaning of the article cited above is
that signatures go down, not up. In an X.509 world, when a signature on
a certificate is verified with regards to a public key in a CA
certificate, then it means that if you "trust" the CA public key, then
you can "trust" the contents of the certificate, in the sense of: "the
CA assumes responsibility". It does NOT mean that you found the CA which
issued the certificate, depending on what you mean by 'the CA'. In
"pure" X.509, entities are uniquely identified by their DN, which can be
used to locate all relevant information within the entrails of the
fabled Directory. Due to some practicality issues (namely, the existence
of the Directory appears to be somewhat elusive), PKIX tends to adopt a
slightly skewed view, which should tolerate two distinct entities which
go by the same DN.

Imagine that a certificate is to be validated, and has issuer DN
'CN=CA1'. Now you find a CA certificate, properly validated at the end
of a chain from a trust anchor, and that CA has subject 'CN=CA1', and
the public key in the CA certificate matches the signature on the
certificate which is to be validated. In pure X.509, you are finished at
that point, because there cannot be two distinct but validated CA which
have the same subject DN (conceptually, the trust setting in X.509
includes the assumption that non-malicious CA guarantee the absence of
name collisions). In the more mundane world which PKIX deals with, name
collisions may occur. What the article means is that the cryptographic
signature is not a full protection against name collisions: verification
of the signature does not imply 'ownership' in the exclusive sense of
the term. In X.509, name collisions are avoided procedurally, by
namespace allocation within the Directory; verifiers do not need proof
that a name collision did not occur. In PKIX, name collisions are just
assumed to be possible; consequences of a name collision must then be
explored.

A consequence is a discrepancy between the definition of the revocation
status (a certificate is revoked if _the_ issuing CA says so) and what
is cryptographically proven from the verifier point of view (I found a
path and a CRL where _a_ CA seems to assume issuer role, and asserts a
given revocation status). One cannot then attach a simple boolean flag
"revoked / not revoked" to a given certificate: although the certificate
has, procedurally, a well-defined revocation status, that status is not
fully verifiable by external entities. Instead, verifiers must keep the
information as "I have a valid path which asserts the status", which is
not exclusive of other paths which would assert a distinct status.

Now, if the signed data includes the public key of the "true" signer (or
a hash thereof), then you get some additional properties, which are not
easy to describe (many details, hence many hidden devils). This is a
reason why the KCDSA algorithm (the Korean DSA "competitor") has
provision for such an inclusion. This also impacts CMS and its ilk, with
the "Signing Certificate" signed attribute. I have no definitive answer
on that matter, I just know that it is more tricky than it seems.

Also, there probably are amusing things that you can do with inheritence
of DSA parameters. You can take an existing certificate with parameter
inheritence (the public key in the certificate contains only y, not p, q
and g, which are copied from the DSA public key of the CA), then create
a DSA 'public key' such that the signature on the certificate is
verified, and the _implied_ user public key verifies a signature on a
message of your own choice. Which means that having _the_ certificate is
no proof that you have _the_ corresponding public key.

(To some extent, this should apply to ECDSA as well, although only if
using the "explicit EC domain parameters" which are defined in X9.62
but apparently shunned by PKIX [see RFC 5480, section 2.1.1].)

	--Thomas Pornin