现行的电子发票有OFD,PDF,XML三种格式,其中PDF用于查看,不能用于信息交换和作为凭证。OFD相对比较规范,但也存在格式复杂,使用存在一定的不便之处,尤其是内部内容全部签名,技术上并不先进。XML格式简单,便于数据交换,校验成本低,也便于人工简单查看。 但存在非常奇怪的技术问题。 下面加以详细讲解,请各位朋友点评,希望不是妄言。
1.样本是一个裁剪的样本发票概要数据,可以说明问题。
内容如下:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<EInvoice> (1)
<Header>
<EIid>23612000xxxxxxx98485</EIid>
<EInvoiceTag>xxxx</EInvoiceTag>
.....
</Header>
<EInvoiceData> (2)
<SellerInformation>
....
</SellerInformation>
<BuyerInformation>
.....
</BuyerInformation>
<AdditionalInformation/>
</EInvoiceData>
<SellerAuthentication>
<AuthenticationMethods>01</AuthenticationMethods>
</SellerAuthentication>
<TaxSupervisionInfo>
....
</TaxSupervisionInfo>
<TaxBureauSignature>
<Reference URI="/Einvoice/Header|/Einvoice/EinvoiceData|/Einvoice/SellerAuthentication|/Einvoice/TaxSupervisionInfo|/Einvoice/TaxBureauSignature/SignatureTime"/>
<SignatureAlgorithm>1.2.156.10197.1.501</SignatureAlgorithm>
<SignatureFormat>DETACH</SignatureFormat>
<SignatureTime>2023-09-26 09:59:04</SignatureTime>
<SignatureValue>3xx......5000&MjAyMzA5MjYgMDk1OTA0</SignatureValue>
<KeyInfo/>
</TaxBureauSignature>
</EInvoice>
2.问题分析 我们具体来看
A. (1) (2) 处标签为 EInvoice,EInvoiceData 而 <Reference URI="/Einvoice/Header|/Einvoice/EinvoiceData 全部为第二个字母小写,导致整个文档失效,无法有效提取数据,进行签名和验签。
B. <SignatureFormat>DETACH</SignatureFormat> 记录为独立式签名( DETACH ) 但是实际XML明显不是,实际是 封装式签名(Enveloped),签名数据镶嵌于原始数据之内 。
C. 按照XML签名国家标准 <Reference URI="/Einvoice/Header|.... />"> 不允许这样写。 要么是全部文档,要么是一个"#xxxx",总而言之,就是只能选择出一个带有顶节点的节点集合,否则按照规范,无法进行签名。
D. 假设其 URI 合理,那么 Reference 中的 Einvoice/TaxBureauSignature/SignatureTime 也是错误的。原因是无论何种方式签名,最后的节点
不可能是 <TaxBureauSignature><SignatureTime>
只能是 <SignatureTime>
原因是SelectNode 选择的时候不会带有父级节点的
E. Reference URI 指向的是待签名的内容,不能签名后的数据 <SignatureTime>xx</SignatureTime> 这个 放在完全就是胡来了
F. 签名数据莫名其妙 <SignatureValue>3xx......5000&MjAyMzA5MjYgMDk1OTA0</SignatureValue>
注意看 在正式的 SignatureValue 数据后添加了 &MjAyMzA5MjYgMDk1OTA0 这东西 解码后是 &20230926 095904 看起来是个时间,问题是你放这里合适吗?
总体而言,XML 发票,技术问题很大。