dogtagpki

#2284 CMC CRMF parsing incorrect
Closed: migrated by dmoluguw. Opened by roysjosh@gmail.com.

Closed: migrated
Reopen Issue

In attempting to integrate a custom CMC PKCS10/CRMF application with a production Dogtag PKI system, a disparity between Dogtag and the RFCs was noticed in the CRMF request handling.

A quick look through git didn't show many changes in the CMC/CRMF request handling so the issue likely still applies to git HEAD.

How reproducible:

Following RFC 5272 and 4211 I generated a PKIData ASN.1 structure as follows:
    0:d=0  hl=4 l= 515 cons: SEQUENCE          ; PKIData
    4:d=1  hl=2 l=   0 cons:  SEQUENCE          ; controlSequence
    6:d=1  hl=4 l= 505 cons:  SEQUENCE          ; reqSequence
   10:d=2  hl=4 l= 501 cons:   cont [ 1 ]        ; TaggedRequest: crm
   14:d=3  hl=4 l= 497 cons:    SEQUENCE          ; CertReqMsg
   18:d=4  hl=4 l= 493 cons:     SEQUENCE          ; CertRequest
   22:d=5  hl=2 l=   1 prim:      INTEGER           :01 ; certReqId
   25:d=5  hl=4 l= 484 cons:      SEQUENCE          ; CertTemplate
   29:d=6  hl=3 l= 135 cons:       cont [ 5 ]        ; subject
   32:d=7  hl=3 l= 132 cons:        SEQUENCE          
   35:d=8  hl=2 l=  11 cons:         SET              
   37:d=9  hl=2 l=   9 cons:          SEQUENCE          
   39:d=10 hl=2 l=   3 prim:           OBJECT            :countryName
   44:d=10 hl=2 l=   2 prim:           PRINTABLESTRING   :US
[...]
  129:d=8  hl=2 l=  36 cons:         SET              
  131:d=9  hl=2 l=  34 cons:          SEQUENCE          
  133:d=10 hl=2 l=   3 prim:           OBJECT            :commonName
  138:d=10 hl=2 l=  27 prim:           PRINTABLESTRING   :Business President PERSON-1
  167:d=6  hl=4 l= 294 cons:       cont [ 6 ]        ; publicKey
  171:d=7  hl=4 l= 290 cons:        SEQUENCE          ; SubjectPublicKeyInfo
  175:d=8  hl=2 l=  13 cons:         SEQUENCE          
  177:d=9  hl=2 l=   9 prim:          OBJECT            :rsaEncryption
  188:d=9  hl=2 l=   0 prim:          NULL              
  190:d=8  hl=4 l= 271 prim:         BIT STRING        
  465:d=6  hl=2 l=  46 cons:       cont [ 9 ]        ; extensions
  467:d=7  hl=2 l=  44 cons:        SEQUENCE          
  469:d=8  hl=2 l=  14 cons:         SEQUENCE          
  471:d=9  hl=2 l=   3 prim:          OBJECT            :X509v3 Key Usage
  476:d=9  hl=2 l=   1 prim:          BOOLEAN           :255
  479:d=9  hl=2 l=   4 prim:          OCTET STRING      [HEX DUMP]:03020780
  485:d=8  hl=2 l=  26 cons:         SEQUENCE          
  487:d=9  hl=2 l=   3 prim:          OBJECT            :X509v3 Subject Alternative Name
  492:d=9  hl=2 l=  19 prim:          OCTET STRING      [HEX DUMP]:...
  513:d=5  hl=2 l=   0 cons:      SEQUENCE          ; controls
  515:d=1  hl=2 l=   0 cons:  SEQUENCE          ; cmsSequence
  517:d=1  hl=2 l=   0 cons:  SEQUENCE          ; otherMsgSequence

Actual results:

The CMC CRMF request is not accepted until I match the CRMF generated by the PKI CLI tools (CRMFPopClient, CMCRequest, etc).  That is, I need to strip out the CertReqMsg SEQUENCE and the SubjectPublicKeyInfo SEQUENCE as follows:
    0:d=0  hl=4 l=1196 cons: SEQUENCE          
    4:d=1  hl=2 l=   0 cons:  SEQUENCE          
    6:d=1  hl=4 l=1186 cons:  SEQUENCE          
   10:d=2  hl=4 l=1182 cons:   cont [ 1 ]        
   14:d=3  hl=4 l=1178 cons:    SEQUENCE          ; XXX note the missing SEQUENCE here!!!
   18:d=4  hl=2 l=   1 prim:     INTEGER           :01
   21:d=4  hl=3 l= 183 cons:     SEQUENCE          
   24:d=5  hl=2 l=   1 prim:      cont [ 0 ]        
   27:d=5  hl=2 l=  16 cons:      cont [ 5 ]        
   29:d=6  hl=2 l=  14 cons:       SEQUENCE          
   31:d=7  hl=2 l=  12 cons:        SET              
   33:d=8  hl=2 l=  10 cons:         SEQUENCE          
   35:d=9  hl=2 l=   3 prim:          OBJECT            :commonName
   40:d=9  hl=2 l=   3 prim:          PRINTABLESTRING   :bar
   45:d=5  hl=3 l= 159 cons:      cont [ 6 ]        
   48:d=6  hl=2 l=  13 cons:       SEQUENCE          ; XXX note the missing SEQUENCE here!!!
   50:d=7  hl=2 l=   9 prim:        OBJECT            :rsaEncryption
   61:d=7  hl=2 l=   0 prim:        NULL              
   63:d=6  hl=3 l= 141 prim:       BIT STRING        
  207:d=4  hl=4 l= 985 cons:     SEQUENCE          
  211:d=5  hl=4 l= 947 cons:      SEQUENCE          
  215:d=6  hl=2 l=   9 prim:       OBJECT            :id-regCtrl-pkiArchiveOptions
  226:d=6  hl=4 l= 932 cons:       cont [ 0 ]        
  230:d=7  hl=4 l= 928 cons:        SEQUENCE          
  234:d=8  hl=2 l=  20 cons:         cont [ 1 ]        
  236:d=9  hl=2 l=   8 prim:          OBJECT            :des-ede3-cbc
  246:d=9  hl=2 l=   8 prim:          OCTET STRING      [HEX DUMP]:0101010101010101
  256:d=8  hl=4 l= 257 prim:         cont [ 2 ]        
  517:d=8  hl=4 l= 641 prim:         BIT STRING        
 1162:d=5  hl=2 l=  32 cons:      SEQUENCE          
 1164:d=6  hl=2 l=   8 prim:       OBJECT            :id-cmc-popLinkWitness
 1174:d=6  hl=2 l=  20 prim:       OCTET STRING      [HEX DUMP]:E669C95F2EFFA490AE73E644CC3F9E1D96779C50
 1196:d=1  hl=2 l=   0 cons:  SEQUENCE          
 1198:d=1  hl=2 l=   0 cons:  SEQUENCE          
This structure was directly generated by the CRMFPopClient and accepted by the server.  All other requests fail with "Invalid Credential." in a CMC response.

Expected results:

RFC compliance (or a better understanding of ASN.1 if someone would like to correct me :)

Per CS Bug/Ticket Triage held 04/19/2016: 10.4

Metadata Update from @roysjosh@gmail.com:
- Issue set to the milestone: UNTRIAGED

Metadata Update from @mharmsen:
- Custom field feature adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field version adjusted to None
- Issue close_status updated to: None
- Issue set to the milestone: 10.5 (was: UNTRIAGED)

[20171025] - Offline Triage ==> 10.6

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.6 (was: 10.5)

Per 10.5.x/10.6 Triage: 10.5

cfu needs to verify if this has already been fixed

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5 (was: 10.6)

Metadata Update from @mharmsen:
- Issue assigned to cfu

Metadata Update from @mharmsen:
- Issue priority set to: critical (was: major)

Per 10.5.x/10.6 Triage: 10.5

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2404

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
Low
defect
General
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.