[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-pkix
Subject: Reply to Jim Schaad's comments on TAC internet draft 00
From: <shpark () kisa ! or ! kr>
Date: 2008-10-13 2:38:12
Message-ID: 200810130237.m9D2bDmj050338 () balder-227 ! proper ! com
[Download RAW message or body]
Dear Jim Schaad and PKIX members,
I embedded the reply to your comments.
You can refer to SANG¡¯s last comments inline to each question.
Thank you.
-------------------
SangHwan Park
Senior Researcher / CISA / CISSP / ITIL
Korea Information Security Agency(KISA)
+82-2-405-5428, shpark@kisa.or.kr
1. What is the time length that TAC certificates are expected to be used
for? Are they onetime certificates, are they supposed to be good for a
short period of time (i.e. months) or are they supposed to be good for
extended periods of time (i.e. years but used infrequently), or all of the
above?
SANG) We do not believe that this document should specify limits on the
duration or frequency with which TACs are used, however they are not
envisioned as one-time certs. It will be up to each TAC CA (BI/AI pair) to
determine the lifetime of the certs it issues, and to advise subjects of
suggested usage guidelines, e.g., via a cert policy. The security
considerations sections says:
... if the user employs
the same TAC for multiple transactions (with the same or
different parties), the transactions can be linked through the
use of the same TAC. Thus the anonymity guarantee is "weak"
even though the user's real identity is still hidden.
To achieve stronger anonymity, a user may acquire multiple
TACs, through distinct iterations of the protocol.
JIM) I understand that you are not specifying the lifetime. That is part
of the problem. If they can be used for a long time, i.e. past the time
that the certificate would "normally" expire or worse past the time that
you have some type of contractual relationship with the BI, then you have a
security problem. Do you renew a current certificate, and how do you
decide if that certificate has been paid for, or do you issue a new
certificate with a new identity and lose any history of the identity with
existing relationships. In one case you are requiring a restart of a
relationship with a partner, in the other case you are potentially leaking
information to either the AI or BI about who you are.
SANG) I understand your point, now that you have provided more comments.
These are topics that the CP and CPS for a TAC would address, but we do not
believe that they need to be dictated by this document. Taking your
comments and concerns into account and we'll revise security consideration,
saying that "if the TAC has a long validity interval, this increases the
probability that the identity of a TAC user will be discovered, e.g., as a
result of linking user transactions across multiple servers. As a result we
recommend that each TAC CA consider carefully how long the validity for a
TAC certificate should be. This document makes no provisions for
certificate renewal or rekey, as a means to encouraging TAC users to
acquire new TACs."
2. Given the ability to potentially link an identity from other information
on the network (i.e. IP addresses), I would like to see some text describing
the types of protocols that TAC certificates should and should not be used
in. For example, it could be used for an anonymous TLS client auth
certificates, but would probably not be as useful for a SIP or S/MIME
certificate. Or maybe you disagree with that. A description of the types
circumstances that these certificates are used in would helpful in trying to
determine if they are both useful and susceptible to other types of attacks.
SANG) This issue was raised in Dublin and as a result we prepared text for
the next rev of the document that addresses the issue you raise here, i.e.,
repeated use of an anonymous credential provides opportunities for linkage.
There is also the potential to determine the true identity of a user by
examining other info outside of what is provided by the cert. Here is the
text we have for the security considerations section, dealing with this
topic.
"It also may be possible to determine the identity of a user via
information carried by lower level protocols, or by other,
application-specific means. For example, the IP address of the
user might be used to identify him/her. An analogous problem
might arise if a user visits a site (and does not conceal
his/her identity), the site deposits a "cookie" into the
user's browser cache, and the user later visits a site and
employs a TAC with the presumption of anonymity. This use
of a TAC is a tool to help a user preserve anonymity, but it
is not, per se, a guarantee of anonymity."
JIM) This text does not address the issue that I raised. Specifically what
type of protocols is this good for, and what type should it not be used for
since more information is available to potentially more people. You have
discussed issues dealing with one specific type of protocol - http/https.
This does not look at other protocols and type of issues that these
protocols raise.
Here is an example, do you believe that a TAC certificate should be used
for sending and receiving e-mail? I think that this raises all sorts of
problem with a store and forward architecture. It is much simpler for
people to obtain information by eavesdropping in this case than it would be
for the case of TLS - especially if you deferred client certificate
validation until after the secure channel has been established.
SANG) The primary role of the TAC is to access web services with anonymity.
We will revise security consideration sections to make this more explicit.
3. I think the document should strongly suggest that indirect CRLs are used
by TAC CAs. This would almost be a requirement for OCSP. The protocol
needs to have a way for a communication to occur between the AI and BI to
allow for signing of CRLs in any event. What is this going to look like.
Does the BI simply trust the AI to hand it a correct hash? Does the AI sign
the CRL, pass it to the BI to finish signing and then verify, does the AI
give the TBS to the BI, have the BI sign it and then return the signature to
the AI to finish signing and publish?
In section 5, the text says that an AI unilaterally manages the CRL for a
TAC CA:
"If AI determines that there is sufficient
evidence of abuse to trace the TAC to the user, the AI revokes
the TAC, by listing its serial number on the next CRL issued
by the AI.
But the text failed to say how the AI does this. Use of an indirect CRL
may be the simplest approach to address this issue.
Requiring TACs to use indirect CRLS is the simplest way to address this
problem, however rfc5280 implementations are not required to process
indirect CRLs. This means you are going to either specify a protocol to
allow for direct CRLs to be jointly issued, or you are going to be non-
rfc5280 compliant.
SANG) An RP that process indirect CRLs is not non-compliant, but you are
correct in noting that a compliant RP need not process indirect CRLs. Our
proposed resolution for this issue to create a second CA, under the TAC CA,
and have it be the CRL issuer for the EE certificates issued by the TAC CA.
This CA will have the cRLSign bit set in KU, but not the keyCertSign bit.
The private key for this CA will be held by the AI, so that it can issue
CRLs unilaterally. This CA certificate should be long-lived, just like the
TAC CA certificate. It will be the only CA certificate issued under the TAC
CA certificate (and thus it will be signed jointly by the BI and AI). We
will recommend that the CRL for this CA certificate be similarly long-
lived, as it too need to be signed jointly by the BI and AI. The EE TAC
certificates MUST contain a CRLDP that points to the CRL issued by this CA,
to ensure that RPs know to check that CRL vs. the CRL that covers this (the
CRL) CA. Do you agree that this approach meets all the relevant 5280
criteria for what RPs MUST support, and still allows the AI to issue CRLs
for TACs unilaterally?
4. Information should be placed in the document (Security Considerations is
fine) about the financial model associated with this issuing model. All
user financials need to be done with the BI and not the AI, the AI would
have to get compensated by the BI for issued certificates. An associated
item with this is the question of should the BI be able to influence
contents of the certificate, specifically the lifetime of the certificate to
correspond to the money paid.
There is no requirement that the Ai and BI be operated in a financially-
separate fashion, but there also is no prohibition. Your suggestion is a
good one, i.e., adding some text to the security considerations section to
note that IF the AI and BI are financially independent of one another, THEN
the user MUST pay the BI (who already knows the user's true identity), and
the BI will compensate the Ai for each cert it issues. We can probably
leave it to AIs and BIs to coordinate the issue of cert lifetime, for
financial purposes. After all, the management of the CA is a joint matter
for the AI and BI, and we should assume they will be able to work out these
details.
The first issue is that you cannot pay the AI for your certificate. If you
do, then you need to pay with some type of anonymous cash, and you must pay
using a completely anonymous protocol. I don't know of any way to
currently do this except in the realm of academia.
I don't believe that you can leave the issue of things like lifetime out.
Let's say that the BI can allow for issuing of certificates for a period of
three months, one year and five years. The BI would need to communicate
this information as part of the token, or the BI and AI would need to have
an additional conversation before the AI builds the certificate in order to
get this piece of information.
As an alternative, you could have different AI's for different length
certificates. This would imply that the BI cannot directly influence the
contents of the certificate, but would require that the BI tell the user
what the name of the AI to be used to issue the certificate. (Which might
not be a bad idea anyway.)
SANG) I agree with your point. There was no intent to require a user to
employ an anonymous or cash payment system to acquire a TAC. There seem to
be a few options here, as you noted. If the TAC CA issues certificates with
only one duration, this problem does not arise. If there are multiple
duration options, then there needs to be a way to signal to the AI which
duration the user has paid for. Having different AI instances (by name) is
one solution to the problem, or the token could be extended to accommodate
your other proposed solution. We will add text to the security
considerations section to suggest that a given TAC CA issued certificates
with only one lifetime, so avoid the complexity that might arise otherwise.
We also will note that if a TAC CA offers certificates of with different
lifetimes, then it will need to communicate this info from the BI to the AI
in a way that does not unduly compromise the anonymity of the user.
5. Renewal/Rekey operations are not covered by this document. Either you
need to state that these operations are never done, or you need to have a
secure method of allowing the operation to be completed. In this case the
Token no longer exists (or at least is no longer valid) and so the AI would
need to prove to the BI that the BI should sign the certificate. One
possible method would be to send the BI the TBSigned of the new certificate
along with the old certificate allowing it to see that it had previously
signed a certificate for subject name. It would still not be traceable back
to the user's Token, but would give assurances that the certificate should
be issued.
SANG) Good point. Renewal/Rekey should NOT be supported. We will revise the
text accordingly.
JIM) This has some implementations for item 1.
SANG) Please refer to the response for item 1.
6. ALREADY RESOLVED
7. Guidance needs to be supplied about how long items are to be kept in the
respective databases. Are these database entries expected to be kept
forever once a certificate has been issued? Or are they only kept for
approximately the life of the certificate. This is really impacted by the
answer to question #5 on rekey/renewal, but has some additional tracing
implications beyond that.
SANG) Since TACs are not suitable for NR (a detail than can be added to the
text), there does not appear to be a need to retain data about TAC certs
beyond their lifetime.
JIM) An aggrieved entity may want to get the identity information about a
signer after the certificate has expired. This implies that there is at
least some minimum duration that the information needs to be kept for
traceability reasons.
SANG) Good point. We'll say that a TAC CA MUST describe in its CP how long
it will retain data about certificates it issued, beyond the lifetime of
these certificates. We also will note your rationale of why such retention
is appropriate. We do not plan to specify a minimum duration for such
retention, as that really is a per-CA matter.
8. ALREADY RESOLVED
9. If you believe that TAC permits both signature and encryption
operations, then you need to address an additional problem. If a DSA
signature certificate and a DH encryption certificate pair are needed, it is
some protocols may require that they contain the same subject name, and thus
would need to be issued at the same time. The current TAC protocol makes no
allowances for the ability to have the BI sign two independent certificates
at the same time. This could be done by allowing the protocol to present
multiple blinded hashes to the BI to be signed for a single token.
SANG) The primary focus of the TAC work has been web access. For that, a
single cert is enough. But, you make a good point that if one wants to use
TACs with S/MIME, for example, dual cert issuance needs to be supported.
For now, we will stick with single cert issuance, with it's implied
limitations.
JIM) This needs to be made explicit.
SANG) Please refer to the response for item 2.
10. ALREADY RESOLVED
11. In section 5.1 Step 2, the statement is made that a TLS certificate
should be used for doing the signature operation on a CMS object. You might
want to rethink this statement. While there is nothing technically wrong
with this, some CMS validators would reject the signature since the EKU
would not be correct.
Does CMS specify a set of EKUs that are acceptable for any use of CMS, or
are you saying that the presence of any EKU associated with TLS use might
cause rejection because software (e.g., OpenSSL) has some non-standard
restrictions embedded in it?
JIM) If there is an EKU in the certificate, and it is not one of the
"acceptable" EKUs for CMS, it is possible that some implementations might
reject the certificate. This is highly dependent on the implementation. I
don't know if this is a problem, but it potentially could be. One
possible solution would be to create an EKU specifically for this operation.
SANG) Sorry for this misunderstanding with regard to TLS certificates. In
section 5.1 Step 2, a TLS certificate is used only for security channel
establishment, not for verifying a signature on a CMS object. See the end
of section 5.1 Step 1, cited below. Does the following text address your
concern?
"It is RECOMMENDED that the UserKey be a random or pseudo-random value.
Whenever the BI passes a UserKey to an external party, or accepts the
UserKey from an external party
(e.g., the AI), the value is embedded in digitally signed CMS object called
a
Token, accompanied by the time stamp noted above. The signature on a
Token is generated by
the BI using a private key employed only for this purpose."
12. ALREADY RESOLVED
13. I would like to see for each of the steps in 5.1, an explanation of who
needs to be protected against for the communication. This will better allow
others to decide on how to implement this with non-TLS communications. For
example, could this be done with e-mail or are the security requirements not
met?
Not sure what you mean by "who needs to be protected against for the
communication." We can explain in more detail what security features are
required at each step, but there is already some text addressing this, for
at least some steps. For example, in step 2, the document says:
"The secure channel is required here to prevent a wiretapper from
being able to acquire the Token. For example, if the user
establishes a one-way authenticated TLS session to the BI in
Step 1, this session could be used to pass the Token back to
the user."
There are cases where you need to explicitly prevent either the AI or BI
from getting the information, but may not need to protect against a general
wiretapper. For example, if the client and BI transaction is open (except
to the AI), this may not help an eavesdropper as long as the client/AI
transaction is completely sealed. The eavesdropper would be in same
situation in this case as BI, it knows some information but not enough to
complete the trace without the cooperation of the AI.
SANG) We requested the secure channel in open communications, based on the
information that is valuable from security point of view.
14. ALREADY RESOLVED
15. ALREADY RESOLVED
16. ALREADY RESOLVED
17. In section 5.2, step C - should the BI also conduct its own assessment
of the fact that the aggrieved party's case before releasing the
information?
BI could do so. We can add text to say that is an option, but it would be
something that each TAC CA decides for itself, and declares in its CP and
details in the CPS.
Not requiring this would allow for a rouge AI to get the information. It
would create a pretend aggrieved party, provide the details to that party
and query the BI. The BI doing no checks would hand over the information
no questions asked.
SANG) Fair point. We will change the text to state that BI should conduct
its own assessment of the aggrieved party's case before releasing the user
ID.
18. ALREADY RESOLVED
19. ALREADY RESOLVED
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:st1="urn:schemas-microsoft-com:office:smarttags" \
xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=ks_c_5601-1987">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="State"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PlaceType"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PlaceName"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="place"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="phone"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:¹ÙÅÁ;
panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
{font-family:±¼¸²;
panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
{font-family:"\@±¼¸²";
panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
{font-family:"\@¹ÙÅÁ";
panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
text-align:justify;
text-justify:inter-ideograph;
text-autospace:none;
word-break:break-hangul;
font-size:10.0pt;
font-family:¹ÙÅÁ;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:±¼¸²;
color:windowtext;}
/* Page Definitions */
@page Section1
{size:595.3pt 841.9pt;
margin:99.25pt 3.0cm 3.0cm 3.0cm;
layout-grid:18.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=KO link=blue vlink=purple>
<div class=Section1 style='layout-grid:18.0pt'>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>Dear Jim Schaad and PKIX members,<o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'><o:p> </o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>I embedded the reply to your \
comments.<o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'><o:p> </o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>You can refer to </span></font><b><font size=3 color="#333399"
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt;font-family:
"Times New Roman";color:#333399;font-weight:bold'>SANG¡¯s last comments inline
to each question.</span></font></b><font size=3 color=black
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt;font-family:
"Times New Roman";color:black'><o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'><o:p> </o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>Thank you.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=¹ÙÅÁ><span \
lang=EN-US><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=¹ÙÅÁ><span lang=EN-US \
style='font-size:10.0pt'>-------------------</span><span \
lang=EN-US><o:p></o:p></span></font></p>
<p class=MsoNormal><st1:place w:st="on"><st1:PlaceName w:st="on"><font size=2
face=¹ÙÅÁ><span lang=EN-US \
style='font-size:10.0pt'>SangHwan</span></font></st1:PlaceName><span lang=EN-US> \
<st1:PlaceType w:st="on">Park</st1:PlaceType></span></st1:place><span lang=EN-US> \
<o:p></o:p></span></p>
<p class=MsoNormal><font size=2 face=¹ÙÅÁ><span lang=EN-US \
style='font-size:10.0pt'>Senior Researcher / CISA / CISSP / \
ITIL<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=¹ÙÅÁ><span lang=EN-US \
style='font-size:10.0pt'>Korea Information Security \
Agency(KISA)<o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=2 face=¹ÙÅÁ><span lang=EN-US \
style='font-size: 10.0pt'>+<st1:phone o:ls="trans" phonenumber="8224055428" \
w:st="on">82-2-405-5428</st1:phone>, <a \
href="mailto:shpark@kisa.or.kr">shpark@kisa.or.kr</a></span></font><font size=3 \
color=black face="Times New Roman"><span lang=EN-US style='font-size: \
12.0pt;font-family:"Times New Roman";color:black'><o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'><o:p> </o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>1. What is the time length that TAC certificates are \
expected to be used<br> for? Are they onetime certificates, are they supposed \
to be good for a<br> short period of time (i.e. months) or are they supposed to be \
good for<br> extended periods of time (i.e. years but used infrequently), or all of \
the above?<br>
<br>
<b><span style='font-weight:bold'>SANG) We do not believe that this document
should specify limits on the duration or frequency with which TACs are used,
however they are not envisioned as one-time certs. It will be up to each TAC CA
(BI/AI pair) to determine the lifetime of the certs it issues, and to advise
subjects of suggested usage guidelines, e.g., via a cert policy. The security
considerations sections says:<br>
... if the user employs<br>
the same TAC for multiple transactions (with the same or<br>
different parties), the transactions can be linked through the<br>
use of the same TAC. Thus the anonymity guarantee is
"weak"<br>
even though the user's real identity is still hidden.<br>
To achieve stronger anonymity, a user may acquire multiple<br>
TACs, through distinct iterations of the protocol.<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> JIM) I understand that you are not specifying the \
lifetime. That is part of the problem. If they can be used for a long \
time, i.e. past the time that the certificate would "normally" expire or \
worse past the time that you have some type of contractual relationship with the BI, \
then you have a security problem. Do you renew a current certificate, and how \
do you decide if that certificate has been paid for, or do you issue a new \
certificate with a new identity and lose any history of the identity with existing
relationships. In one case you are requiring a restart of a relationship
with a partner, in the other case you are potentially leaking information to
either the AI or BI about who you are.<br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) I understand your point, now that you have provided
more comments. These are topics that the CP and CPS for a TAC would address,
but we do not believe that they need to be dictated by this document. Taking
your comments and concerns into account and we'll revise security
consideration, saying that "if the TAC has a long validity interval, this
increases the probability that the identity of a TAC user will be discovered,
e.g., as a result of linking user transactions across multiple servers. As a result
we recommend that each TAC CA consider carefully how long the validity for a
TAC certificate should be. This document makes no provisions for certificate
renewal or rekey, as a means to encouraging TAC users to acquire new
TACs."<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 2. Given the ability to potentially link an \
identity from other information<br>
on the network (i.e. IP addresses), I would like to see some text describing<br>
the types of protocols that TAC certificates should and should not be used<br>
in. For example, it could be used for an anonymous TLS client auth<br>
certificates, but would probably not be as useful for a SIP or S/MIME<br>
certificate. Or maybe you disagree with that. A description of the
types<br>
circumstances that these certificates are used in would helpful in trying to<br>
determine if they are both useful and susceptible to other types of attacks.<br>
<br>
<b><span style='font-weight:bold'>SANG) This issue was raised in Dublin and as
a result we prepared text for the next rev of the document that addresses the
issue you raise here, i.e., repeated use of an anonymous credential provides
opportunities for linkage. There is also the potential to determine the true
identity of a user by examining other info outside of what is provided by the
cert. Here is the text we have for the security considerations section, dealing
with this topic.</span></b></span></font><font size=3 face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman"'><o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><b><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black; font-weight:bold'>"It also may be possible to determine the \
identity of a user via<br>
information carried by lower level protocols, or by other,<br>
application-specific means. For example, the IP address of the<br>
user might be used to identify him/her. An analogous problem<br>
might arise if a user visits a site (and does not conceal<br>
his/her identity), the site deposits a "cookie" into the<br>
user's browser cache, and the user later visits a site and<br>
employs a TAC with the presumption of anonymity. This use<br>
of a TAC is a tool to help a user preserve anonymity, but it<br>
is not, per se, a guarantee of anonymity.</span></font></b><font size=3
color=black face="Times New Roman"><span lang=EN-US style='font-size:12.0pt;
font-family:"Times New Roman";color:black'>"<br>
</span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> JIM) This text does not address the issue that I \
raised. Specifically what type of protocols is this good for, and what type \
should it not be used for since more information is available to potentially more \
people. You have discussed issues dealing with one specific type of protocol -
http/https. This does not look at other protocols and type of issues that
these protocols raise.<br>
Here is an example, do you believe that a TAC certificate should be used
for sending and receiving e-mail? I think that this raises all sorts of
problem with a store and forward architecture. It is much simpler for
people to obtain information by eavesdropping in this case than it would be for
the case of TLS - especially if you deferred client certificate validation
until after the secure channel has been established.<br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) The primary role of the TAC is to access web services
with anonymity. We will revise security consideration sections to make this
more explicit.<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 3. I think the document should strongly suggest \
that indirect CRLs are used<br>
by TAC CAs. This would almost be a requirement for OCSP. The
protocol<br>
needs to have a way for a communication to occur between the AI and BI to<br>
allow for signing of CRLs in any event. What is this going to look like.<br>
Does the BI simply trust the AI to hand it a correct hash? Does the AI
sign<br>
the CRL, pass it to the BI to finish signing and then verify, does the AI<br>
give the TBS to the BI, have the BI sign it and then return the signature to<br>
the AI to finish signing and publish?<br>
<br>
<b><span style='font-weight:bold'>In section 5, the text says that an AI
unilaterally manages the CRL for a TAC CA:<br>
"If AI determines that there is sufficient<br>
evidence of abuse to trace the TAC to the user, the AI revokes<br>
the TAC, by listing its serial number on the next CRL issued<br>
by the AI.<br>
</span></b> <br>
<b><span style='font-weight:bold'>But the text failed to say how the AI does
this. Use of an indirect CRL may be the simplest approach to address this
issue.<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> Requiring TACs to use indirect CRLS is the simplest \
way to address this problem, however rfc5280 implementations are not required to \
process indirect CRLs. This means you are going to either specify a protocol to \
allow for direct CRLs to be jointly issued, or you are going to be non-rfc5280 \
compliant.<br> </span></font><b><font size=3 color="#333399" face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#333399; font-weight:bold'> <br>
SANG) An RP that process indirect CRLs is not non-compliant, but you are
correct in noting that a compliant RP need not process indirect CRLs. Our
proposed resolution for this issue to create a second CA, under the TAC CA, and
have it be the CRL issuer for the EE certificates issued by the TAC CA. This CA
will have the cRLSign bit set in KU, but not the keyCertSign bit. The private
key for this CA will be held by the AI, so that it can issue CRLs unilaterally.
This CA certificate should be long-lived, just like the TAC CA certificate. It
will be the only CA certificate issued under the TAC CA certificate (and thus
it will be signed jointly by the BI and AI). We will recommend that the CRL for
this CA certificate be similarly long-lived, as it too need to be signed
jointly by the BI and AI. The EE TAC certificates MUST contain a CRLDP that
points to the CRL issued by this CA, to ensure that RPs know to check that CRL
vs. the CRL that covers this (the CRL) CA. Do you agree that this approach
meets all the relevant 5280 criteria for what RPs MUST support, and still
allows the AI to issue CRLs for TACs unilaterally?<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 4. Information should be placed in the document \
(Security Considerations is<br>
fine) about the financial model associated with this issuing model. \
All</span></font><font size=3 face="Times New Roman"><span lang=EN-US \
style='font-size:12.0pt; font-family:"Times New Roman"'><o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>user financials need to be done with the BI and not the AI, the \
AI would<br> have to get compensated by the BI for issued certificates. An \
associated<br> item with this is the question of should the BI be able to \
influence<br> contents of the certificate, specifically the lifetime of the \
certificate to<br> correspond to the money paid.<br>
<br>
<b><span style='font-weight:bold'>There is no requirement that the Ai and BI be
operated in a financially-separate fashion, but there also is no prohibition.
Your suggestion is a good one, i.e., adding some text to the security
considerations section to note that IF the AI and BI are financially
independent of one another, THEN the user MUST pay the BI (who already knows
the user's true identity), and the BI will compensate the Ai for each cert it
issues. We can probably leave it to AIs and BIs to coordinate the issue of cert
lifetime, for financial purposes. After all, the management of the CA is a
joint matter for the AI and BI, and we should assume they will be able to work
out these details.<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> The first issue is that you cannot pay the AI for \
your certificate. If you do, then you need to pay with some type of anonymous \
cash, and you must pay using a completely anonymous protocol. I don't know of \
any way to currently do this except in the realm of academia.<br>
I don't believe that you can leave the issue of things like lifetime out.
Let's say that the BI can allow for issuing of certificates for a period of
three months, one year and five years. The BI would need to communicate
this information as part of the token, or the BI and AI would need to have an
additional conversation before the AI builds the certificate in order to get
this piece of information.<br>
As an alternative, you could have different AI's for different length
certificates. This would imply that the BI cannot directly influence the
contents of the certificate, but would require that the BI tell the user what
the name of the AI to be used to issue the certificate. (Which might not
be a bad idea anyway.)<br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) I agree with your point. There was no intent to require
a user to employ an anonymous or cash payment system to acquire a TAC. There
seem to be a few options here, as you noted. If the TAC CA issues certificates
with only one duration, this problem does not arise. If there are multiple
duration options, then there needs to be a way to signal to the AI which
duration the user has paid for. Having different AI instances (by name) is one
solution to the problem, or the token could be extended to accommodate your
other proposed solution. We will add text to the security considerations
section to suggest that a given <st1:place w:st="on"><st1:City \
w:st="on">TAC</st1:City> <st1:State w:st="on">CA</st1:State></st1:place> issued \
certificates with only one lifetime, so avoid the complexity that might arise \
otherwise. We also will note that if a TAC CA offers certificates of with different \
lifetimes, then it will need to communicate this info from the BI to the AI in a way \
that does not unduly compromise the anonymity of the user.<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 5. Renewal/Rekey operations are not covered by \
this document. Either you<br>
need to state that these operations are never done, or you need to have a<br>
secure method of allowing the operation to be completed. In this case the<br>
Token no longer exists (or at least is no longer valid) and so the AI would<br>
need to prove to the BI that the BI should sign the certificate. One<br>
possible method would be to send the BI the TBSigned of the new certificate<br>
along with the old certificate allowing it to see that it had previously<br>
signed a certificate for subject name. It would still not be traceable
back<br>
to the user's Token, but would give assurances that the certificate should<br>
be issued.<br>
<br>
<b><span style='font-weight:bold'>SANG) Good point. Renewal/Rekey should NOT be
supported. We will revise the text accordingly.<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> JIM) This has some implementations for item \
1.<o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color="#1f497d" face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'><br> </span></font><b><font size=3 color="#333399" face="Times \
New Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#333399; font-weight:bold'>SANG) Please refer to the response for item \
1.<br> </span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 6. ALREADY RESOLVED<br>
<br>
7. Guidance needs to be supplied about how long items are to be kept in
the<br>
respective databases. Are these database entries expected to be kept<br>
forever once a certificate has been issued? Or are they only kept for<br>
approximately the life of the certificate. This is really impacted by \
the</span></font><font size=3 face="Times New Roman"><span lang=EN-US \
style='font-size:12.0pt; font-family:"Times New Roman"'><o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>answer to question #5 on rekey/renewal, but has some additional \
tracing<br> implications beyond that.<br>
<br>
<b><span style='font-weight:bold'>SANG) Since TACs are not suitable for NR (a
detail than can be added to the text), there does not appear to be a need to
retain data about TAC certs beyond their lifetime.<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> JIM) An aggrieved entity may want to get the \
identity information about a signer after the certificate has expired. This \
implies that there is at least some minimum duration that the information needs to be \
kept for traceability reasons.<br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) Good point. We'll say that a TAC CA MUST describe in
its CP how long it will retain data about certificates it issued, beyond the
lifetime of these certificates. We also will note your rationale of why such
retention is appropriate. We do not plan to specify a minimum duration
for such retention, as that really is a per-CA matter.<br>
<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'>8. ALREADY RESOLVED<br>
<br>
9. If you believe that TAC permits both signature and encryption<br>
operations, then you need to address an additional problem. If a DSA<br>
signature certificate and a DH encryption certificate pair are needed, it is<br>
some protocols may require that they contain the same subject name, and thus<br>
would need to be issued at the same time. The current TAC protocol makes
no<br>
allowances for the ability to have the BI sign two independent certificates<br>
at the same time. This could be done by allowing the protocol to present<br>
multiple blinded hashes to the BI to be signed for a single token.<br>
<br>
<b><span style='font-weight:bold'>SANG) The primary focus of the TAC work has
been web access. For that, a single cert is enough. But, you make a good point
that if one wants to use TACs with S/MIME, for example, dual cert issuance
needs to be supported. For now, we will stick with single cert issuance, with
it's implied limitations.<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> JIM) This needs to be made explicit.<br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) Please refer to the response for item 2.<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 10. ALREADY RESOLVED<br>
<br>
11. In section 5.1 Step 2, the statement is made that a TLS certificate<br>
should be used for doing the signature operation on a CMS object. You
might<br>
want to rethink this statement. While there is nothing technically wrong<br>
with this, some CMS validators would reject the signature since the EKU<br>
would not be correct.<br>
<br>
<b><span style='font-weight:bold'>Does CMS specify a set of EKUs that are
acceptable for any use of CMS, or are you saying that the presence of any EKU
associated with TLS use might cause rejection because software (e.g., OpenSSL)
has some non-standard restrictions embedded in it?<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> JIM) If there is an EKU in the certificate, and it \
is not one of the "acceptable" EKUs for CMS, it is possible that some \
implementations might reject the certificate. This is highly dependent on the
implementation. I don't know if this is a problem, but it potentially
could be. One possible solution would be to create an EKU
specifically for this operation.<br>
<br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) Sorry for this misunderstanding with regard to TLS
certificates. In section 5.1 Step 2, a TLS certificate is used only for
security channel establishment, not for verifying a signature on a CMS object.
See the end of section 5.1 Step 1, cited below. Does the following text address
your concern?<br>
<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> "</span></font><font size=3 color="#333399" \
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times \
New Roman";color:#333399'>It is RECOMMENDED that the UserKey be a random or \
pseudo-random </span></font><font size=3 color="#333399" face=Courier><span \
lang=EN-US style='font-size:12.0pt; font-family:Courier;color:#333399'>value. \
<o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color="#333399" face=Courier><span
lang=EN-US style='font-size:12.0pt;font-family:Courier;color:#333399'>Whenever
the BI passes a UserKey to an external party, or accepts the UserKey from an
external party <o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color="#333399" face=Courier><span
lang=EN-US style='font-size:12.0pt;font-family:Courier;color:#333399'>(e.g.,
the AI), the value is embedded in digitally signed CMS object called a<br>
</span></font><font size=3 color=black face=Courier><span lang=EN-US
style='font-size:12.0pt;font-family:Courier;color:black'> </span></font><font
size=3 color="#333399" face=Courier><span lang=EN-US style='font-size:12.0pt;
font-family:Courier;color:#333399'> Token, accompanied by the time stamp noted
above. The signature on a Token is generated by <o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color="#333399" face=Courier><span
lang=EN-US style='font-size:12.0pt;font-family:Courier;color:#333399'>the BI
using a private key employed only for this purpose."<br>
</span></font><font size=3 color=black face=Courier><span lang=EN-US
style='font-size:12.0pt;font-family:Courier;color:black'> <br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
12. ALREADY RESOLVED<br>
<br>
13. I would like to see for each of the steps in 5.1, an explanation of
who<br>
needs to be protected against for the communication. This will better
allow<br>
others to decide on how to implement this with non-TLS communications.
For<br>
example, could this be done with e-mail or are the security requirements not<br>
met?<br>
<br>
<b><span style='font-weight:bold'>Not sure what you mean by "who needs to
be protected against for the communication." We can explain in more detail
what security features are required at each step, but there is already some
text addressing this, for at least some steps. For example, in step 2, the
document says:</span></b></span></font><font size=3 face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman"'><o:p></o:p></span></font></p>
<p class=MsoNormal align=left style='text-align:left;text-autospace:ideograph-numeric \
ideograph-other; word-break:keep-all'><font size=3 color=black face="Times New \
Roman"><span lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> <b><span style='font-weight:bold'>"The secure \
channel is required here to prevent a wiretapper from<br>
being able to acquire the Token. For example, if the user<br>
establishes a one-way authenticated TLS session to the BI in<br>
Step 1, this session could be used to pass the Token back to<br>
the user.</span></b>"<br>
</span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> There are cases where you need to explicitly prevent \
either the AI or BI from getting the information, but may not need to protect against \
a general wiretapper. For example, if the client and BI transaction is open \
(except to the AI), this may not help an eavesdropper as long as the client/AI
transaction is completely sealed. The eavesdropper would be in same
situation in this case as BI, it knows some information but not enough to
complete the trace without the cooperation of the AI.<br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) We requested the secure channel in open communications,
based on the information that is valuable from security point of view.<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 14. ALREADY RESOLVED<br>
<br>
15. ALREADY RESOLVED<br>
<br>
16. ALREADY RESOLVED<br>
<br>
17. In section 5.2, step C - should the BI also conduct its own
assessment<br>
of the fact that the aggrieved party's case before releasing the<br>
information?<br>
<br>
<b><span style='font-weight:bold'>BI could do so. We can add text to say that
is an option, but it would be something that each TAC CA decides for itself,
and declares in its CP and details in the CPS.<br>
</span></b></span></font><font size=3 color="#1f497d" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:#1F497D'> <br> Not requiring this would allow for a rouge AI to get \
the information. It would create a pretend aggrieved party, provide the details \
to that party and query the BI. The BI doing no checks would hand over the \
information no questions asked.<br>
</span></font><font size=3 color=black face="Times New Roman"><span lang=EN-US
style='font-size:12.0pt;font-family:"Times New Roman";color:black'> <br>
</span></font><b><font size=3 color="#333399" face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New Roman";color:#333399;
font-weight:bold'>SANG) Fair point. We will change the text to state that BI
should conduct its own assessment of the aggrieved party's case before
releasing the user ID.<br>
</span></font></b><font size=3 color=black face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman";color:black'> <br> 18. ALREADY RESOLVED<br>
<br>
19. ALREADY RESOLVED</span></font><font size=3 face="Times New Roman"><span
lang=EN-US style='font-size:12.0pt;font-family:"Times New \
Roman"'><o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=¹ÙÅÁ><span \
lang=EN-US><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=¹ÙÅÁ><span \
lang=EN-US><o:p> </o:p></span></font></p>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic