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

[Stefan Santesson <[e-mail]>]

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" <[e-mail]> 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.
>>  
>>  
>>  
> 
>