RFC 5636
Traceable Anonymous Certificate
Traceable Anonymous Certificate 🦋
Okay bestie, the header info first 📄✨ This is RFC 5636, titled Traceable Anonymous Certificate, from the Network Working Group. It's an Experimental document dated August 2009. The authors are S. Park, H. Park, Y. Won, and J. Lee (all from KISA), plus S. Kent from BBN Technologies. The title block has no Obsoletes or Updates line, so it doesn't list any RFCs it replaces or changes 🙈
Abstract ✨
Okay so this doc is about giving you privacy when you request and use an X.509 certificate that has a pseudonym in it 🎭. But the system still keeps the ability to map that certificate back to the real person who asked for it. You're anonymous to the world, but not to the accountability squad 👀
It's built to play nicely with the normal IETF certificate request formats, PKCS10 (RFC 2986) and CMC (RFC 5272) 💅. The big twist is that the authority jobs get split up. One authority checks that you own the private key (that's the Blind Issuer), and a different one checks what's actually inside the certificate (that's the Anonymity Issuer). The end entity certificates made this way are called Traceable Anonymous Certificates (TACs) 🦋
Status of This Memo 📝
Quick legal-ish vibe check: this memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested, so feel free to weigh in. Distribution of this memo is unlimited 💜
Copyright Notice ©
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, since they spell out your rights and restrictions with respect to this document 📜
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. General Overview ................................................4
3. Requirements ....................................................5
4. Traceable Anonymous Certificate Model ...........................6
5. Issuing a TAC ...................................................7
5.1. Steps in Issuing a TAC .....................................8
5.2. Mapping a TAC to a User's Real Identity ...................15
5.3. TAC Request Message Format Profile ........................17
5.3.1. PKCS10 Profile .....................................17
5.3.2. CMC Profile ........................................18
6. Security Considerations ........................................19
7. Acknowledgments ................................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................22
Appendix A. Traceable Anonymous Certificate ASN.1 Modules .........24
Appendix B. TAC Message Exchanges over Transport Layer Security ...26
B.1. Message Exchanges between a User and the BI or the AI .....26
B.2. Message Exchanges between the BI and the AI ...............27
B.3. Message Exchanges between the Aggrieved Party and the AI
or the BI .................................................27
Appendix C. Cryptographic Message Syntax Profile for TAC Token ....28
C.1. Signed-Data Content Type ..................................28
C.1.1. encapContentInfo ...................................29
C.1.2. signerInfos ........................................291. Introduction ✨
Public Key Infrastructure (PKI) is a super powerful way of authenticating individuals, organizations, and computers (like web servers) 🔐. But when people use certificates to access stuff on the public Internet, there are real concerns about personal privacy 😬. That's why there are growing demands for privacy-enhancing techniques on the Internet.
In a PKI, an authorized entity like a Certification Authority (CA) or a Registration Authority (RA) can come off as a "big brother" 👁️, even when the CA issues a certificate whose Subject name is a pseudonym. That's because those entities can always map a pseudonym in a certificate they issued to the name of the real user it was issued to. This document defines a practical architecture and protocols for offering privacy to a user who requests and uses an X.509 certificate containing a pseudonym, while still keeping the ability to map that certificate to the real user who requested it. It's giving balance 🎀
A PKI typically identifies the holder of a private key (matched to the corresponding public key in a certificate) in a standard way 🔑. The public key, identity, and related information are signed by an entity acting as a CA, as specified in X.509 [11] and as profiled for use in the Internet [2]. Over the past decade, PKIs have been widely deployed to support all kinds of communications and transactions over the Internet 🌐
However, when it comes to privacy on the Internet, a PKI is generally not very privacy-friendly, at least partly because of these issues:
- A certificate typically contains the true identity of the user it was issued to in the Subject field. That identity gets disclosed to a relying party (like a web site, or the recipient of an S/MIME message [18]) whenever the certificate holder presents it in a security protocol that requires a user to present a certificate. In some protocols, like TLS, a user's certificate is sent over an unencrypted channel before a secure communication capability is set up 😱
- A certificate is often published by the CA, for example in a directory system that may be widely accessible 📚
- An anonymous (end entity) certificate [9] is one that indicates the holder's true identity is not represented in the subject field. (Such a certificate might more accurately be called "pseudonymous", since an X.509 certificate must contain an identifier to comply with PKI format standards, and a CA must not issue multiple certificates with the same Subject name to different entities. However, we use the more common term "anonymous" throughout this document to refer to such certificates.) Issuing anonymous certificates could enhance user privacy 🥰
There is, however, a need to balance privacy and accountability when issuing anonymous certificates ⚖️. If a CA/RA can't map an anonymous certificate to the real user it was issued to, the user might abuse the anonymity the certificate gives them, because relying parties would have no recourse. Yikes 💀
A CA or RA generally would be able to map an anonymous certificate to the user it was issued to, which helps avoid those problems. To do that, the CA/RA would first identify the user and maintain a database that relates the user's true identity to the pseudonym carried in the certificate's Subject field 🗃️
In a traditional PKI, there's a nominal separation of functions between an RA and a CA, but in practice these roles are often closely coordinated 🤝. So either the RA or the CA could, in principle, unilaterally map an autonomous certificate to the real user identity. Not ideal, bestie 🙈
The architecture, syntax, and protocol conventions described in this document let anonymous certificates be issued and used in existing PKIs. They strike a balance between privacy and a conditional ability to map an anonymous certificate to the individual it was issued to 🦋
An anonymous certificate (Traceable Anonymous Certificate) in this document is issued by a pair of entities that operate in a split responsibility mode: a Blind Issuer (BI) and an Anonymity Issuer (AI) 👯. The conditional traceability this model offers assumes a strong separation between the RA and CA roles, and uses technical means (threshold cryptography and "blinded" signatures) to make that separation happen. (A blinded signature is one in which the value being signed is not made visible to the signer, via cryptographic means. More details come later 🔍)
The AI knows about the certificate issued to the user, but has no knowledge of the user's real identity. The BI knows the user's real identity, but has no knowledge of the certificate issued to that user. Only if the AI and BI collaborate can they map the TAC issued to a user to that user's real identity 🤫 That's the whole flex, honestly 💅
1.1. Conventions Used in This Document 📏
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 🧐
2. General Overview 🗺️
This section defines the notion of a Traceable Anonymous Certificate (referred to as TAC or anonymous certificate in this document) 🎀. It's different from a conventional pseudonymous certificate [8, 9] because a TAC containing a pseudonym in the Subject field will be conditionally traceable (as defined that it is not trivial to design a system that issues anonymous certificates, consistent with Internet PKI standards, when additional constraints are imposed, as illustrated by the following scenarios. Lowkey tricky, right? 🧩 Here are the scenarios:
- If a CA issues an anonymous certificate without verifying a true identity, it is untraceable. That gives inadequate recourse if the user it was issued to abuses the anonymity it provides. (Even without the ability to trace an anonymous certificate to the corresponding user, the certificate can always be revoked, but this may not be a sufficient response to abuse 🚫)
- If a CA issues an anonymous certificate but verifies the real identity and keeps a record of that identity, the CA can link the pseudonym in the Subject field to the real identity. That's a potential "big brother" problem [12] 👀
- If the CA issues a certificate with a certificate containing a user-selected Subject name, and does not verify the user's identity, the certificate is effectively untraceable 🫠
- If the CA issues an anonymous certificate using a blind signature (see below), the CA cannot verify the contents of the certificate. That makes the certificate untraceable and essentially forgeable. (If a CA signs a certificate without examining its content, even after verifying a user's identity, certificates issued by the CA are essentially forgeable 💀)
To address the issues above, we extend the simple separation-of-authority concept already defined in the RA/CA PKI model 🧩 First we restate the requirements in a more precise and concise fashion, then introduce a basic model for achieving the goals from a more general perspective [16] ✨
Part 1 of 6 is done, bestie 🧚 Next up: Section 3, Requirements 💜
3. Requirements ✨
okay bestie, this is the checklist the TAC design has to pass 📝 and it's giving strict. The goal is a new separation-of-authority model for issuing Traceable Anonymous Certificates 🦋 that still plays nicely with the standards existing PKIs already use 💅. Here's what has to be true:
- The Traceable Anonymous Certificate
MUSTbe a syntactically valid X.509 certificate in which the Subject field contains a pseudonym. 🎀 - There needs to be technical ways to shut down a sneaky malicious user who later says "not me…" about stuff they did 🙈. So when a user is identified and asks for a TAC, the mechanisms used
MUSTmake sure the TAC goes to the same person who asked for it (unless that user hands the private key to someone else, who is unknown to the RA/CA). - The traceability and revocation functions
MUSTsupport linking a user's true identity to the pseudonym in a certificate issued to them. So the solutionMUSTlet anyone figure out the true identity from the anonymous certificate, but only once the authorities who worked together to issue the certificate agree to it 🔥.
4. Traceable Anonymous Certificate Model 🧚
okay so a TAC is an end entity (EE) certificate that gets issued by a pair of entities working in split responsibility mode: a Blind Issuer (BI) and an Anonymity Issuer (AI) 👯. To the outside world, the pair looks like a single CA. For example, they're represented by one CA certificate 💜. The public key in that CA certificate verifies certificates issued by this CA the normal way, which means a relying party handles a TAC just like any other EE certificate ✨.
The BI acts as an RA 💼. It works with a user to verify the user's "real" identity, just like a normal RA would. The BI keeps a database that can map a TAC back to the user it was issued to, but it can only do that with the AI's cooperation 🫶.
That mapping only gets started if there's evidence that the user it was issued to has abused the anonymity the TAC gives them 🚨.
The AI acts as a CA 🏛️. It checks a certificate request the user sends in, using a standard request format like PKCS10. The AI does all the usual CA jobs, like a private-key proof-of-possession (PoP) check, a name uniqueness check across all the certificates it has issued, assigning a serial number, and so on. To actually issue the TAC, the AI talks to the BI over a secure channel to create the signature on the TAC together, then sends the signed TAC to the user 🎁.
The AI manages all this without ever learning the user's real identity, whether from the user or from the BI 🙈.
Here's the big payoff: neither one can reveal the real user identity on their own 👑. The AI knows about the certificate issued to the user, but has no idea who the user really is. The BI knows the user's real identity, but has no idea what certificate was issued to that user. Only if the AI and BI team up can they map a TAC to the real person it belongs to 🌈.
Is this system perfect? nope 💀. It assumes the AI and BI only team up to reveal someone's real identity under appropriate circumstances. How they make sure that happens is procedural security stuff, and it's outside the scope of this document. Still, adopting this model has real security benefits, thanks to the technical approach used to keep the BI and AI functions separate 🔐.
For example, the BI and AI can be run by different organizations, in geographically separate facilities, with different staff. That means you can have more confidence in the anonymity the system gives a user, compared to a monolithic CA that only relies on procedural controls to keep things anonymous 🍓.
5. Issuing a TAC 🎀
The following subsections explain the procedures and protocols used to issue a TAC 📋. First up, the BI and AI work together to generate a public key pair (the one that represents the CA as relying parties see it) using a threshold signature scheme 🤝. Threshold signature schemes have been defined for RSA. How it works depends on the algorithm in question, so it isn't covered here. Go check [15] for the procedures for implementing RSA threshold signatures. A DSA-based threshold signature scheme will be added in a future version of TAC [14] 🔮.
Quick note: this split signing model for issuance is a super simple case of a threshold signature 💅. The private key used to sign a TAC gets divided into exactly two shares, one held by the BI and one held by the AI. Both shares have to be used, one after the other, to create a signature on a TAC. Once the key pair for the (nominal) CA is generated and the private key is split between the BI and AI, the public key gets published, for example in a self-signed certificate representing the TAC CA 📜.
Another public-key crypto function that's essential to this system is called "blind signing" 🦋. To make a blind signature, one party encrypts a value to be signed (like a hash value of a certificate) and passes it to the signer. The signer digitally signs the encrypted value and sends it back to the first party. The first party then undoes the encryption it applied using the random value it started with, which gives a signature on the underlying data (like a hash value) 🌸.
This technique lets the signer digitally sign a message without ever seeing what's in it 👀. It's the simplest approach to blind signing, but it requires that the public key needed to undo the encryption not be available to the blind signer. Other blind signing techniques skip that restriction, but they're more complicated 🧩.
The tricky part is that the blinding function must be associative and commutative with regard to a public-key signature function 🤯. Let B be a blinding function, B-INV its inverse, and S a public-key signature. The following relationship must hold:
B-INV( S (B (X) ) ) = B-INV( B( S (X) ) ) = S (X).RSA can blind a value with a random value and sign a blinded value, because the modular exponentiation operation RSA uses for both signatures and encryption is associative and commutative 💖.
The TAC issuance process needs the BI, the AI, and the user to be able to use secure communication channels with each other 🔒.
TLS [17] is one suitable way to set up those channels, although other options are acceptable too. This document assumes TLS as the default secure channel, which means the BI and AI need X.509 certificates representing them 🎀.
These certificates are separate from the certificate representing the CA (formed by the BI and AI). They can be self-signed or issued by other CA(s) 🫧.
Appendix B gives a top-level description of how TLS applies to these message exchanges ✨.
5.1. Steps in Issuing a TAC 🌈
Figure 1 shows the procedures for issuing a TAC 🗺️. The lines are the steps in the issuance process, and the numbers point to those steps.
1 +---------------+
+<-------->| Blind |
| 2 | Issuer (BI)|
| +---------------+
+-------+ | ^
| user |<------------>| 4 | 5
+-------+ | v
| 3 +----------------+
+--------->| |
| | Anonymity |
| | Issuer (AI) |
+<-------- | |
6 +----------------+
Figure 1. TAC Issuance ProceduresStep 1:
Okay so the user authenticates themselves to the BI 🪪. This can happen in person or electronically. The same sorts of procedures RAs use for normal certificate issuance apply here. Those procedures aren't standardized, so they aren't described in detail here. For the TAC architecture, the BI has to create a record in a database for the user and generate a (locally) unique identifier called the UserKey, which will act as a (database) key for that record 🔑. The UserKey value MUST NOT be generated in a way that lets any outside entity (including the AI) infer a user's real identity from its value. For example, if the user's name is used as input to a one-way hash algorithm to generate the UserKey value, then additional random data must be used as input too, to prevent simple guessing attacks 🙅. Each UserKey in this database has an expiration time attached. The BI and AI use that expiration time to reject session-level replay attacks in some exchanges, and to let them garbage-collect database records when a user starts a certificate request but never finishes it 🗑️.
It's RECOMMENDED that the UserKey be a random or pseudo-random value 🎲. Whenever the BI passes a UserKey to an external party, or accepts one from an external party (like the AI), the value gets wrapped in a digitally signed CMS object called a Token, along with the timestamp mentioned above. The BI generates the signature on a Token. (Note that the certificate used here is just a certificate suitable for use with CMS, and it is NOT the split-key certificate used to verify TAC 💅.)
The following ASN.1 syntax represents the UserKey and an expiration time:
UserKey ::= OCTET STRING
Timeout ::= GeneralizedTimeIn the context of this specification, the GeneralizedTime value MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (YYYYMMDDHHMMSSZ) ⏰.
Step 2:
The BI presents the user with a data structure called a Token 🎟️. The Token must be conveyed to the user over a secure channel, like in person or through a secure communication channel. The secure channel is required here so a wiretapper can't grab the Token 🕵️. For example, if the user set up a one-way authenticated TLS session with the BI in Step 1, that same session could be used to pass the Token back to the user 💜.
The Token has two jobs, bestie 🎀 First, during TAC issuance, it proves that the request to the AI came from someone registered with the BI 🧚 (so there's a record of their real identity in the BI's database). That's what makes the TAC traceable to the user later. Second, if someone asks to reveal a user's real identity, the AI releases the Token to the entity requesting the trace, and that entity passes it to the BI so the TAC can be traced 🕵️♀️ If the BI doesn't do its part of the certificate issuance procedure (in Step 6) before the Token expires, the BI can delete the Token from its database as garbage collection 🗑️ The timeout value inside a Token is picked by the BI, so that's its call ⏰
The Token is a ContentInfo with a contentType of id-kisa-tac-token. Its content is a SignedData (CMS SignedData object [6]) signed by the BI. The eContent (EncapsulatedContentInfo) is a SEQUENCE of the UserKey and Timeout, and the eContentType MUST be id-data 💖
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the UserKey and
-- Timeout'
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }The signature (SignatureValue of SignerInfo) is made with the BI's private signature key, which matches the public key in the BI's certificate. Heads up, this certificate is just a regular TLS certificate, NOT the split-key certificate used to verify a TAC 👀 The certificate (or certificates) MUST be present 🔐 Appendix A has the ASN.1 syntax for the Token as a profiled CMS ContentInfo object, and Appendix C has the CMS SignedData object profile for wrapping the Token.
Token ::= ContentInfoWhen the user gets the Token, they SHOULD verify the signature using the BI public key and note the Timeout value, so the certificate request gets finished before that time ⏳✨
Step 3: 📝
The user prepares a certificate request in a standard format, for example PKCS10 [3] or CMC [4] 📄 The Subject field of the certificate holds a pseudonym the user generated. It's expected that the CA (BI + AI) might provide software that users can use to build their certificate requests 💻
If they do, that software can generate a candidate Subject name to lower the chances of a collision 🙌 If the user picks a pseudonym without that help, a subject name collision will probably be more likely. That means the certificate request could get rejected, or the AI might have to generate a pseudonym for the user instead 😬
After building the certificate request, the user sends it, along with the Token from Step 2, to the AI over a secure channel 🔒 This channel MUST be encrypted and one-way authenticated. In other words, the user MUST be able to verify that they're talking to the AI, but the AI MUST NOT be able to verify the user's real identity 🙈 Typical TLS use for secure web site access meets this requirement. The certificate request (PKCS10 [3] or CMC [4]) carries the Token from Step 2 💌
The Token goes in as an attribute of a certificate request (CertificationRequestInfo.attributes), where the attrType MUST be id-kisa-tac below in PKCS10 format. In CMC [4] format, the Token is set as attrValues (Certificate Request Controls), where the attrType MUST be id-kisa-tac. The TAC request message profile is described in the section 5.3 🦋
Step 4: 🔍
The AI gets the certificate request containing a Token and checks that the request is consistent with the processing defined for the request format (PKCS10) ✅ If a Subject name is there, the AI checks that the proposed pseudonym is unique. It also verifies the signature on the Token and, if that's valid, checks the Timeout value to reject a replay attack based on a "timed-out" Token 🚫
A Token with an old Timeout value gets rejected out-of-hand by the AI ✋ (Once a Token's Timeout time is reached, the AI deletes the Token from its cache.) Next, the AI compares the received Token against its cache of recent (not "timed out"), validated Tokens 🗂️ The AI matches the resubmitted request to the original request and responds accordingly. For example, if a duplicate is detected, the certificate request can be rejected as a replay 🔁
If the Subject field has a Subject name the AI already issued, the AI MUST either reject the certificate request, or substitute a pseudonym it generates. Which one depends on the policy of the TAC CA 🏛️ If the certificate request is acceptable, the AI assigns a serial number and builds a tbsCertificate (the final form of the certificate payload, ready to be signed) 📦
Then the AI computes a hash over this data structure and blinds the hash value. (The AI blinds it using a key from a public-key encryption pair where neither key is ever made public. The other key from that pair is used by the AI in Step 6 to un-blind the signed hash value 🪄)
The AI sends the CMS ContentInfo object of TokenandBlindHash to the BI over a two-way authenticated and encrypted channel. That two-way authentication and encryption is required so the BI can verify the values came from the AI, and so a wiretapper can't grab the Token 🕶️ A TLS session where both parties use certificates to authenticate each other is the RECOMMENDED way to do this 💜
The TokenandBlindHash is a CMS ContentInfo with a contentType of id-kisa-tac-tokenandblindhash. Its content is a SignedData (CMS SignedData object [6]) signed by the AI, and the eContent (EncapsulatedContentInfo) is a SEQUENCE of the Token and BlindedCertificateHash. The eContentType MUST be id-data 🎀
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the Token and
-- BlindedCertificateHash'The signature (SignatureValue of SignerInfo) is made with the AI's private signature key, which matches the public key in the AI's certificate. Again, this is just a TLS-suitable certificate and NOT the split-key certificate used to issue a TAC. The certificate (or certificates) MUST be present 🔐
The following ASN.1 syntax represents the Token and BlindedCertificateHash:
Token ::= ContentInfo
BlinedCertificateHash ::= OCTET STRINGToken is the value of ContentInfo in the certificate request message (CertificationRequestInfo.attributes) from Step 3. BlindedCertificateHash is the blinded hash value for the tbsCertificate. Appendix A provides the ASN.1 syntax for the Token as a profiled CMS ContentInfo object, and Appendix C provides the CMS SignedData object profile for wrapping the Token.
TokenandBlindHash ::= ContentInfoStep 5: 🏦
The BI receives the Token and blinded certificate hash over the secure channel from above. First, the BI verifies the signature on the TokenandBlindHash generated by the AI. Then it verifies the signature on the Token, to make sure it's a legit Token generated by the BI 💅 Next, the BI checks its database to confirm that the UserKey value from the Token is there, and that the Token hasn't already been used to authorize a certificate issuance 👀
This check makes sure the BI has authenticated the user and entered their real identity into the BI's database. Each Token authorizes issuance of only one certificate, so the check also makes sure the same Token wasn't used for more than one certificate. Together, these checks mean the certificate the AI issues to this user will be traceable, if needed 🫶
The BI uses its share of the threshold private signature key to sign the blinded certificate hash, then returns the CMS SignedData back to the AI. The eContent of the SignedData is a SEQUENCE of the Token and PartiallySignedCertificateHash 🧩
The following ASN.1 syntax represents the Token and PartiallySignedCertificateHash:
Token ::= ContentInfo
PartiallySignedCertificateHash ::= OCTET STRINGToken is the token value of the TokenandBlindHash (where the eContent is a SEQUENCE of the Token and PartiallySignedCertificateHash) from Step 4. PartiallySignedCertificateHash is the signature value that BI's share of the threshold private signature key generated on BlindedCertificateHash from Step 4 ✨
The TokenandPartiallySignedCertificateHash is a CMS ContentInfo with a contentType of id-kisa-tac-tokenandpartially. Its content is a SignedData (CMS SignedData object [6]) signed by the BI, and the eContent (EncapsulatedContentInfo) is a SEQUENCE of the Token and PartiallySignedCertificateHash. The eContentType MUST be id-data 🌸
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the Token and
-- PartiallySignedCertificateHash'The signature (SignatureValue of SignerInfo) is made with the BI's private signature key, which matches the public key in the BI's certificate. (Yep, it's a TLS certificate and NOT the split-key certificate used to issue a TAC.) The certificate (or certificates) MUST be present. Appendix A has the ASN.1 syntax for the Token as a profiled CMS SignedData object, and Appendix C has the CMS SignedData object profile for wrapping the Token.
TokenandPartiallySignedCertificateHash ::= ContentInfoStep 6: 🎉
When the AI gets the TokenandPartiallySignedCertificateHash, it verifies the signature on the PartiallySignedCertificateHash, which was generated by the BI. Then it matches the Token against its list of outstanding requests to the BI 📋 The AI next un-blinds the blindHashValue, using the other key from the key pair it used in Step 4. That reveals the partially signed certificate hash. Then the AI applies its part of the split private key to finish signing the user's certificate 🔑✨
It records the certificate and the Token value in its database, so the certificate can be traced back to the real user identity later, if needed 🕵️ The AI sends the completed certificate to the user in the response message of the request protocol the user used in Step 3, which is PKCS10 💌
The user can now use the certificate with any PKI-enabled app or protocol that works with X.509 certificates 💅, as long as it matches the key usage and Extended Key Usage (EKU) values in the cert 🎀. Heads up, bestie: the user should be prepared for issuance to take a little while ⏳. The connection between the user and the AI could drop after they send the request at the end of Step 3 and before the AI sends the cert back at the end of Step 6 😭. If that happens, the user should resubmit the request 🔁. The AI and BI keep enough state to match the resubmitted request to the original and respond accordingly 🧠✨. And if the process fails in Steps 5 or 6, the AI sends an error indication back to the user 💀.
5.2. Mapping a TAC to a User's Real Identity
If a user who was issued a TAC abuses the anonymity that TAC gives them, the TAC can be traced back to that user's identity 🕵️♀️. Mapping a TAC to a real identity is a four-step process 🦋, described below and illustrated in Figure 2.
C +---------------+
+<-------->| Blind |
| D | Issuer (BI)|
| +---------------+
+---------+ |
| Relying |<---------->|
| Party | |
+---------+ |
| A +----------------+
+<-------->| Anonymity |
B | Issuer (AI) |
+----------------+
Figure 2. Revealing a TAC User's Real IdentityStep A:
The AI checks the claim from an aggrieved party that a TAC user has abused the anonymity their TAC gave them 👀. The procedures the AI uses to confirm that abuse happened are outside the scope of this document 🙅♀️. No protocol is defined here for the interaction between the aggrieved party and the AI. The only technical requirement is that the offending user's TAC gets handed over to the AI 📨. If the AI decides there's enough evidence of abuse to trace the TAC to the user, it revokes the TAC by listing its serial number on the next Certificate Revocation List (CRL) the AI issues 🚫.
The AI manages the CRL for a TAC all by itself 👑. Because RFC 5280 implementations are not required to process indirect CRLs, we create a second certificate for the CA, under the TAC CA 🧩. Revoked EE certificates issued by the TAC CA get recorded on this CRL and validated using this second CA certificate.
This CA certificate has the cRLSign bit set in the KeyUsage extension, but not the keyCertSign bit 🔑. The AI holds the private key for this certificate, so it can issue CRLs on its own.
The Subject DN (Distinguished Name) is the same in both CA certificates. That reinforces the vibe that the CRL issuer is the same entity as the TAC issuer, and that this CRL is not an indirect CRL 💖. Because the CRL issuer doesn't issue any certificates itself, there's no possible serial number conflict 🙌. This is the only CA certificate issued under the TAC CA certificate, so it gets signed jointly by the BI and AI 🤝. We recommend that the CRL for this CA certificate be similarly long-lived, since it also needs to be signed by the BI and AI ⏰. Each EE TAC certificate MUST contain a CRL Distribution Point that points to the CRL issued by this CA 📍. That way relying parties know to check this CRL and not the one that covers only the CRL CA 🧐. (If the AI uses the Online Certificate Status Protocol (OCSP) [13] to convey the revocation status of TACs, an equivalent procedure is employed 🔁.) If it's later determined that the revocation wasn't warranted, a new TAC can be issued to keep the user's anonymity intact for future transactions 🌸.
Step B:
The AI searches its database, for example by the serial number in the TAC, to find the Token that was passed between the AI and BI during issuance (Steps 5 and 6 above) 🔍. The AI passes this Token to the aggrieved party over an encrypted and two-way authenticated channel 🔐. Encryption is required to keep the Token from being disclosed, and two-way authentication is required so the aggrieved party and the AI know they're talking to each other 🫶. Two-way authenticated TLS is the RECOMMENDED way to implement this channel, though other approaches are allowed ✨.
Steps C and D:
The aggrieved party transits the Token to the BI over an encrypted and two-way authenticated channel 🚀. The channel MUST be encrypted so the Token isn't disclosed, and two-way authentication is required so the aggrieved party and the BI know they're communicating with each other 💜. If the Certificate Policy (CP) for the TAC CA specifies it, the BI independently determines that there's enough evidence of abuse to trace the TAC to the user before going any further 🧐. The BI verifies its own signature on the Token, to confirm it's a Token it generated and presumably released to the aggrieved party through the AI 🪄. Next, the BI searches its database using the UserKey value pulled from the Token 🗂️. The BI retrieves the user's real identity and hands it to the aggrieved party 🎉. (By making the aggrieved party deal with both the AI and the BI, the BI can confirm it's dealing with an actual aggrieved party, not with the AI going rogue solo 😤.)
5.3. TAC Request Message Format Profile
A TAC request MAY use either PKCS10 or CMC 📝. An AI MUST support PKCS10 and MAY support CMC 💅.
5.3.1. PKCS10 Profile
This profile refines the specification in PKCS10 [3] as it relates to TAC 🌷. A Certificate Request Message object, formatted according to PKCS10, is passed to the AI.
This profile applies the following additional constraints to fields that may appear in a CertificationRequestInfo 🎀:
- Version: This field is mandatory and MUST have the value 0.
- Subject: This field MUST be present. If the value of this field is empty, the AI generates a subject name that is unique in the context of certificates issued by this issuer 🪪. If the Subject field contains a Subject name the AI has already issued, the AI MUST either reject the certificate request, or substitute a pseudonym it generates, depending on the policy of the TAC CA 🙃.
- SubjectPublicKeyInfo: This field specifies the subject's public key and the algorithm the key is used with 🔐.
- Attributes: PKCS10 [3] defines the attributes field as key-value pairs, where the key is an OID and the structure of the value depends on the key 🧃. The attribute field MUST include the
id-kisa-tacattribute, which holds the Token and is defined below 🎫. The Attributes field MAY also contain X509v3 Certificate Extensions and any PKCS9 [7] extensionRequest attributes that the subscriber would like included in the certificate 💫. The profile for extensions in certificate requests is specified in RFC 5280 [2] 📖.
5.3.2. CMC Profile
This profile refines the Certificate Request messages in Certificate Management over CMS in CMC [4], as they relate to TACs 🦄.
A Certificate Request message, formatted according to CMC [4], is passed to the AI.
Apart from the public-key-related fields, the CA is allowed to change any requested field when it issues the matching certificate 🔄.
This profile recommends the full PKI Request over the Simple PKI Request, and the PKI Request SHOULD be encapsulated in SignedData with an eContentType of id-cct-PKIData 📦.
This profile applies the following additional constraints to fields that may appear in a Certificate Request Template of Certificate Request Message Format (CRMF) [5] 🧾:
- Version: This field MAY be absent, or MAY specify the request of a Version 3 Certificate. It SHOULD be omitted.
- SerialNumber: As per CRMF [5], this field is assigned by the CA and MUST be omitted in this profile.
- SigningAlgorithm: As per CRMF [5], this field is assigned by the CA and MUST be omitted in this profile.
- Issuer: This field is assigned by the CA and MUST be omitted in this profile.
- Validity: This field MAY be omitted. If it's omitted, the AI issues a Certificate with Validity dates set by the TAC CA policy ⏳. If it's specified, the CA MAY override the requested values with dates set by the TAC CA policy.
- Subject: This field MUST be present. If the value of this field is empty, the AI MUST generate a subject name that is unique in the context of certificates issued by this issuer. If the Subject field contains a Subject name the AI has already issued, the AI MUST either reject the certificate request, or substitute a pseudonym it generates, depending on the policy of the TAC CA 🫠.
- PublicKey: This field MUST be present. 🔑
This profile also refines constraints that may appear in a Certificate Request controls: the Token is set to attrValues (in CertRequest.controls) where the attrType MUST be id-kisa-tac 🧚.
See Section 5.3.1, "PKCS10 Profile", for the certification request formats based on PKCS10 📚.
6. Security Considerations ✨
Okay bestie, the anonymity from this architecture and these protocols is conditional 🙈. And if a user reuses the same TAC for multiple transactions (with the same or different parties), those transactions can be linked because they share that TAC. So the anonymity is "weak," even though the user's real identity stays hidden 🫶.
To get stronger anonymity, a user can grab multiple TACs by running the protocol through distinct iterations 🦋. Each TAC is generated independently, so it should not be possible for a relying party to link pseudonyms together unless the tracing feature gets invoked. But if a TAC has a long validity interval, the chance of figuring out who a TAC user is goes up, for example by linking their transactions across multiple servers 😭. So we recommend that each TAC CA think carefully about how long a TAC certificate's validity should be. When a TAC is being issued, the AI and the user interact directly, so the AI may see lower-layer info (like an IP address) that could reveal the user's identity. A user worried about that should use appropriate measures to conceal it, such as a network anonymity service like Tor [10].
This document has no provisions for certificate renewal or rekey 🌸, so we recommend TAC users get new TACs periodically to further lower the likelihood of linkage. It may also be possible to figure out a user's identity from info carried by lower-level protocols, or through other application-specific means. For example, the user's IP address might be used to identify him. For this reason, we recommend that a TAC be used primarily to access web services with anonymity. Also, the TAC architecture in this document can't be used for S/MIME certificates 📧, because there's no provision to issue two certificates (one for encryption and one for signatures) that contain the same anonymous Subject name. A similar problem could pop up if a user visits a site without concealing their identity, that site drops a "cookie" into the user's browser cache, and the user later visits a site and uses a TAC assuming they're anonymous 👀.
Using a TAC is a tool to help a user preserve anonymity, but it is not, per se, a guarantee of anonymity 🎀. We recommend that each TAC CA issue certificates with only one lifetime, to avoid the complexity that could otherwise arise. If a TAC CA offered certificates with different lifetimes, it would need to communicate this information from the BI to the AI in a way that does not unduly compromise the user's anonymity.
This architecture uses the UserKey to link a TAC to the corresponding real user identity 🔗. The UserKey is generated so that it cannot be examined to determine a user's real identity. UserKey values are kept in two distinct databases: the BI database maps a UserKey to a real user identity, and the AI database maps a TAC to a UserKey. The UserKey is always carried in a signed data object, a Token. The Token is signed so the BI can verify its authenticity, which prevents attacks based on guessing UserKey values. The Token also carries a Timeout value, so the AI and BI can reject session-level replay attacks and garbage collect their databases 🧹.
Threshold cryptography is used to enable strong separation of the BI and AI functions, and to make sure both must cooperate to issue certificates under the aegis of a TAC CA 🤝. (The AI and BI must ensure that the threshold cryptographic scheme they employ does not provide an advantage to either party based on the way the key-splitting is effected.) Blind signatures are used with threshold cryptography to preserve the separation of functions, meaning they stop the BI from learning the hash value of the TAC issued by the AI 🙈.
Message exchanges between a user and the BI or the AI, between the AI and BI, and between an aggrieved party and the AI and BI all use secure channels 🔐. These channels are encrypted to prevent disclosure of the Token value and of the pseudonym in the TAC request and response and in a tracing request. The channels are two-way authenticated so the AI and BI can verify their respective identities when they talk to each other, and one-way authenticated so the user can verify their identities when communicating with them. Two-way authentication is used for communication between an aggrieved party and the AI and BI, so all parties can verify one another.
There is an opportunity for the AI to return the wrong UserKey to an aggrieved party 😱, which would trace a certificate to the wrong real user identity. This appears to be unavoidable in any scheme of this sort, since the BI's database is intentionally ignorant of any info relating a UserKey to a TAC.
A TAC CA MUST describe in its CP how long it will retain the data about certificates it issued, beyond the lifetime of these certificates ⏳. This helps a prospective TAC subject gauge the likelihood of unauthorized use of their identity from a compromise of this retained data. It also tells relying parties the timeframe (after a certificate expires) in which an alleged abuse must be brought to the attention of the AI and BI, before the data linking a certificate to the real user identity is destroyed.
7. Acknowledgments
Huge shoutout to Tim Polk (NIST), Stefan Santesson (ACC-sec.com), Jim Schaad (Soaring Hawk), David A. Cooper (NIST), SeokLae Lee, JongHyun Baek, SoonTae Park (KISA), Taekyoung Kwon (Sejong University), JungHee Cheon (Seoul National University), and YongDae Kim (Minnesota University) 👑. They significantly contributed to the work on the concept of TAC and identified security issues, and their comments enhanced the maturity of the document 🌈.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[3] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[4] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[5] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[7] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
8.2. Informative References
[8] S. Brands, "Rethinking public key infrastructures and digital certificates - Building in Privacy", PhD thesis, Eindhoven Institute of Technology, Eindhoven, The Netherlands, 1999.
[9] D. Chaum, "Blind signature system", CRYPTO '83, Plenum Press, page 153, 1984.
[10] "Tor: anonymity online", http://www.torproject.org.
[11] X.509, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, March 2000. Also available as ISO/IEC 9594-8, 2001.
[12] S. Rafaeli, M. Rennhard, L. Mathy, B. Plattner, and D. Hutchison, "An Architecture for Pseudonymous e-Commerce", AISB'01 Symposium on Information Agents for Electronic Commerce, pp. 33-41, 2001.
[13] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[14] Philip MacKenzie and Michael K. Reiter, "Two-Party Generation of DSA Signature", Crypto 2001.
[15] Shaohua Tang, "Simple Threshold RSA Signature Scheme Based on Simple Secret Sharing", in "Computational Intelligence and Security", CIS 2005, Part II, Springer, pp. 186-191, 2005.
[16] Taekyoung Kwon, Jung Hee Cheon, Yongdae Kim, Jae-Il Lee, "Privacy Protection in PKIs: A Separation-of-Authority Approach", in "Information Security Applications", WISA 2006, Springer, pp. 297-311, 2007.
[17] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[18] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
Appendix A. Traceable Anonymous Certificate ASN.1 Modules 🧚
DEFINITIONS IMPLICIT TAGS ::=
--
-- Copyright (c) 2009 IETF Trust and the persons identified as
-- authors of the code. All rights reserved.
--
-- Redistribution and use in source and binary forms, with or
-- without modification, are permitted provided that the following
-- conditions are met:
--
-- - Redistributions of source code must retain the above
-- copyright notice, this list of conditions and the following
-- disclaimer.
--
-- - Redistributions in binary form must reproduce the above
-- copyright notice, this list of conditions and the following
-- disclaimer in the documentation and/or other materials provided
-- with the distribution.
--
-- - Neither the name of Internet Society, IETF or IETF Trust, nor
-- the names of specific contributors, may be used to endorse or
-- promote products derived from this software without specific
-- prior written permission.
--
--
--
-- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
-- CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
-- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-- DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
-- BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
-- EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
-- TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-- DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
-- ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-- OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-- POSSIBILITY OF SUCH DAMAGE.
--
-- This version of the ASN.1 module is part of RFC 5636;
-- see the RFC itself for full legal notices.
--
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes.
IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber, Name FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Imports from CMS
ContentInfo, SignedData FROM
CryptographicMessageSyntax2004{ iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24)}Appendix A. ASN.1 Module (continued) ✨
UserKey ::= OCTET STRING
Timeout ::= GeneralizedTime
BlinedCertificateHash ::= OCTET STRING
PartiallySignedCertificateHash ::= OCTET STRING
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
Token ::= ContentInfo
TokenandBlindHash ::= ContentInfo
TokenandPartiallySignedCertificateHash ::= ContentInfo
id-KISA OBJECT IDENTIFIER ::= {iso(1) member-body(2) korea(410)
kisa(200004)}
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-kisa-tac OBJECT IDENTIFIER ::= {id-attribute 1}
id-kisa-tac-token OBJECT IDENTIFIER ::= { id-kisa-tac 1}
id-kisa-tac-tokenandblindbash OBJECT IDENTIFIER ::= { id-kisa-tac 2}
id-kisa-tac-tokenandpartially OBJECT IDENTIFIER ::= { id-kisa-tac 3}
ENDAppendix B. TAC Message Exchanges over Transport Layer Security 🔐
Okay, so every TAC chat is going over a secure channel 🫶. That covers user to BI or AI, AI to BI, and aggrieved party to AI or BI. The whole point is that nobody gets to peek at the Token value or the pseudonym, whether it's in the TAC request, the response, or a tracing request 🙈. Transport Layer Security Protocol v1.2 (TLS) [17] is a solid pick for this, and this document recommends use of TLS to protect these exchanges 💜. Below is how the TLS handshake should be used for each type of exchange. Heads up, no specific cipher suites are named here. Picking them is up to the client and servers, which is totally normal 💅.
B.1. Message Exchanges between a User and the BI or the AI 💖
The channels between a User and the BI or the AI are one-way authenticated, so the user can verify who they're talking to 🦋.
User BI or AI
ClientHello -------->
ServerHello
Certificate
<-------- ServerHelloDone
ClientKeyExchange
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC MessageFigure 3. TAC Message exchanges between a User and the BI or the AI
B.2. Message Exchanges between the BI and the AI 🌸
The channels between the BI and the AI are two-way authenticated, so the AI and BI can verify each other's identities when they communicate 🤝.
BI AI
ClientHello -------->
ServerHello
Certificate
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC MessageFigure 4. TAC Message exchanges between BI and AI
B.3. Message Exchanges between the Aggrieved Party and the AI or the BI 😤
The channels between a User and the BI or the AI are two-way authenticated, so both parties can verify one another's identity 💅.
User BI or AI
ClientHello -------->
ServerHello
Certificate
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC MessageFigure 5. TAC Message Exchanges between an Aggrieved Party and the BI or the AI
Appendix C. Cryptographic Message Syntax Profile for TAC Token 🧚
Using the Cryptographic Message Syntax (CMS) [6], a TAC Token is a type of signed-data object 🎀. Here's the general format of a CMS object:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIERSince a TAC is a signed-data object, it uses the matching OID, 1.2.840.113549.1.1.2 ✨.
C.1. Signed-Data Content Type 💜
According to the CMS specification, the signed-data content type shall have ASN.1 type SignedData:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfoHere's the breakdown of the signed-data content type elements 👑:
- Version: The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3.
- digestAlgorithms: This field specifies digest Algorithms.
- encapContentInfo: This element is defined in Appendix C.1.1.
- certificates: The certificates element MUST be included and MUST contain only the single PKI EE certificate needed to validate this CMS Object. The CertificateSet type is defined in section 10 of RFC3852 [6].
- crls: The crls element MUST be omitted.
- signerInfos: This element is defined in Appendix C.1.2.
C.1.1. encapContentInfo 🌈
encapContentInfo is the signed content, made up of a content type identifier and the content itself.
EncapsulatedContentInfo ::= SEQUENCE{
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIERHere's how those elements work 🦋:
- eContentType: The ContentType for a TAC Token is id-data and has the numerical value of 1.2.840.113549.1.7.1.
- eContent: The content of a TAC Token is the DER-encoded SEQUENCE of UserKey and Timeout.
C.1.2. signerInfos 🍓
SignerInfo is defined under CMS as:
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }Here's what each SignerInfo element is doing ⭐:
- Version: The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid.
- sid: The sid is defined as:
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }For a TAC Token, the sid MUST be a SubjectKeyIdentifier.
- digestAlgorithm: This field specifies digest Algorithms.
- signedAttrs: The signedAttr element MUST be omitted.
- SignatureAlgorithm: This field specifies the signature Algorithm.
- Signature: The signature value is defined as:
SignatureValue ::= OCTET STRINGThe signature characteristics are defined by the digest and signature algorithms.
- UnsignedAttrs: unsignedAttrs MUST be omitted.
Authors' Addresses 📮
SangHwan Park
Korea Internet & Security Agency
78, Garak-Dong, Songpa-Gu, Seoul, Korea
EMail: shpark@kisa.or.kr
Haeryong Park
Korea Internet & Security Agency
78, Garak-Dong, Songpa-Gu, Seoul, Korea
EMail: hrpark@kisa.or.kr
YooJae Won
Korea Internet & Security Agency
78, Garak-Dong, Songpa-Gu, Seoul, Korea
EMail: yjwon@kisa.or.kr
JaeIl Lee
Korea Internet & Security Agency
78, Garak-Dong, Songpa-Gu, Seoul, Korea
EMail: jilee@kisa.or.kr
Stephen Kent
BBN Technologies
10 Moulton Street Cambridge, MA 02138
EMail: kent@bbn.com📦 where this page comes from
- ietf: rfc5636 2009-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms