Subject: Re: WG Last Call on draft-ietf-pkix-tac-03

From: Stefan Santesson <[email-masked]>
Date: Mon, 04 May 2009 13:46:25 +0200

Before closing this WGLC.

I have not seen any reply to David Copper¹s comment as part of this WGLC.
I think this model is a valid alternative.

Does the authors intend to make a response?

I would also like to add the following comments:

1) The term ³Anonymous Issuer².
I believe that I proposed this term to be changed to ³Anonymity Issuer² and
that this proposal was accepted. ³Anonymous Issuer² may fool the reader to
believe that the issuer is anonymous which is not the case.

2) Short version flow description
This is just a suggestion to the authors to increase the readability of the
document.
I would suggest that the document was rearranged slightly to first provide a
short description if the certificate issuance and name recovery flows
without any juicy technical details. Then I would provide the technical
details of each step in a following section. This would make it a lot easier
and faster to understand the basic architecture.

3) Nit from section 5.1 step 4
The following text is a bit confusing
"Token is the value of the certificate request"

A reader may misunderstand this to mean that the certificate request IS the
token.
The token is carried in the certificate request, which is slightly
different.

4) Conceptual question
I have another conceptual question.

Wouldn¹t it be possible to achieve the same anonymity assurance without
doing the blind signature (step 4-5).
This is also the question using Stephen¹s and David¹s altered model.

The AI already knows that the request is genuine because the user provides a
valid token. 
The AI can now issue an anonymous certificate that is unknown to BI. In case
of problems, AI releases the token that can be sent to BI for identification
of the user.

What extra level of assurance for anonymity is given to the user by the
threshold signature scheme?

I can see that it prevents AI from issuing certificates on its own, and thus
is an assurance that there actually exist a BI record that the BI will honor
in case of problems, but if AI was trusted to only issue valid certificates
based on valid tokens, then what is the gain?

The follow up question is: If there as a reasonable mode where this protocol
can be used without deploying the threshold signature scheme, then wouldn¹t
it be valid to describe that as an optional scenario within which the basic
protocol can be used?

/Stefan

On 09-04-03 4:27 PM, "David A. Cooper" <[email-masked]> wrote:

> I think that Stephen makes a great point.  Stephen's point is that in many
> cases it is possible to learn someone's true identity even if one is only
> provided the IP address from which the person was communicating.  So, it would
> not matter that the TAC protocol does not provide the AI with any identity
> information.
> 
> I also do not agree that the TAC cannot be sent directly from the BI to the
> user.  The protocol could be reworked to address Stephen's concern.  The basic
> idea for the protocol would be as follows:
> 
> step 1: The user creates a certificate request message and encrypts it with a
> session key, which is in turn encrypted using the AI's public key.
> 
> step 2: The user authenticates to the BI and provides the BI with the
> encrypted certificate request message.
> 
> step 3: The BI creates a Token for the user and sends the Token and the
> encrypted certificate request message to the AI over a channel that is
> protected using two-way authenticated TLS.
> 
> step 4: The AI decrypts the certificate request message and creates the
> TBSCertificate.
> 
> (If it is considered necessary): steps 5 and 6:  The AI and the BI jointly
> sign the TBSCertificate using the blinded, split signature scheme.
> 
> step 7: The AI encrypts the signed certificate (TAC) using the session key
> that was created by the user in step 1 and sends the encrypted TAC and the
> Token to the BI.
> 
> step 8: The BI sends the encrypted TAC to the user.
> 
> [Note that to maximize privacy, the encrypted certificate request message and
> the encrypted TAC could both be padded to a fixed length to ensure that the BI
> could not learn anything from the lengths of these messages.]
> 
> I wrote out this protocol fairly quickly, so I may not have gotten all of the
> details correct, but I think the basic idea is correct.  It seems to retain
> all of the properties of the current protocol while also helping to address
> the flaw that Stephen identified.
> 
> Dave
> 
> SangHwan Park wrote:
>>        
>>  
>> 
>> Dear Stephen,
>>  
>>  
>>  
>> Thank you for the comments.
>>  
>>  
>>  
>> I¹ve included my responses inline below.
>>  
>>  
>>  
>>> > A couple of comments:
>>  
>>  
>>  
>>> >#1: Top of p7:
>>  
>>> >  "To effect issuance of the TAC, the AI interacts with
>>  
>>> >   the BI, over a secure channel, to jointly create the signature on
>>  
>>> >   the TAC, and sends the signed TAC to the user.
>>  
>>> > 
>>  
>>> >   The AI does this without learning the user's real identity
>>  
>>> >   (either from the user or from the BI)."
>>  
>>> > 
>>  
>>> >If the AI sends the TAC to the user, then it will know some
>>  
>>> >form of identity for that user, even if that's only an IP
>>  
>>> >address. (And with the likes of SAVI, that could well be
>>  
>>> >enough to establish a real identity.)
>>  
>>> > 
>>  
>>> >I'd have thought it'd be much better to return the TAC
>>  
>>> >via the BI and not require any user<->AI direct connections?
>>  
>>  
>>  
>> According to the concept of separation of CA authorities in this document, BI
>> only identify user¹s real identity and AI only issue TAC with the help of BI
>> without disclosing user¹s real identity. As you suggested if we allow BI to
>> send TAC to users not from AI, BI can trace user¹s real identity
>> unilaterally. It means it is against our concept. And AI can¹t trace their
>> real identity with IP address alone, collected in the issuance process
>> because AI does not have any identity information for users. For this reason,
>> it makes sense to require AI to send TAC to users.
>>  
>>  
>>  
> 
>

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 04 May 2009 15:30:43 +0200

Stefan Santesson wrote:
> *) The term “Anonymous Issuer”.
> *I believe that I proposed this term to be changed to “Anonymity Issuer”
> and that this proposal was accepted. “Anonymous Issuer” may fool the
> reader to believe that the issuer is anonymous which is not the case.

Both sound a bit strange to me.

Wouldn't "Anonymising Issuer" be the term that's already in usage in 
similar scheme ?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 May 2009 09:42:15 -0400

At 10:27 AM -0400 4/3/09, David A. Cooper wrote:
>I think that Stephen makes a great point. Stephen's point is that in 
>many cases it is possible to learn someone's true identity even if 
>one is only provided the IP address from which the person was 
>communicating. So, it would not matter that the TAC protocol does 
>not provide the AI with any identity information.
>
>I also do not agree that the TAC cannot be sent directly from the BI 
>to the user. The protocol could be reworked to address Stephen's 
>concern. The basic idea for the protocol would be as follows:
>
>step 1: The user creates a certificate request message and encrypts 
>it with a session key, which is in turn encrypted using the AI's 
>public key.
>
>step 2: The user authenticates to the BI and provides the BI with 
>the encrypted certificate request message.
>
>step 3: The BI creates a Token for the user and sends the Token and 
>the encrypted certificate request message to the AI over a channel 
>that is protected using two-way authenticated TLS.
>
>step 4: The AI decrypts the certificate request message and creates 
>the TBSCertificate.
>
>(If it is considered necessary): steps 5 and 6: The AI and the BI 
>jointly sign the TBSCertificate using the blinded, split signature 
>scheme.
>
>step 7: The AI encrypts the signed certificate (TAC) using the 
>session key that was created by the user in step 1 and sends the 
>encrypted TAC and the Token to the BI.
>
>[Note that to maximize privacy, the encrypted certificate request 
>message and the encrypted TAC could both be padded to a fixed length 
>to ensure that the BI could not learn anything from the lengths of 
>these messages.]
>
>I wrote out this protocol fairly quickly, so I may not have gotten 
>all of the details correct, but I think the basic idea is correct. 
>It seems to retain all of the properties of the current protocol 
>while also helping to address the flaw that Stephen identified.

Dave,

The "flaw" that Stehen cited is already addressed in the Security 
Considerations text, in a more general context, e.g., the same issue 
arises when a user contacts a web site using a TAC. We're not going 
to mitigate that concern by changing the TAC model as you suggest 
above.

The WG needs to decide if it is worthwhile asking the authors to 
re-design the model and the protocols for this (minor) benefit. I for 
one am not convinced that the additional work and delay is worthwhile.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 13 May 2009 19:44:55 +0200

We had some traffic on this draft, but I could see no reply to my questions
below.

On 09-05-04 1:46 PM, "Stefan Santesson" <[email-masked]> wrote:

> short description if the certificate issuance and name recovery flows without
> any juicy technical details. Then I would provide the technical details of
> each step in a following section. This would make it a lot easier and faster
> to understand the basic architecture.
> 
> The token is carried in the certificate request, which is slightly different.
> 
> 4) Conceptual question
> Wouldn¹t it be possible to achieve the same anonymity assurance without doing
> the blind signature (step 4-5).
> can be used without deploying the threshold signature scheme, then wouldn¹t it
> be valid to describe that as an optional scenario within which the basic
> protocol can be used?
> 
> /Stefan
> 
> 
> 
>> provided the IP address from which the person was communicating.  So, it
>> would not matter that the TAC protocol does not provide the AI with any
>> identity information.
>> 
>> user.  The protocol could be reworked to address Stephen's concern.  The
>> basic idea for the protocol would be as follows:
>> 
>> the encrypted TAC could both be padded to a fixed length to ensure that the
>> BI could not learn anything from the lengths of these messages.]
>> 
>>> According to the concept of separation of CA authorities in this document,
>>> BI only identify user¹s real identity and AI only issue TAC with the help of
>>> BI without disclosing user¹s real identity. As you suggested if we allow BI
>>> to send TAC to users not from AI, BI can trace user¹s real identity
>>> because AI does not have any identity information for users. For this
>>> reason, it makes sense to require AI to send TAC to users.
>>>  
>>>  
>>>  
>> 
>> 
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 May 2009 15:27:18 -0400

Stefan,

Here are my responses to your (repeated) questions:

>I have not seen any reply to David Copper's comment as part of this WGLC.
>1) The term "Anonymous Issuer".
>I believe that I proposed this term to be changed to "Anonymity 
>Issuer" and that this proposal was accepted. "Anonymous Issuer" may 
>fool the reader to believe that the issuer is anonymous which is not 
>the case.

I think Jean-Marc's suggestion "Anonymizing Issuer" is even more 
descriptive. I think we can make that change, if my co-authors do not 
object.

>This is just a suggestion to the authors to increase the readability 
>of the document.
>I would suggest that the document was rearranged slightly to first 
>provide a short description if the certificate issuance and name 
>recovery flows without any juicy technical details. Then I would 
>provide the technical details of each step in a following section. 
>This would make it a lot easier and faster to understand the basic 
>architecture.

I agree that this would make the document more readable.  We can add 
such text as part of the intro.

>A reader may misunderstand this to mean that the certificate request 
>IS the token.

Good point, we can edit the text to avoid this confusing statement.

>Wouldn't it be possible to achieve the same anonymity assurance 
>without doing the blind signature (step 4-5).
>This is also the question using Stephen's and David's altered model.
>
>The AI already knows that the request is genuine because the user 
>provides a valid token.
>The AI can now issue an anonymous certificate that is unknown to BI. 
>In case of problems, AI releases the token that can be sent to BI 
>for identification of the user.
>
>What extra level of assurance for anonymity is given to the user by 
>the threshold signature scheme?
>
>I can see that it prevents AI from issuing certificates on its own, 
>and thus is an assurance that there actually exist a BI record that 
>the BI will honor in case of problems, but if AI was trusted to only 
>issue valid certificates based on valid tokens, then what is the 
>gain?
>
>The follow up question is: If there as a reasonable mode where this 
>protocol can be used without deploying the threshold signature 
>scheme, then wouldn't it be valid to describe that as an optional 
>scenario within which the basic protocol can be used?

The use of a split signature scheme contributes to the argument that 
the TAC CA is taking precautions to help preserve user anonymity in 
the issuance process. The use of this mechanism is not directly 
visible to the user, as you and others ave noted. However, in many 
contexts, a CA operating a TAC service may need to satisfy 
accreditors that it is providing this service in a trustworthy 
fashion. This is what motivated the KISA folks, who perform 
assessments of CAs in their country, to call for use of the 
split-signing approach. Thus the use of split-signing is not an 
arbitrary, academic proposal, but rather is motivated by the 
experience of a group of folks who perform CA evaluations and who 
want to have an RFC that they can cite as the basis for their 
evaluations of TAC CAs.  I think we should defer to their experience 
as CA evaluators in this instance.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 May 2009 22:19:05 +0100

Stephen Kent wrote:
>> *4) Conceptual question
>> *I have another conceptual question.
>>

Well, I think there may be a few ways to go at it that differ
from the current draft. My concern was more with the communications
paths used rather than an objection to the use of the threshold
scheme.

>> In case of problems, AI releases the token that can be sent to BI for
>> identification of the user.
>>
>> issue valid certificates based on valid tokens, then what is the gain?
>> protocol can be used without deploying the threshold signature scheme,
>> then wouldn't it be valid to describe that as an optional scenario
>> within which the basic protocol can be used?
> 
> The use of a split signature scheme contributes to the argument that the
> TAC CA is taking precautions to help preserve user anonymity in the
> issuance process. 

I'm not sure I follow that - how does the scheme show the CA is taking
precautions? The entities involved could still collude regardless of the
scheme, or could honestly not collude even if no threshold scheme were
used.

> The use of this mechanism is not directly visible to
> the user, as you and others ave noted. However, in many contexts, a CA
> operating a TAC service may need to satisfy accreditors that it is
> providing this service in a trustworthy fashion. This is what motivated
> the KISA folks, who perform assessments of CAs in their country, to call
> for use of the split-signing approach. Thus the use of split-signing is
> not an arbitrary, academic proposal, but rather is motivated by the
> experience of a group of folks who perform CA evaluations and who want
> to have an RFC that they can cite as the basis for their evaluations of
> TAC CAs.  I think we should defer to their experience as CA evaluators
> in this instance.

Deference? In the IETF? That's optimistic. ;-)

However, since this is aimed at experimental I'd be fine if some
text were added that pointed out the alternatives and the differences
between the various flows. That way, the issue could be revisited
if/when the spec were put on the standards track.

S.

---

From: Stephen Kent <[email-masked]>
Date: Sat, 23 May 2009 10:37:45 -0400

A
>...

But, your suggestion of direct communication only between the BI and 
the user causes the problems I noted, unless we add the encryption 
mechanism suggested by David Cooper, which itself is an example of 
added complexity :-)

>...

It is true that an honest TAC CA could do all of this even without 
the AI/BI split. That's not the issue. The motivation for having the 
AI/BI split is to make it easier to show to a third party (and to 
convince prospective users) that IF the TAC CA operates as described, 
then it is providing the conditional anonymity indicated. The details 
here are ones that a TAC CA would cite in its CPS. The split signing 
and threshold signature mechanism are ones that, if implemented 
properly, provide reasonable assurance of the desired separation. An 
auditor or evaluator of a TAC CA can verify that these mechanisms are 
being used, as part of an assessment.

The value of a document like this is that it provides those who 
perform audits (assessments, evaluations, ...) a guideline against 
which to measure a CA. This is analogous to what we did with RFC 
3647, providing attorneys with a guideline for CP/CPS construction.

>Deference? In the IETF? That's optimistic. ;-)

yes, but it is also reasonable.  we have accorded some level of 
deference to folks who are more expert in a specific area that we 
are, the CP/CPS document and its reliance on lawyers is a good 
example.

>if/when the spec were put on the standards track.

I think my co-authors at KISA have made enough revisions at this 
stage to satisfy comments. If someone wants to write another I-D that 
proposes alternatives, they are free to do so. After all, as you 
noted, this is a document declared to be experimental, so there is no 
harm in having more that one approach.  If we find that one or more 
real CAs offer TAC services and choose to follow the model here, that 
supports this as a viable model.  If no CAs do so, or if they object 
to the model and propose alternatives, that will support the 
contention that other approaches are superior.

Steve