Subject: Re: Comments on draft-ietf-pkix-tac-00.txt

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 1 Jul 2008 12:02:25 +0200

Steve,

It looks like the main motivation is to (finally) find an application for the split key and blind signing mechanism. 
:-)
The crypto security should be not the central point. 

There is no way proposed in the draft so that a RP can know that the split key and blind signing aspects occurred or not.

If the draft goes along, I would see the place for two schemes:

a) a simpler scheme without the split key and blind signing aspects of the design, 
b) a more complex scheme with the split key and blind signing aspects of the design.

Scheme a) is simpler to implement. 

In any case, the RP should be able to know which scheme was used, keeping in mind the limitation: 
the CA could lie in any case.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : denis.pinkas 
Date : 2008-06-30, 19:43:58
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

Denis,
..
Denis :  in the above exchanges, the RA does not know the pseudonym. The mapping is only done using the UserKey.
The threshold signature and blind signature elements are not fundamental.
Sorry that I misread your text, inferring that the RA supplied the pseudonym. Although my comment about the source of the pseudonym wa wrong, it doesn't change my conclusion (see below).

The next part of your proposed redesign is as follows:

If the UserKey is not in the cache of the CA, the request is rejected.
If the pseudonym is not unique, the request is rejected and the CA proposes a different pseudonym.
In that case, the entity makes a second request with the same UserKey. Otherwise the CA contacts the RA
to make sure that the registration information kept by the RA will not be deleted, generates the PKC
and sends it back to the entity.

In that case, the CA maintains a database which contains:

- the UserKey chosen by the RA,
- the PKC issued to the entity.

In the design you propose, the CA issued the cert to the user by itself (from a crypto perspective), which undermines the two-party issuance model in the I-D. The split signing key procedure described in the I-D requires that the RA also sign the hash of the cert, which prevents the CA from acting unilaterally (which would yield a non-traceable cert). Having both the CA and RA sign the cert yields a stronger system, and the blind signature by the CA is needed to enable the split key signing without disclosing the hash value to the RA.

So, unless one wants to weaken the guarantees provided by the two-party signing, I think the split key and blind signing aspects of the design need to be retained.  Also, as I noted earlier given the split key and blind signature aspects of the design in the I-D, the terms AI and BI are appropriate.

I agree that if one did not want to have the crypto security offered by the split key approach (which then necessitates the blind signature function), the design here could be simplified. But, my co-authors see this form of crypto security as a central, motivating aspect of the design, so I believe it should remain.  Thanks, though, for your suggestions re inclusion of a time stamp in the Token and the timeout notion to help with garbage collection.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jul 2008 10:01:34 -0400

At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m61A2c5J025564
>
>Steve,
>
>It looks like the main motivation is to (finally) find an 
>application for the split key and blind signing mechanism.
>:-)

I think it's fair to say that these crypto security mechanisms (split 
key signing and blind signatures) offer greater security than what is 
available from relying only on procedural security promises.

>  There is no way proposed in the draft so that a RP can know that 
>the split key and blind signing aspects occurred or not.

True. it is invisible to RPs.

>b) a more complex scheme with the split key and blind signing 

This I-D is targeted as an informational RFC.  As such it is 
describing a proposed design for TACs, one that meets the 
requirements perceived by the (primary) authors. There is room for a 
second informational RFC describing an alternative design, one that 
does not rely on slit key signing and (internal use of blind 
signatures).

Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 1 Jul 2008 16:44:00 +0200

Comments in line.
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-01, 16:01:34
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

Denis: "Greater security invisible to RPs" = no advantage for RPs = no advantage at all.

Denis: I guess that it is still up to the WG to decide whether 
the PKIX WG would sponsor or not this draft.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jul 2008 15:52:18 -0400

>...

I disagree. Many claims made by a CA in a CP or CPS may not be 
externally verifiable by an RP, yet an RP may rely on them.

>the PKIX WG would sponsor or not this draft.

You're right. I did give permission to post this as a PKIX document, 
targeted as an Informational RFC, before getting a sense of the WG on 
this.

So, let me ask now if there are objections to having PKIX adopt this 
as a document. Obviously I am in favor of it, else I would not have 
signed up as a co-author.

Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 2 Jul 2008 14:11:18 +0200

Steve,

In response to your question:

Obviously,  I am NOT in favor of it, since it appears that there is no intent to pass major change controls to the WG.
Authors may submit Informational RFCs without the support of the WG.

Denis

----- Message reçu ----- 
De : owner-ietf-pkix 
À : denis.pinkas 
Date : 2008-07-01, 21:52:18
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

..

I disagree. Many claims made by a CA in a CP or CPS may not be externally verifiable by an RP, yet an RP may rely on them.

You're right. I did give permission to post this as a PKIX document, targeted as an Informational RFC, before getting a sense of the WG on this.

So, let me ask now if there are objections to having PKIX adopt this as a document. Obviously I am in favor of it, else I would not have signed up as a co-author.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Jul 2008 09:41:07 -0400

At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:
>balder-227.proper.com id m62CBX9E005364
>
>Steve,
>
>Obviously,  I am NOT in favor of it, since it appears that there is 
>no intent to pass major change controls to the WG.

Denis,

The authors will abide by the same rules as anyone who submits a 
document to a WG.

Some but not ALL of your suggested design changes were accepted. That 
hardly seems unreasonable at this stage of the discussion. If we 
rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs :-).

Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 3 Jul 2008 08:59:39 +0200

Steve,

You are saying: "Some but not ALL of your suggested design changes were accepted".
The reality is :"Some but not ALL of the suggested design changes were accepted 
by one of the co-authors of the draft".

At this time, the document is not yet a PKIX WG document and 
there is no WG decision about accepting or rejecting any design change at this stage AFAIK.

The last sentence of your response is inappropriate.

Denis
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-02, 15:41:07
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

Denis,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Jul 2008 10:48:12 -0400

At 8:59 AM +0200 7/3/08, Denis Pinkas wrote:
>balder-227.proper.com id m637064w089766
>
>Steve,
>

The KISA authors contacted me immediately after your first message 
and my response. They seem to be comfortable with the changes that I 
agreed were good suggestions, ones that improved the design but did 
not fundamentally alter it.

>change at this stage AFAIK.

As I noted i a prior message, I did give the KISA authors permission 
to post it as a PKIX I-D, without having conducted the poll that I 
had said would be conducted at the PKIX meeting in PHL. That's why I 
initiated a poll earlier this week, in response to your comments.

>  The last sentence of your response is inappropriate.

The last sentence of my response is accurate.  It reflects the fact 
that you, as a member of this WG, have rarely if ever been completely 
satisfied with any WG document and that the WG has, nonetheless, 
achieved consensus on numerous documents that have been published as 
RFCs. It also reflects that fact that in many of these instances, 
your requests for changes to documents have not been supported by 
other WG members, which is why they did not result in changes to the 
documents when they were issued as RFCs.

Steve

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 3 Jul 2008 17:57:17 +0200

Steve,
The last response from your first email is inappropriate and counter-productive. 
You said:
"If we rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs".
The "If" is not appropriate. Any WG member is free to propose changes. 
Then chair persons decide if/when there is concensus.
I have been the co-editor of several RFCs which demonstrates that these RFCs have been published, 
including in this WG: RFC 3161, RFC 3379, RFC 3628, RFC 4043; and in the S/MIME WG :
RFC 3125, RFC 3126, RFC 5126; and also in the CAT WG: RFC 2487.
At this time, there is one response to this poll. 
Let us wait for other opinions on the *technical* aspects.
Denis
----- Message reçu ----- 
De : Stephen Kent 
À : denis.pinkas 
Date : 2008-07-03, 16:48:12
Sujet : Re: Comments on draft-ietf-pkix-tac-00.txt

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Jul 2008 14:02:23 -0400

At 5:57 PM +0200 7/3/08, Denis Pinkas wrote:
>balder-227.proper.com id m63FvkKc036489
>
>Steve,
>

yes, and WG member can propose changes but, I noted in my response, 
you have a history of proposing lots of changes, many of which are 
not incorporated into the documents under discussion.  As WG chair, I 
have received numerous complaints from document editors about the 
amount of time they feel that hey have "wasted" responding to the 
same proposed changes time and time again.

>RFC 3125, RFC 3126, RFC 5126; and also in the CAT WG: RFC 2487.

the fact that these document have been published says nothing about 
your penchant for repeatedly proposing changes that have no support 
from other WG members.

>At this time, there is one response to this poll.

no, there are two. I expressed my support for adopting the document 
as a PKIX work item.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Jul 2008 16:52:03 +0100

Stephen Kent wrote:
> no, there are two. I expressed my support for adopting the document as a 
> PKIX work item.

FWIW, (but without yet having given the I-D a proper read), I do
think that this topic is a good thing for PKIX to take on. The addition
of more privacy-friendly aspects to Internet protocols is a good thing.

Based on a quick scan, I do have two preliminary comments:-

1. This looks more like it ought end up as an experimental RFC (it
currently says informational). Not a big deal, but if anything at
all is meant to be experimental track, this'd be it IMO.

2. I'd have a concern that regardless of the ability of the
protocol presented to help hide identities from PKI components,
lower layers (e.g. IP address logging) might leak identities.
I'm not sure how that would best be handled - at minimum as sec.
cons. text but if the protocol depends on a lack of logging then
its usefulness might be lessened so I'd be interested in knowing
whether the authors have already considered that or not (maybe
I missed it).

At some later stage, if this does progress, I'll give it a proper
read and might well have comments on other aspects of the scheme,
but overall, if PKIX is going to continue to do new work, then
this is just the right kind of thing to be doing.

Regards,
Stephen.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jul 2008 12:30:25 -0400

>all is meant to be experimental track, this'd be it IMO.

fair comment. now that you mention it, experimental does seem more 
appropriate than informational.

>whether the authors have already considered that or not (maybe

good point and widely applicable to what the IETF considers to be 
privacy-preserving technologies. I agree that a discussion of these 
issues should be added to the security considerations section.

>this is just the right kind of thing to be doing.

Thanks,

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 25 Jul 2008 12:03:18 +0100

I admit that I have some concerns with this I-D, but of reasons different from Denis.

What I'm asking myself is whether this I-D is an appropriate response to a real issue. Not the Internet privacy is not an issue, because it is. But as a society of security engineers, we do have a history of over engineering security solutions ending up in no deployment, which we should take into consideration and hopefully learn from.

Sometimes then appropriate response to a threat is the easier to deploy and easier to understand approach, providing reasonable security, rather than the complex fool proof solution.

Against this dual/blind signing architecture stands one where you simply let a CA issue an anonymous certificate on its own and then trust that CA to keep your identity secret.
This would be very much like how PayPal keeps your credit card number from the merchant. They "could" give your details to the merchant, but they don't. At least I trust them to not do that.

Such approach is of course a bit less secure, but is the simpler solution secure enough?
The problem we face as a standards group is that we don't necessarily know that, and we don't get to decide. In the end, this is decided by the market players, the institutions and the governments on the play field.
All we can do is to offer them good solid specifications for what they want to do.

Being adopted as a WG item does not guarantee that it will be published as an RFC, but given the effort put behind this work I do believe that we ought to let this document be developed with the input of this WG. This process has clearly already lead to improvements.

As this document describes a protocol under development aiming at being a functional standard, I do agree with Stephen Farrell that this should be experimental rather than Informational.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 7 juli 2008 18:30
> To: Stephen Farrell
> Cc: ietf-pkix
> Subject: Re: Comments on draft-ietf-pkix-tac-00.txt
>
>