Re: [perpass] draft-tschofenig-iab-webpki-evolution-00

Some comments:

Paragraph1:

It should be noted that in the DigiNotar case the breach was not discovered
for several weeks and not reported after discovery and due to the nature of
the breach revocation was not possible. In the Comodo case the mis-issue
was discovered within minutes and the certificates revoked.

This is a very important point to raise since the next paragraph is
conculsory, "The main problem, however, is
   that any CA can issue a certificate for any domain name."

1) one could make a very good argument that the main problem is that the
browsers don't implement revocation reliably.

2) CAA has already been created to address this problem. If that was the
'main' problem it would be solved. Unfortunately it isn't.

The 'EFF 600' number is unfortunately a XXX and I use the term advisedly.
They have accepted that they are mis-measuring the number of CAs but they
continue to insist on a number they admit they can't support. Please do not
present Fox News figures in what is meant to be a serious report. I regret
that I have to use the word 'XXX' here but when a falsehood is presented
and then insisted on after being proven untrue, what other description is
there?

The EFF study conflates all intermediate certs whose subject name is
different to the issuer with cross certificates to a CA. In practice 300+
of the certificates they identify as 'CA certificates' are issued by a
single CA and none are CA certificates. We have had exhaustive discussion
of the issue and no correction from the EFF unfortunately.

The fact that they can't measure what they would like to measure from the
certificate graph does not mean that they can measure it wrongly in a
fashion that inflates it by a factor of ten and present that figure and
assert that it is up to others to supply a better figure.

The principal problem with Sovereign keys is that it simplifies the trust
management problem by assuming that no network manager will ever make a
mistake. If they make one mistake they will lose control of their domain in
perpetuity. Nobody is ever going to take responsibility for deploying such
a scheme on ebay.com or the like.

I think that you miss the point of CT which is that Transparency is the
principle that the CA can be audited by any party without access to hidden
knowledge. That is a groundbreaking concept in trust infrastructure.

What the client checks is proof that the certificate was entered into the
log, not the log itself. That is an important but subtle point.

On DANE among the risks that have to be considered is that there is only
one provider of PKI services in DANE. Thus if that provider decides to deny
access to a party they have no recourse. Hence the Russian interest in GOST
etc. Whether or not you accept that scenario, the folk who do accept it are
willing to fracture the Internet over it.

On Tue, Oct 22, 2013 at 2:48 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> one item that predates the pervasive surveillance debate is the discussion
> about improving the public key infrastructure (but still has relevance in
> this discussion, see https://www.net-security.org/**secworld.php?id=15579<https://www.net-security.org/secworld.php?id=15579>
> ).
>
> Following the workshop at NIST earlier this year the IAB and ISOC have
> been reaching out to different players (and are still doing that) to
> continue the conversation.
>
> We have put together a first document that describes the different
> proposals (and as you can see the level of detail available for them and
> their maturity varies greately). Here is the writeup:
> http://tools.ietf.org/html/**draft-tschofenig-iab-webpki-**evolution-00<http://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-00>
>
> The analysis is still a bit weak and requires more work but the proposals
> are hopefully captured accurately. Let us know whether there is something
> missing.
>
> We hope that this could help to create move momentum behind certain
> proposals to get them accepted by the community and widely deployed.
>
> Ciao
> Hannes
> ______________________________**_________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>

-- 
Website: http://hallambaker.com/