OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dss-x] Another streamlining approach to the core

Thanks Pim,

Just for completing the picture: the deprecation of X509IssuerSerial had a direct impact on XAdES, which in its former versions, specified in ETSI TS 101 903, made use of such element in a structure that contained this element plus an element similar to the dsig11:X509Digest, as a way of obtaining two purposes: first to identify a certain certificate (using the X509IssuerSerial), and second incorporate within the signed attributes the digest of the identified certificate as a way of securing it.

In order not to loss the capability of doing both things within the same structure, and given the problems outlined by W3C in the management of int values, the solution in the new XAdES signatures, specified in ETSI EN 319 132 was to use a new element IssuerSerialV2, containing the base-64 encoding of one DER-encoded instance of type IssuerSerial type defined in IETF RFC 5035.


Juan Carlos
El 17/2/17 a las 11:00, Pim van der Eijk escribió:

On 16-02-17 20:00, Andreas Kuehne wrote:
Hi all,

            X509IssuerSerial: well established and dtmo in use widely.

So maybe we can get away with something likes this:

    <xs:complexType name="StreamlinedKeyInfoType">
            <xs:element name="X509IssuerSerial" >
                <complexType name="X509IssuerSerialType" mixed="false">
                        <element name="X509IssuerName" type="string"/>
                        <element name="X509SerialNumber" type="integer"/>

It could be time to align with XML Signature 1.1, https://www.w3.org/TR/xmldsig-core1/ which adds

The dsig11:X509Digest element contains a base64-encoded digest of a certificate. The digest algorithm URI is identified with a required Algorithm attribute. The input to the digest must be the raw octets that would be base64-encoded were the same certificate to appear in the X509Certificate element.

That specification also remind us of the following (which I'm sure we've all encountered from time to time):

X509IssuerSerial element has been deprecated in favor of the newly-introduced dsig11:X509Digest element. The XML Schema type of the serial number was defined to be an integer, and XML Schema validators may not support integer types with decimal data exceeding 18 decimal digits [XMLSCHEMA-2]. This has proven insufficient, because many Certificate Authorities issue certificates with large, random serial numbers that exceed this limit. As a result, deployments that do make use of this element should take care if schema validation is involved. New deployments should avoid use of the element.



Kind Regards,


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]