Location of signature algorithm

[xipki]

In the current draft (-07), the signature algorithm is at the end of TBSCertificate. This does not allow the so-called one-pass signature verification. To verify the signature, one has to first parse the whole TBSCertificate to get the signature algorithm, and then come back to the begin of TBSCertificate.

A better structure is to put the signature algorithm after the c509CertificateType, namely the TBSCertificate shall be changed from

TBSCertificate = (
   c509CertificateType: int,
   certificateSerialNumber: CertificateSerialNumber,
   ...,
   issuerSignatureAlgorithm: AlgorithmIdentifier,
)

to

TBSCertificate = (
   c509CertificateType: int,
   issuerSignatureAlgorithm: AlgorithmIdentifier,
   certificateSerialNumber: CertificateSerialNumber,
   ...,
)

For Certificate, Certificate Request ad OCSP, due to the small size, this overhead may be still acceptable. But for the following CRL structure, the overhead is inacceptable, since the revokedCertificates may be very large.

TBSCertificateSigningRequest = (
   C509CertificateRevocationListType: int,
   ...
   revokedCertificates: RevokedCertificates,
   ...
   issuerSignatureAlgorithm: AlgorithmIdentifier,
)

Note that in the X.509 Certificate, the signature algorithm is at the beginning of TBSCertificate.

[emanjon]

Ok so the problem is that you need issuerSignatureAlgorithm before parsing. That makes sense.

Aligning with RFC5280 the signature algorithm would be in these two locations:

    C509Certificate = [
       TBSCertificate,
       **issuerSignatureAlgorithm: AlgorithmIdentifier,**
       issuerSignatureValue : any,
    ]

    ; The elements of the following group are used in a CBOR Sequence:
    TBSCertificate = (
       c509CertificateType: int,
       certificateSerialNumber: CertificateSerialNumber,
       **issuerSignatureAlgorithm: AlgorithmIdentifier,**
       issuer: Name,
       validityNotBefore: Time,
       validityNotAfter: Time,
       subject: Name,
       subjectPublicKeyAlgorithm: AlgorithmIdentifier,
       subjectPublicKey: any,
       extensions: Extensions,
    )

Goal: One pass processing for verification and X509 -> C509 processing Do the signature algorithm need to be covered by the signature?

[highlunder]

We propose the following, from

Old:

; The elements of the following group are used in a CBOR Sequence:
TBSCertificate = (
   c509CertificateType: int,
   certificateSerialNumber: CertificateSerialNumber,
   issuer: Name,
   validityNotBefore: Time,
   validityNotAfter: Time,
   subject: Name,
   subjectPublicKeyAlgorithm: AlgorithmIdentifier,
   subjectPublicKey: any,
   extensions: Extensions,
   **issuerSignatureAlgorithm: AlgorithmIdentifier,**
)

To

TBSCertificate = (
       c509CertificateType: int,
       certificateSerialNumber: CertificateSerialNumber,
       **issuerSignatureAlgorithm: AlgorithmIdentifier,**
       issuer: Name,
       validityNotBefore: Time,
       validityNotAfter: Time,
       subject: Name,
       subjectPublicKeyAlgorithm: AlgorithmIdentifier,
       subjectPublicKey: any,
       extensions: Extensions,
    )

Since this would achieve the desired one-pass functionality. The sign.alg is also covered by the signature.

[xipki]

I would like to have the issuerSignatureAlgorithm direct after c509CertificateType to save the unnecessary parsing of certificateSerialNumber.

[highlunder]

We have a slight preference for keeping the structure aligned with existing x.509 structures, so we suggest taking this issue to the wider ietf audience.

[gselander]

Comments from the WG in this thread: https://mailarchive.ietf.org/arch/msg/cose/r5znNRvkOgeBdAsKFimzsZBmXSM/

[emanjon]

PR #153 implements all the agreements from the COSE WG session in Brisbane. Should be ready to merge as soon as a new signature has been calculated for the native cert example.

[highlunder]

Closing as the PR has been approved