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

[Stefan Santesson <[e-mail]>]

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

> 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.
>>>  
>>>  
>>>  
>> 
>> 
>