2017-04-24 168 views
1

我想用JSCEP與屬性證書(ACS),他們是X.509的一部分。當我檢查Java庫時。在java.security.cert封裝的抽象X509Certificate包含但此證書繼承java.security.cert.Certificate一個getPublicKey方法,該方法不是一個交流的一部分。JSCEP與x509證書和屬性證書

我的問題:

  • 請問X509Certificate不公鑰使用。那麼在JcaX509CertificateConverter等其他java類中不會出現問題?
  • 我應該實現自己的AttributeCertificate類,它不從java.security.cert.Certificate繼承?
  • 什麼是最佳實踐方法?

回答

4

X509Certificate類表示公鑰證書(PKC),而一個屬性證書(AC),雖然這是一個類似(但不是很多)結構,沒有公共密鑰。他們不是一回事。

一個X509Certificate離不開公鑰使用,因爲關鍵是它的一部分。如果您在RFC's definition看一看,你會發現這是一個必填字段:

Certificate ::= SEQUENCE { 
    tbsCertificate  TBSCertificate, 
    signatureAlgorithm AlgorithmIdentifier, 
    signatureValue  BIT STRING } 

TBSCertificate ::= SEQUENCE { 
    ... lots of fields... 
    subjectPublicKeyInfo SubjectPublicKeyInfo, 
    ... } 

SubjectPublicKeyInfo ::= SEQUENCE { 
    algorithm   AlgorithmIdentifier, 
    subjectPublicKey  BIT STRING } 

公鑰也是PKC的定義的一部分:東西結合的身份和公鑰,爲stated in the RFC

...公鑰證書,這是結合 公共密鑰值的受試者的數據結構


屬性證書this RFC定義,它告訴從PKC的差異:

有些人不斷地混淆PKCS和AC。一個類比可能會使 的區別變得清晰。一個PKC可以被認爲是像 護照:它可以標識持有者,往往會持續很長一段時間, ,不應該是微不足道的獲得。交流更像是一個條目 簽證:它通常由不同機構頒發的,並且不 最後,只要時間。由於獲得入境簽證通常需要出示護照,因此獲得簽證可以是更簡單的 程序。

在同一個頁面上,你可以看到,AC's structure是從PKC很大的不同,所以交流的實現不應該X509Certificate繼承。雖然有一些類似的領域,但我認爲它們並不足以證明繼承是正確的(並且它們也有不同的目的和用途,這使我完全放棄了繼承)。

你的情況最好的方法:我建議使用現有的實現。 BouncyCastle is one of them。如果您不能使用外部庫,則可以使用BouncyCastle's code作爲參考。

+0

非常感謝你的這個好的答案。你知道bouncycastle是否實施了一個協議來管理像SCEP這樣的AC嗎? –

+0

好吧,有一個'X509v2AttributeCertificateBuilder'類,我認爲你可以使用它(不知道是否有比這更完整的東西)。我找到了一個示例代碼[here](https://github.com/bcgit/bc-java/blob/master/misc/src/main/java/org/bouncycastle/jcajce/examples/AttrCertExample.java) – 2017-04-25 19:51:51

+0

非常感謝你! –