添加的内容 删除的内容
无编辑摘要 |
小 (机器人:清理不当的来源、移除无用的模板参数) |
||
(未显示3个用户的4个中间版本) | |||
第7行: | 第7行: | ||
| year_started = 1988 |
| year_started = 1988 |
||
| version = 10/19 |
| version = 10/19 |
||
| version_date = |
| version_date = 2019-10 |
||
| preview = |
| preview = |
||
| preview_date = |
| preview_date = |
||
第56行: | 第56行: | ||
* 数字签名 |
* 数字签名 |
||
所有扩展都有一个ID,由[[object identifier]]来表达.它是一个集合,并且有一个标记用与指示这个扩展是不是决定性的。证书使用时,如果发现一份证书带有决定性标记的扩展,而这个系统并不清楚该扩展的用途,那么要拒绝使用它。但对于非决定性的扩展,不认识可以予以忽略。<ref>{{Cite web |url=http://tools.ietf.org/html/rfc5280#section-4.2, |title=RFC 5280 section 4.2, retrieved 12 February 2013 |accessdate=2018-04-28 |
所有扩展都有一个ID,由[[object identifier]]来表达.它是一个集合,并且有一个标记用与指示这个扩展是不是决定性的。证书使用时,如果发现一份证书带有决定性标记的扩展,而这个系统并不清楚该扩展的用途,那么要拒绝使用它。但对于非决定性的扩展,不认识可以予以忽略。<ref>{{Cite web |url=http://tools.ietf.org/html/rfc5280#section-4.2, |title=RFC 5280 section 4.2, retrieved 12 February 2013 |accessdate=2018-04-28 }}</ref> |
||
RFC 1422<ref>[http://www.ietf.org/rfc/rfc1422 RFC 1422]</ref>给出了v1的证书结构 |
RFC 1422<ref>[http://www.ietf.org/rfc/rfc1422 RFC 1422]</ref>给出了v1的证书结构 |
||
ITU-T在v2里增加了颁发者和主题唯一标识符,从而可以在一段时间后可以重用。重用的一个例子是当一个CA破产了,它的名称也在公共列表里清除掉了,一段时间之后另一个CA可以用相同的名称来注册,即使它与之前的并没有任何瓜葛。不过[[IETF]]并不建议重用同名注册。另外v2在Internet也没有多大范围的使用。 |
ITU-T在v2里增加了颁发者和主题唯一标识符,从而可以在一段时间后可以重用。重用的一个例子是当一个CA破产了,它的名称也在公共列表里清除掉了,一段时间之后另一个CA可以用相同的名称来注册,即使它与之前的并没有任何瓜葛。不过[[IETF]]并不建议重用同名注册。另外v2在Internet也没有多大范围的使用。 |
||
第69行: | 第69行: | ||
| title = RFC 5280, Section 'Basic Constraints' |
| title = RFC 5280, Section 'Basic Constraints' |
||
| accessdate = 2018-04-28 |
| accessdate = 2018-04-28 |
||
| archive-date = 2018-03-15 |
|||
| archive-url = https://web.archive.org/web/20180315115721/https://tools.ietf.org/html/rfc5280#section-4.2.1.9 |
|||
| dead-url = no |
|||
}}</ref>用于指定一份证书是不是一个CA证书。 |
}}</ref>用于指定一份证书是不是一个CA证书。 |
||
* Key Usage, <tt>{ id-ce 15 }</tt>,<ref>{{cite web |
* Key Usage, <tt>{ id-ce 15 }</tt>,<ref>{{cite web |
||
第77行: | 第74行: | ||
| title = 'RFC 5280, Section 'Key Usage' |
| title = 'RFC 5280, Section 'Key Usage' |
||
| accessdate = 2018-04-28 |
| accessdate = 2018-04-28 |
||
| archive-date = 2018-03-15 |
|||
| archive-url = https://web.archive.org/web/20180315115721/https://tools.ietf.org/html/rfc5280#section-4.2.1.3 |
|||
| dead-url = no |
|||
}}</ref>指定了这份证书包含的公钥可以执行的密码操作。作为一个例子,它可以指定只能用于签名,而不能用来进行加密操作。 |
}}</ref>指定了这份证书包含的公钥可以执行的密码操作。作为一个例子,它可以指定只能用于签名,而不能用来进行加密操作。 |
||
* Extended Key Usage, <tt>{ id-ce 37 }</tt>,<ref>{{cite web |
* Extended Key Usage, <tt>{ id-ce 37 }</tt>,<ref>{{cite web |
||
第85行: | 第79行: | ||
| title = RFC 5280, Section 'Extended Key Usage' |
| title = RFC 5280, Section 'Extended Key Usage' |
||
| accessdate = 2018-04-28 |
| accessdate = 2018-04-28 |
||
| archive-date = 2018-03-15 |
|||
| archive-url = https://web.archive.org/web/20180315115721/https://tools.ietf.org/html/rfc5280#section-4.2.1.12 |
|||
| dead-url = no |
|||
}}</ref>典型用法是用于叶子证书中的公钥的使用目的。它包括一系列的OID,每一个都指定一种用途。比如<tt>{ id-pkix 3 1 }</tt> 表示用于服务器端的TLS/SSL连接,而<tt>{ id-pkix 3 4 }</tt>用于email的安全操作。 |
}}</ref>典型用法是用于叶子证书中的公钥的使用目的。它包括一系列的OID,每一个都指定一种用途。比如<tt>{ id-pkix 3 1 }</tt> 表示用于服务器端的TLS/SSL连接,而<tt>{ id-pkix 3 4 }</tt>用于email的安全操作。 |
||
通常情况下,一份证书有多个限制用途的扩展时,所有限制条件都应该满足才可以使用。<nowiki>RFC 5280</nowiki>里有对一个同时含有keyUsage和extendedKeyUsage的证书的例子,这样的证书只能用在两个扩展中都指定了的用途。比如[[网络安全服务]]决定证书用途时会同时对这两个扩展进行判断<ref>[https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3 All About Certificate Extensions]</ref> |
通常情况下,一份证书有多个限制用途的扩展时,所有限制条件都应该满足才可以使用。<nowiki>RFC 5280</nowiki>里有对一个同时含有keyUsage和extendedKeyUsage的证书的例子,这样的证书只能用在两个扩展中都指定了的用途。比如[[网络安全服务]]决定证书用途时会同时对这两个扩展进行判断<ref>[https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3 All About Certificate Extensions]</ref> |
||
第109行: | 第100行: | ||
| url = http://tools.ietf.org/html/rfc5280#page-71 |
| url = http://tools.ietf.org/html/rfc5280#page-71 |
||
| access-date = 2018-04-28 |
| access-date = 2018-04-28 |
||
| archive-date = 2018-03-15 |
|||
| archive-url = https://web.archive.org/web/20180315115721/https://tools.ietf.org/html/rfc5280#page-71 |
|||
| dead-url = no |
|||
}}</ref>是从终端使用者证书后跟着一系列的CA证书,而通常最后一个是自签名证书,并且有如下关系: |
}}</ref>是从终端使用者证书后跟着一系列的CA证书,而通常最后一个是自签名证书,并且有如下关系: |
||
# 在证书链上除最后一个证书外,证书颁发者等于其后一个证书的主题。 |
# 在证书链上除最后一个证书外,证书颁发者等于其后一个证书的主题。 |
||
第128行: | 第116行: | ||
{{cite book |
{{cite book |
||
|title=Understanding Certification Path Construction |
|title=Understanding Certification Path Construction |
||
|date= |
|date=2002-09 |
||
|publisher=PKI Forum |
|publisher=PKI Forum |
||
|last=Lloyd |
|last=Lloyd |
||
第147行: | 第135行: | ||
{{cite book |
{{cite book |
||
|title=Qualified Subordination Deployment Scenarios |
|title=Qualified Subordination Deployment Scenarios |
||
|date= |
|date=2009-08 |
||
|publisher=Microsoft |
|publisher=Microsoft |
||
|section=Cross-Certification Between Root CAs |
|section=Cross-Certification Between Root CAs |
||
第158行: | 第146行: | ||
=== 例2: CA证书更新 === |
=== 例2: CA证书更新 === |
||
{{cite book |
|||
|title=Understanding Certification Path Construction |
|||
|date=September 2002 |
|||
|publisher=PKI Forum |
|||
|url=http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf |
|||
|quote=为了证书颁发者从旧的私钥順利地转移到新的私钥,他可以颁发两个证书,其中一个是新的私钥对旧的公钥进行签名,另一个是旧的私钥对新的公钥的签名,这两个都是机构自己给自己颁发的证书,但都不是自签名证书。注:另外还存在新旧两个自签名证书。 |
|||
}} |
|||
假设cert1和cert3具有相同的公钥,对于cert5来说有两条合法的证书链,cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情况也类似。这样就允许老的用户证书可以在新旧两个根证书之间平滑转移。<ref name=" PKI Implementing and Managing E-Security"> |
假设cert1和cert3具有相同的公钥,对于cert5来说有两条合法的证书链,cert5 → cert1 和 cert5 → cert3 → cert2, cert6的情况也类似。这样就允许老的用户证书可以在新旧两个根证书之间平滑转移。<ref name=" PKI Implementing and Managing E-Security"> |
||
{{cite book |
{{cite book |
||
第178行: | 第158行: | ||
|section=Key and Certificate Life Cycles. CA Certificate Renewal |
|section=Key and Certificate Life Cycles. CA Certificate Renewal |
||
}} |
}} |
||
</ref> |
</ref><ref>{{cite book |
||
|title=Understanding Certification Path Construction |
|||
|date=2002-09 |
|||
== X.509证书样例 == |
|||
|publisher=PKI Forum |
|||
下面是[[GlobalSign]]颁发的用于wikipedia.org以及一些其它Wikipedia网站X.509证书。证书颁发者填在颁发者(Issuer)字段,主题内容里是组织机构Wikipedia的描述,主题备用名称是那些采用该证书的服务器的主机名。主题公钥里的信息表明采用的是[[椭圆曲线]]公共密钥,位于最后的签名算法表示它是由GlobalSign用其私钥并采用带[[RSA]]加密的SHA-256算法进行签名的。 |
|||
|url=http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf |
|||
|quote=为了证书颁发者从旧的私钥順利地转移到新的私钥,他可以颁发两个证书,其中一个是新的私钥对旧的公钥进行签名,另一个是旧的私钥对新的公钥的签名,这两个都是机构自己给自己颁发的证书,但都不是自签名证书。注:另外还存在新旧两个自签名证书。 |
|||
=== 最终實體證書(或者叫叶子证书) === |
|||
}}</ref> |
|||
認證: |
|||
版本: 3 (0x2) |
|||
序號: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 |
|||
簽章演算法: sha256WithRSAEncryption |
|||
發行者: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 |
|||
有效期開始時間: Nov 21 08:00:00 2016 GMT |
|||
有效期結束時間: Nov 22 07:59:59 2017 GMT |
|||
主體: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org |
|||
主體公鑰信息(subject public key info): |
|||
公鑰算法: id-ecPublicKey |
|||
256位的公鑰: |
|||
04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5: |
|||
af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e: |
|||
ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7: |
|||
c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6: |
|||
9d:3b:ef:d5:c1 |
|||
ASN1 OID: prime256v1 |
|||
NIST CURVE: P-256 |
|||
額外資訊(extension): |
|||
密鑰使用: |
|||
敏感訊息(critical):是 |
|||
公鑰用途:數位簽章,密鑰協商Key Agreement |
|||
授權相關訊息: |
|||
敏感訊息(critical):否 |
|||
頒發者URI:<nowiki>http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt</nowiki> |
|||
線上憑證狀態協定(OCSP)URI:<nowiki>http://ocsp2.globalsign.com/gsorganizationvalsha2g2</nowiki> |
|||
證書原則(Certificate Policies): |
|||
敏感訊息(critical):否 |
|||
policy ID#1: 1.3.6.1.4.1.4146.1.20 |
|||
CPS URI: <nowiki>https://www.globalsign.com/repository/</nowiki> |
|||
policy ID#2: 2.23.140.1.2.2 |
|||
基本限制: |
|||
CA:FALSE |
|||
憑證撤銷中心(X509v3 CRL Distribution Points): |
|||
敏感訊息(critical):否 |
|||
URI:<nowiki>http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl</nowiki> |
|||
主體備用名稱: |
|||
敏感訊息(critical):否 |
|||
DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org |
|||
(在額外訊息中的)密鑰使用目的: |
|||
敏感訊息(critical):否 |
|||
目的1:TLS Web伺服器鑑定 |
|||
目的2:TLS Web客户端鑑定 |
|||
主體密鑰識別代碼(Subject Key Identifier): |
|||
敏感訊息(critical):否 |
|||
密鑰id: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 |
|||
授權密鑰識別代碼(X509v3 Authority Key Identifier): |
|||
敏感訊息(critical):否 |
|||
密鑰id:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C |
|||
簽章算法: sha256WithRSAEncryption |
|||
數位簽章: 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35: |
|||
... |
|||
要验证这个证书,我们需要一个跟该证书颁发者及授权密钥标识符 |
|||
{| class="wikitable" |
|||
|颁发者 |
|||
|C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 |
|||
|- |
|||
|授权密钥标识符 |
|||
|96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C |
|||
|}都匹配的中间证书 |
|||
配置正确的服务器可以在TLS连接建立的握手阶段同时提供其中间证书。但是也有可能需要根据证书里颁发者的URL去取得中间证书。 |
|||
=== 中间证书 === |
|||
下面是[[证书颁发机构]]的证书示例。该证书是由下例根证书签名的用于颁发上例最终实体证书的证书。当然它的主题标识符跟上例证书的授权密钥标识符是相匹配的。 |
|||
证书: |
|||
版本: 3 (0x2) |
|||
序列号: 04:00:00:00:00:01:44:4e:f0:42:47 |
|||
签名算法: sha256WithRSAEncryption |
|||
颁发者: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA |
|||
此前无效: Feb 20 10:00:00 2014 GMT |
|||
此后无效: Feb 20 10:00:00 2024 GMT |
|||
主题: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2 |
|||
主题公钥信息: |
|||
公钥算法: rsaEncryption |
|||
2048位的公钥: |
|||
00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e: |
|||
... |
|||
指数: 65537 (0x10001) |
|||
X509 v3扩展: |
|||
X509v3 密钥使用: |
|||
关键:是 |
|||
用于:证书签名, CRL签名 |
|||
基本约束: |
|||
关键:是 |
|||
证书颁发机构:是 |
|||
路径长度限制:0 |
|||
主题密钥标识符: |
|||
关键:否 |
|||
密钥: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C |
|||
96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C |
|||
证书策略: |
|||
关键:否 |
|||
策略1: 任何策略标识符 |
|||
CPS URI: <nowiki>https://www.globalsign.com/repository/</nowiki> |
|||
CRL 分发点: |
|||
关键:否 |
|||
URI:<nowiki>http://crl.globalsign.net/root.crl</nowiki> |
|||
授权相关信息: |
|||
关键:否 |
|||
在线证书状态协议(OCSP)URI:<nowiki>http://ocsp.globalsign.com/rootr1</nowiki> |
|||
授权密钥标识符: |
|||
关键:否 |
|||
密钥:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B |
|||
签名算法: sha256WithRSAEncryption |
|||
数字签名:46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8: |
|||
... |
|||
=== 根证书 === |
|||
下面是证书颁发机构的自签名根证书。它的颁发者和主题是相同的,可以用自身的公钥进行合法认证。证书认证过程也将在此终止。如果应用已经在它的可信公钥存贮里已经含有该公钥证书,那么TLS连接时的那个最终实体证书是可信的,否则就是不可信的。 |
|||
证书: |
|||
版本: 3 (0x2) |
|||
序列号: 04:00:00:00:00:01:15:4b:5a:c3:94 |
|||
Signature Algorithm: sha1WithRSAEncryption |
|||
Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA |
|||
Validity |
|||
Not Before: Sep 1 12:00:00 1998 GMT |
|||
Not After : Jan 28 12:00:00 2028 GMT |
|||
Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA |
|||
Subject Public Key Info: |
|||
Public Key Algorithm: rsaEncryption |
|||
Public-Key: (2048 bit) |
|||
Modulus: |
|||
00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b: |
|||
... |
|||
Exponent: 65537 (0x10001) |
|||
X509v3 extensions: |
|||
X509v3 Key Usage: critical |
|||
Certificate Sign, CRL Sign |
|||
X509v3 Basic Constraints: critical |
|||
CA:TRUE |
|||
X509v3 Subject Key Identifier: |
|||
60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B |
|||
Signature Algorithm: sha1WithRSAEncryption |
|||
d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5: |
|||
... |
|||
== 安全性 == |
== 安全性 == |
||
第339行: | 第174行: | ||
| publisher = Computer Security Journal (Volume XVI, Number 1, 2000) |
| publisher = Computer Security Journal (Volume XVI, Number 1, 2000) |
||
| accessdate = 2018-04-28 |
| accessdate = 2018-04-28 |
||
| archive-date = 2015-11-24 |
|||
| archive-url = https://web.archive.org/web/20151124191828/https://www.schneier.com/paper-pki.pdf |
|||
| dead-url = yes |
|||
}}</ref><ref name="pkinotdead">{{cite web |
}}</ref><ref name="pkinotdead">{{cite web |
||
| url = http://www.cs.auckland.ac.nz/~pgut001/pubs/notdead.pdf |
| url = http://www.cs.auckland.ac.nz/~pgut001/pubs/notdead.pdf |
||
第348行: | 第180行: | ||
| publisher = IEEE Computer (Volume:35, Issue: 8) |
| publisher = IEEE Computer (Volume:35, Issue: 8) |
||
| accessdate = 2018-04-28 |
| accessdate = 2018-04-28 |
||
| archive-date = 2018-01-29 |
|||
| archive-url = https://web.archive.org/web/20180129075349/https://www.cs.auckland.ac.nz/~pgut001/pubs/notdead.pdf |
|||
| dead-url = no |
|||
}}</ref><ref name="gutmann1">{{cite web |
}}</ref><ref name="gutmann1">{{cite web |
||
|last=Gutmann |
|last=Gutmann |
||
第356行: | 第185行: | ||
|title=Everything you Never Wanted to Know about PKI but were Forced to Find Out |
|title=Everything you Never Wanted to Know about PKI but were Forced to Find Out |
||
|url=http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf |
|url=http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf |
||
|accessdate= |
|accessdate=2011-11-14 |
||
|archive-url=https://web.archive.org/web/20110607040159/http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf |
|||
|archive-date=2011-06-07 |
|||
|dead-url=yes |
|||
}}</ref> |
}}</ref> |
||
=== 架构的弱点 === |
=== 架构的弱点 === |
||
* 采用黑名单方式的证书吊销列表([[证书吊销列表|CRL]])和在线证书状态协议([[OCSP]]) |
* 采用黑名单方式的证书吊销列表([[证书吊销列表|CRL]])和在线证书状态协议([[OCSP]]) |
||
** 如果客户端仅信任在CRL可用的时候信任证书,那就失去离线信任的需求。因此通常客户端会在CRL不可用的情况下信任证书,因而给了那些可以控制信道的攻击者可乘之机。如谷歌的Adam Langley所说,对CRL的检查就像在关键时刻断开的安全带<ref>{{cite web|last1=Langley|first1=Adam|title=Revocation checking and Chrome's CRL (05 Feb 2012)|url=https://www.imperialviolet.org/2012/02/05/crlsets.html|website=Imperial Violet|accessdate= |
** 如果客户端仅信任在CRL可用的时候信任证书,那就失去离线信任的需求。因此通常客户端会在CRL不可用的情况下信任证书,因而给了那些可以控制信道的攻击者可乘之机。如谷歌的Adam Langley所说,对CRL的检查就像在关键时刻断开的安全带<ref>{{cite web|last1=Langley|first1=Adam|title=Revocation checking and Chrome's CRL (05 Feb 2012)|url=https://www.imperialviolet.org/2012/02/05/crlsets.html|website=Imperial Violet|accessdate=2017-02-02}}</ref> |
||
* 在大范围及复杂的分布模式下选用CRL并不明智 |
* 在大范围及复杂的分布模式下选用CRL并不明智 |
||
* OCSP由于没有吊销状态的历史记录也会出现歧义 |
* OCSP由于没有吊销状态的历史记录也会出现歧义 |