Subject: Re: [Anima] [Anima-bootstrap] Voucher signing method

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Apr 2017 00:51:30 +0000

Hi Max,

I'd like to reproduce your experiment, but I can't find a library
that supports the 'x5c' header.  What do you mean that you added
it (the x5c header) to the JWS?

Separately, I don't think "-----BEGIN CERTIFICATE-----" is valid
for the 'domain-cert-trusted-ca' field, for which the YANG in 
the voucher-02 draft says is a "binary" type field called 
'trusted-ca-certificate'.  If it's type binary, then it's 
encoded as just the base64 of the DER, with no PEM header/footer
ceremony. See here:

https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-6.6.

Kent

-----ORIGINAL MESSAGE-----

Folks, in Chicago we discussed the signing method for vouchers. 

Because the voucher is JSON, and there is expectation of a CBOR encoding for future work, there is an open discussion point about using the JWS/COSE signing methods; if not JWT/CWT. There was brief discussion of this at IETF98 and one person indicated they liked PKCS7, others indicates JWT and others did not speak up. Fully meeting minutes might provide more information but my recollection was that we’d move the discussion to the list. This thread is for that discussion. 

The current text of draft-ietf-anima-voucher-02 is:

> The voucher is signed a PKCS#7 SignedData structure, as specified by Section 9.1
> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690.

For concrete discussion, the proposed change is:

> The voucher is a JWT [RFC7519] signed token.

I’ve updated my tooling that was used during the IETF98 hackathon to support a JWT token format; I did this as homework to be informed for the discussion. 

MY POSITION: is that I appreciate the simplicity of the JWS signing and feel it is a good match for us. It was easy enough to implement, was a refreshing change from the ASN1 complexity of PKCS7, and seems to provide a good path toward CBOR/COSE in a future document without maintaining PKCS7/CMS technical debt or revisiting/rewriting too much. 

QUESTION FOR THE WORKING GROUP: What is your position? Why? 

What follows is a dump of the raw JWS before signing (the equivalent PKCS7/CMS structure would be the SignedData asn1 structures which is hard to capture). After that is an encoded and signed voucher. Further below is an example of a PKCS7 signed voucher. 

Please note these characteristics:

a) From JWT RFC7519 "JWTs are always represented using the JWS Compact Serialization”. There are some JWT headers that overlap with voucher fields. I’m using JWT here; but the distinction between JWS/JWT is not fundamental to our discussion. The important point is JWS vs PKCS7. 

b) I’ve added the x5c header to the JWS. This is used to carry the certificate chain of the signer. Our current voucher format indicates PKCS7 which supports an equivalent field called “CertificateSet structure”. Its in the BRSKI document that we specify "The entire certificate chain, up to and including the Domain CA, MUST be included in the CertificateSet structure”. With the transition to JWT we’d be specifying that the x5c header be fully populated up to an including the Domain CA etc. 

c) From these examples we can’t directly compare size encodings. I don’t think this is a significant aspect of the conversation but can create comparable examples if folks feel that is necessary. 

The dumps:

A debug dump of the JWT form before encoding:
{
   "typ": "JWT",
   "alg": "ES256",
   "x5c": ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug", "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNVHQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA76kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDBHIx18"]
}
.
{
   "ietf-voucher:voucher": {
       "assertion": "logging",
       "domain-cert-trusted-ca": "-----BEGIN CERTIFICATE-----\nMIIBUjCB+qADAgECAgkAwP4qKsGyQlYwCgYIKoZIzj0EAwIwFzEVMBMGA1UEAwwM\nZXN0RXhhbXBsZUNBMB4XDTE3MDMyNTIyMTc1MFoXDTE4MDMyNTIyMTc1MFowFzEV\nMBMGA1UEAwwMZXN0RXhhbXBsZUNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE\nRVrNlEN2ocYscAILBU7NggABo0JgA1rEGdYdCQj1nHKL6xKONJIUfBibe6iMVYd3\nRUmPwaPiHNZJ98kRwHIwnKMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQU+dVX\naXoucU1godNF0bycS1U5W54wCgYIKoZIzj0EAwIDRwAwRAIgNsCGjpEjuvz6OKJ/\n3rOvMc2ZfDhD02K+0PCVFJGCQGwCIAzf3BS6x9kKSROJJvxDSpg0QK9+b9LSFkbZ\nM1PW98AN\n-----END CERTIFICATE-----\n",
       "nonce": "ea7102e8e88f119e",
       "serial-number": "PID:1 SN:widget1",
       "serial-number-issuer": "36097E3DEA39316EA4CE5C695BE905E78AF2FB5A",
       "version": "1"
   }
}
.
[signature goes here]

As per JWT RFC7519 this is what it looks like after URL-safe encoding. You can see that now the signature is included  (look to the second to last line to see the second “.” followed by a valid signature): 

eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsICAgICJ4NWMiOlsiTUlJQmRqQ0NBUjJnQXdJQkFnSUJBVEFLQmdncWhrak9QUVFEQWpBck1SWXdGQVlEVlFRS0RBMURhWE5qYnlCVGVYTjBaVzF6TVJFd0R3WURWUVFEREFoV1pXNWtiM0pEUVRBZUZ3MHhOekEwTURNeE5URTFORFZhRncweE9EQTBNRE14TlRFMU5EVmFNQzB4RmpBVUJnTlZCQW9NRFVOcGMyTnZJRk41YzNSbGJYTXhFekFSQmdOVkJBTU1DbFpsYm1SdmNrMUJVMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ5R1RyRGQwR1dnd2N1U3k4TENuMHdhTWVrbnBMem5halp6cVdsTGhyUHdzaGdJUElQdmJ5WTZJeUNvNHVCWVUvZTRPTzZUUUQ5VVZMbHlVNVI2Y0E2b3pBd0xqQUxCZ05WSFE4RUJBTUNCYUF3SHdZRFZSMGpCQmd3Rm9BVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdBUThZUjJJZExvZEVFOGsrSnhwQk9JQUd1ekNlVDlCbUZPVmhGVWI4ZUpNQ0lDMjNHb3NzNm1hblJqTlNtaDYrMm9COXRzUmJqbW5ud3VNbERYUjhmenVnIiwiTUlJQm5UQ0NBVU9nQXdJQkFnSUpBSzlQZDVHKy9yMFVNQW9HQ0NxR1NNNDlCQU1DTUNzeEZqQVVCZ05WQkFvTURVTnBjMk52SUZONWMzUmxiWE14RVRBUEJnTlZCQU1NQ0ZabGJtUnZja05CTUI0WERURTNNRFF3TXpFME1UQXdOVm9YRFRFNE1EUXdNekUwTVRBd05Wb3dLekVXTUJRR0ExVUVDZ3dOUTJselkyOGdVM2x6ZEdWdGN6RVJNQThHQTFVRUF3d0lWbVZ1Wkc5eVEwRXdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU3Vuc1FMMlBWT1NGV1dwMG9DamxxRjhpVlBQcEVnSmN0OTMxQ1pRNmFzc3AwN290bWZnWnFYc2sxSllSVGxLQ0dqUk94ckFpVlJRc0I1NGlvQTB5dTBvMUF3VGpBZEJnTlZIUTRFRmdRVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdId1lEVlIwakJCZ3dGb0FVUjRvRXBiNFlGdWVsa01yUWpsbkt0TTAxb3ZFd0RBWURWUjBUQkFVd0F3RUIvekFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUVBK1NTT2hpTlEyM1JXQTc2a1ovMnU3MEZDcFU4T3NVN1g5SVJpV0dEZ0lBZ0NJRkx1OEZuSnVxUHgxMHNnSHZJenFJNUJnT2N3Q2E1dkZRWmRDREJISXgxOCJdfQ.eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2dnaW5nIiwiZG9tYWluLWNlcnQtdHJ1c3RlZC1jYSI6Ii0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLVxuTUlJQlVqQ0IrcUFEQWdFQ0Fna0F3UDRxS3NHeVFsWXdDZ1lJS29aSXpqMEVBd0l3RnpFVk1CTUdBMVVFQXd3TVxuWlhOMFJYaGhiWEJzWlVOQk1CNFhEVEUzTURNeU5USXlNVGMxTUZvWERURTRNRE15TlRJeU1UYzFNRm93RnpFVlxuTUJNR0ExVUVBd3dNWlhOMFJYaGhiWEJzWlVOQk1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVxuUlZyTmxFTjJvY1lzY0FJTEJVN05nZ0FCbzBKZ0ExckVHZFlkQ1FqMW5IS0w2eEtPTkpJVWZCaWJlNmlNVllkM1xuUlVtUHdhUGlITlpKOThrUndISXduS012TUMwd0RBWURWUjBUQkFVd0F3RUIvekFkQmdOVkhRNEVGZ1FVK2RWWFxuYVhvdWNVMWdvZE5GMGJ5Y1MxVTVXNTR3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnTnNDR2pwRWp1dno2T0tKL1xuM3JPdk1jMlpmRGhEMDJLKzBQQ1ZGSkdDUUd3Q0lBemYzQlM2eDlrS1NST0pKdnhEU3BnMFFLOStiOUxTRmtiWlxuTTFQVzk4QU5cbi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS1cbiIsIm5vbmNlIjoiZWE3MTAyZThlODhmMTE5ZSIsInNlcmlhbC1udW1iZXIiOiJQSUQ6MSBTTjp3aWRnZXQxIiwic2VyaWFsLW51bWJlci1pc3N1ZXIiOiIzNjA5N0UzREVBMzkzMTZFQTRDRTVDNjk1QkU5MDVFNzhBRjJGQjVBIiwidmVyc2lvbiI6IjEifX0.QkTUpcxv6Ng6ylyWYnlqun-5SFhD1XwLIW1kD7Y9dNwioheNMcVnowkELl_EMClyOWuLvvWuoCHAcWz_UA0IGw

Here is an equivalent PKCS7 voucher via asn1 dump. You’d have to look at the binary if you really want to decode it. This voucher was generated by MCR during the hackathon: 

pritikin@ubuntu:~/src/brski-project/brski_msgs$ openssl asn1parse -in mcr.voucher.txt.pkcs7
    0:d=0  hl=4 l=2706 cons: SEQUENCE          
    4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
   15:d=1  hl=4 l=2691 cons: cont [ 0 ]        
   19:d=2  hl=4 l=2687 cons: SEQUENCE          
   23:d=3  hl=2 l=   1 prim: INTEGER           :01
   26:d=3  hl=2 l=  15 cons: SET               
   28:d=4  hl=2 l=  13 cons: SEQUENCE          
   30:d=5  hl=2 l=   9 prim: OBJECT            :sha256
   41:d=5  hl=2 l=   0 prim: NULL              
   43:d=3  hl=4 l=1644 cons: SEQUENCE          
   47:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
   58:d=4  hl=4 l=1629 cons: cont [ 0 ]        
   62:d=5  hl=4 l=1625 prim: OCTET STRING      :{"ietf-voucher:voucher":{"nonce":"62a2e7693d82fcda2624de58fb6722e5","created-on":"2017-01-01T00:00:00.000Z","device-identifier":"00-d0-e5-f2-00-01","assertion":"logged","owner":"MIIEEzCCAvugAwIBAgIJAK6rFouvk+7YMA0GCSqGSIb3DQEBCwUAMIGfMQsw\nCQYDVQQGEwJDQTEQMA4GA1UECAwHT250YXJpbzEPMA0GA1UEBwwGT3R0YXdh\nMRowGAYDVQQKDBFPd25lciBFeGFtcGxlIE9uZTERMA8GA1UECwwITm90IFZl\ncnkxGzAZBgNVBAMMEm93bmVyMS5leGFtcGxlLmNvbTEhMB8GCSqGSIb3DQEJ\nARYSb3duZXIxQGV4YW1wbGUuY29tMB4XDTE3MDMyNTE2MjkzNFoXDTE3MDQy\nNDE2MjkzNFowgZ8xCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8w\nDQYDVQQHDAZPdHRhd2ExGjAYBgNVBAoMEU93bmVyIEV4YW1wbGUgT25lMREw\nDwYDVQQLDAhOb3QgVmVyeTEbMBkGA1UEAwwSb3duZXIxLmV4YW1wbGUuY29t\nMSEwHwYJKoZIhvcNAQkBFhJvd25lcjFAZXhhbXBsZS5jb20wggEiMA0GCSqG\nSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4QYAEnTtXgiKqsfSVYkgkHddFcP34\nOU3YP7ibrsgx0i9cyj7xOzWHOF2PsoKBgTRH75MSMhTl5UidrCszlluK+qp4\nd3Zg31oQM/HDmyRJyRpY+PC1n5Vx/Mj5VagRQbqG7XTDQCfCrhqIKrKBTuPQ\n4vYKeL0tQk4UJlPIoZXEmBk5dkn/Fzl9AfIZSvUzQ1QAhQ9oaLz5Nf5MWHPK\nUY+6b2zA/yQaXduPrVuxp7xCj11C/Ljlhl1/Hx16MJrV33MCbd+RKW711D/3\n0XlWSqEprdbKbqw8WMPjuJ1aoX8aQEWoL+xbomRQQJJoFaMPlzgdDcfoAHDU\nTsxd0+FN8pFHAgMBAAGjUDBOMB0GA1UdDgQWBBSqp5TwQtHsQy9oYLZb0D5W\n+licHDAfBgNVHSMEGDAWgBSqp5TwQtHsQy9oYLZb0D5W+licHDAMBgNVHRME\nBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBgSQGacjwxmbRrrBhW63gY5KaW\nim76rG45p3uh9A8WUfMWryCUufrFOm/QEJnlUUK3QX4KEVj2eywb9gsfkiCE\nyaJzxe665Q2BrWwe3rGVkAhO/fn8upec4E1ASc31ASaF8m+pYqCCPSflL5kV\nMefHG4lEs3XJkHceClRzyXvjb5Kj/u02C5YCjcALYd8/kcSbf4joe1GufvKF\n5wvPBPkRVfbW2KagL+jw62j+8U6oB7FbxtFyqQP1YoZGia9MkPKnK+yg5o/0\ncZ57hgk4mQmM1i82RrUZQVoBP3CD5LdBJZfJoXstRlXe6dX7+TisdSAspp5e\nhNm0BcqdLK+z8ntt\n"}}
 1691:d=3  hl=4 l= 557 cons: cont [ 0 ]        
 1695:d=4  hl=4 l= 553 cons: SEQUENCE          
 1699:d=5  hl=4 l= 431 cons: SEQUENCE          
 1703:d=6  hl=2 l=   3 cons: cont [ 0 ]        
 1705:d=7  hl=2 l=   1 prim: INTEGER           :02
 1708:d=6  hl=2 l=   1 prim: INTEGER           :01
 1711:d=6  hl=2 l=  10 cons: SEQUENCE          
 1713:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 1723:d=6  hl=2 l=  77 cons: SEQUENCE          
 1725:d=7  hl=2 l=  18 cons: SET               
 1727:d=8  hl=2 l=  16 cons: SEQUENCE          
 1729:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 1741:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 1745:d=7  hl=2 l=  25 cons: SET               
 1747:d=8  hl=2 l=  23 cons: SEQUENCE          
 1749:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 1761:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 1772:d=7  hl=2 l=  28 cons: SET               
 1774:d=8  hl=2 l=  26 cons: SEQUENCE          
 1776:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 1781:d=9  hl=2 l=  19 prim: UTF8STRING        :Unstrung Highway CA
 1802:d=6  hl=2 l=  30 cons: SEQUENCE          
 1804:d=7  hl=2 l=  13 prim: UTCTIME           :160507023655Z
 1819:d=7  hl=2 l=  13 prim: UTCTIME           :180507023655Z
 1834:d=6  hl=2 l=  77 cons: SEQUENCE          
 1836:d=7  hl=2 l=  18 cons: SET               
 1838:d=8  hl=2 l=  16 cons: SEQUENCE          
 1840:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 1852:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 1856:d=7  hl=2 l=  25 cons: SET               
 1858:d=8  hl=2 l=  23 cons: SEQUENCE          
 1860:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 1872:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 1883:d=7  hl=2 l=  28 cons: SET               
 1885:d=8  hl=2 l=  26 cons: SEQUENCE          
 1887:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 1892:d=9  hl=2 l=  19 prim: UTF8STRING        :Unstrung Highway CA
 1913:d=6  hl=2 l= 118 cons: SEQUENCE          
 1915:d=7  hl=2 l=  16 cons: SEQUENCE          
 1917:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
 1926:d=8  hl=2 l=   5 prim: OBJECT            :secp384r1
 1933:d=7  hl=2 l=  98 prim: BIT STRING        
 2033:d=6  hl=2 l=  99 cons: cont [ 3 ]        
 2035:d=7  hl=2 l=  97 cons: SEQUENCE          
 2037:d=8  hl=2 l=  15 cons: SEQUENCE          
 2039:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
 2044:d=9  hl=2 l=   1 prim: BOOLEAN           :255
 2047:d=9  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF
 2054:d=8  hl=2 l=  14 cons: SEQUENCE          
 2056:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
 2061:d=9  hl=2 l=   1 prim: BOOLEAN           :255
 2064:d=9  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:03020106
 2070:d=8  hl=2 l=  29 cons: SEQUENCE          
 2072:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
 2077:d=9  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:0414258EDF2D51788F0CEC872A22FBD4FEBE0676EB07
 2101:d=8  hl=2 l=  31 cons: SEQUENCE          
 2103:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
 2108:d=9  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:30168014258EDF2D51788F0CEC872A22FBD4FEBE0676EB07
 2134:d=5  hl=2 l=  10 cons: SEQUENCE          
 2136:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 2146:d=5  hl=2 l= 104 prim: BIT STRING        
 2252:d=3  hl=4 l= 454 cons: SET               
 2256:d=4  hl=4 l= 450 cons: SEQUENCE          
 2260:d=5  hl=2 l=   1 prim: INTEGER           :01
 2263:d=5  hl=2 l=  82 cons: SEQUENCE          
 2265:d=6  hl=2 l=  77 cons: SEQUENCE          
 2267:d=7  hl=2 l=  18 cons: SET               
 2269:d=8  hl=2 l=  16 cons: SEQUENCE          
 2271:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 2283:d=9  hl=2 l=   2 prim: IA5STRING         :ca
 2287:d=7  hl=2 l=  25 cons: SET               
 2289:d=8  hl=2 l=  23 cons: SEQUENCE          
 2291:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
 2303:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
 2314:d=7  hl=2 l=  28 cons: SET               
 2316:d=8  hl=2 l=  26 cons: SEQUENCE          
 2318:d=9  hl=2 l=   3 prim: OBJECT            :commonName
 2323:d=9  hl=2 l=  19 prim: UTF8STRING        :Unstrung Highway CA
 2344:d=6  hl=2 l=   1 prim: INTEGER           :01
 2347:d=5  hl=2 l=  13 cons: SEQUENCE          
 2349:d=6  hl=2 l=   9 prim: OBJECT            :sha256
 2360:d=6  hl=2 l=   0 prim: NULL              
 2362:d=5  hl=3 l= 228 cons: cont [ 0 ]        
 2365:d=6  hl=2 l=  24 cons: SEQUENCE          
 2367:d=7  hl=2 l=   9 prim: OBJECT            :contentType
 2378:d=7  hl=2 l=  11 cons: SET               
 2380:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
 2391:d=6  hl=2 l=  28 cons: SEQUENCE          
 2393:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
 2404:d=7  hl=2 l=  15 cons: SET               
 2406:d=8  hl=2 l=  13 prim: UTCTIME           :170325220308Z
 2421:d=6  hl=2 l=  47 cons: SEQUENCE          
 2423:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
 2434:d=7  hl=2 l=  34 cons: SET               
 2436:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:552DD2EE5CBC4C7C4D207F98A2519F031EE10074D674265A7DD0CA73E68BE57D
 2470:d=6  hl=2 l= 121 cons: SEQUENCE          
 2472:d=7  hl=2 l=   9 prim: OBJECT            :S/MIME Capabilities
 2483:d=7  hl=2 l= 108 cons: SET               
 2485:d=8  hl=2 l= 106 cons: SEQUENCE          
 2487:d=9  hl=2 l=  11 cons: SEQUENCE          
 2489:d=10 hl=2 l=   9 prim: OBJECT            :aes-256-cbc
 2500:d=9  hl=2 l=  11 cons: SEQUENCE          
 2502:d=10 hl=2 l=   9 prim: OBJECT            :aes-192-cbc
 2513:d=9  hl=2 l=  11 cons: SEQUENCE          
 2515:d=10 hl=2 l=   9 prim: OBJECT            :aes-128-cbc
 2526:d=9  hl=2 l=  10 cons: SEQUENCE          
 2528:d=10 hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
 2538:d=9  hl=2 l=  14 cons: SEQUENCE          
 2540:d=10 hl=2 l=   8 prim: OBJECT            :rc2-cbc
 2550:d=10 hl=2 l=   2 prim: INTEGER           :80
 2554:d=9  hl=2 l=  13 cons: SEQUENCE          
 2556:d=10 hl=2 l=   8 prim: OBJECT            :rc2-cbc
 2566:d=10 hl=2 l=   1 prim: INTEGER           :40
 2569:d=9  hl=2 l=   7 cons: SEQUENCE          
 2571:d=10 hl=2 l=   5 prim: OBJECT            :des-cbc
 2578:d=9  hl=2 l=  13 cons: SEQUENCE          
 2580:d=10 hl=2 l=   8 prim: OBJECT            :rc2-cbc
 2590:d=10 hl=2 l=   1 prim: INTEGER           :28
 2593:d=5  hl=2 l=  10 cons: SEQUENCE          
 2595:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
 2605:d=5  hl=2 l= 103 prim: OCTET STRING      [HEX DUMP]:3065023100E60EAF73A69826077CF6B760AF9BD1C9BF723D0E84812B06B5A8B7C252362394D98E1B5B4C02D8ACD8DA5BD2248D51EA02306B5BDBDFFBB022A1E039A1847259D2E0AA332E12D24053B3E7ECA6D18EA821E29A53D93EE3BA4DE7D8C594C51736511C

And this is the “encoded” form:
-----BEGIN PKCS7-----
-----END PKCS7-----

_______________________________________________
Anima-bootstrap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 21 Apr 2017 00:55:46 +0000

> On Apr 20, 2017, at 6:51 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hi Max,
> 

The x5c header is defined in JWT but the library I used off github (libjwt) didn’t support it. After looking at the code more closely I’m not sure a jwt abstraction layer is really even needed; JWS is pretty simple to use directly. I’ve forked libjwt and will upload my diff to github tomorrow so you can see what i mean.

> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-6.6.

Totally true. This was discovered at the hackathon too … I just didn’t fix it before looking at the JWT stuff.

- max

> MIIKkgYJKoZIhvcNAQcCoIIKgzCCCn8CAQExDzANBglghkgBZQMEAgEFADCCBmwG
> CSqGSIb3DQEHAaCCBl0EggZZeyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJub25j
> ZSI6IjYyYTJlNzY5M2Q4MmZjZGEyNjI0ZGU1OGZiNjcyMmU1IiwiY3JlYXRlZC1v
> biI6IjIwMTctMDEtMDFUMDA6MDA6MDAuMDAwWiIsImRldmljZS1pZGVudGlmaWVy
> IjoiMDAtZDAtZTUtZjItMDAtMDEiLCJhc3NlcnRpb24iOiJsb2dnZWQiLCJvd25l
> ciI6Ik1JSUVFekNDQXZ1Z0F3SUJBZ0lKQUs2ckZvdXZrKzdZTUEwR0NTcUdTSWIz
> RFFFQkN3VUFNSUdmTVFzd1xuQ1FZRFZRUUdFd0pEUVRFUU1BNEdBMVVFQ0F3SFQy
> NTBZWEpwYnpFUE1BMEdBMVVFQnd3R1QzUjBZWGRoXG5NUm93R0FZRFZRUUtEQkZQ
> ZDI1bGNpQkZlR0Z0Y0d4bElFOXVaVEVSTUE4R0ExVUVDd3dJVG05MElGWmxcbmNu
> a3hHekFaQmdOVkJBTU1FbTkzYm1WeU1TNWxlR0Z0Y0d4bExtTnZiVEVoTUI4R0NT
> cUdTSWIzRFFFSlxuQVJZU2IzZHVaWEl4UUdWNFlXMXdiR1V1WTI5dE1CNFhEVEUz
> TURNeU5URTJNamt6TkZvWERURTNNRFF5XG5OREUyTWprek5Gb3dnWjh4Q3pBSkJn
> TlZCQVlUQWtOQk1SQXdEZ1lEVlFRSURBZFBiblJoY21sdk1ROHdcbkRRWURWUVFI
> REFaUGRIUmhkMkV4R2pBWUJnTlZCQW9NRVU5M2JtVnlJRVY0WVcxd2JHVWdUMjVs
> TVJFd1xuRHdZRFZRUUxEQWhPYjNRZ1ZtVnllVEViTUJrR0ExVUVBd3dTYjNkdVpY
> SXhMbVY0WVcxd2JHVXVZMjl0XG5NU0V3SHdZSktvWklodmNOQVFrQkZoSnZkMjVs
> Y2pGQVpYaGhiWEJzWlM1amIyMHdnZ0VpTUEwR0NTcUdcblNJYjNEUUVCQVFVQUE0
> SUJEd0F3Z2dFS0FvSUJBUUM0UVlBRW5UdFhnaUtxc2ZTVllrZ2tIZGRGY1AzNFxu
> T1UzWVA3aWJyc2d4MGk5Y3lqN3hPeldIT0YyUHNvS0JnVFJINzVNU01oVGw1VWlk
> ckNzemxsdUsrcXA0XG5kM1pnMzFvUU0vSERteVJKeVJwWStQQzFuNVZ4L01qNVZh
> Z1JRYnFHN1hURFFDZkNyaHFJS3JLQlR1UFFcbjR2WUtlTDB0UWs0VUpsUElvWlhF
> bUJrNWRrbi9Gemw5QWZJWlN2VXpRMVFBaFE5b2FMejVOZjVNV0hQS1xuVVkrNmIy
> ekEveVFhWGR1UHJWdXhwN3hDajExQy9MamxobDEvSHgxNk1KclYzM01DYmQrUktX
> NzExRC8zXG4wWGxXU3FFcHJkYkticXc4V01QanVKMWFvWDhhUUVXb0wreGJvbVJR
> UUpKb0ZhTVBsemdkRGNmb0FIRFVcblRzeGQwK0ZOOHBGSEFnTUJBQUdqVURCT01C
> MEdBMVVkRGdRV0JCU3FwNVR3UXRIc1F5OW9ZTFpiMEQ1V1xuK2xpY0hEQWZCZ05W
> SFNNRUdEQVdnQlNxcDVUd1F0SHNReTlvWUxaYjBENVcrbGljSERBTUJnTlZIUk1F
> XG5CVEFEQVFIL01BMEdDU3FHU0liM0RRRUJDd1VBQTRJQkFRQmdTUUdhY2p3eG1i
> UnJyQmhXNjNnWTVLYVdcbmltNzZyRzQ1cDN1aDlBOFdVZk1XcnlDVXVmckZPbS9R
> RUpubFVVSzNRWDRLRVZqMmV5d2I5Z3Nma2lDRVxueWFKenhlNjY1UTJCcld3ZTNy
> R1ZrQWhPL2ZuOHVwZWM0RTFBU2MzMUFTYUY4bStwWXFDQ1BTZmxMNWtWXG5NZWZI
> RzRsRXMzWEprSGNlQ2xSenlYdmpiNUtqL3UwMkM1WUNqY0FMWWQ4L2tjU2JmNGpv
> ZTFHdWZ2S0ZcbjV3dlBCUGtSVmZiVzJLYWdMK2p3NjJqKzhVNm9CN0ZieHRGeXFR
> UDFZb1pHaWE5TWtQS25LK3lnNW8vMFxuY1o1N2hnazRtUW1NMWk4MlJyVVpRVm9C
> UDNDRDVMZEJKWmZKb1hzdFJsWGU2ZFg3K1Rpc2RTQXNwcDVlXG5oTm0wQmNxZExL
> K3o4bnR0XG4ifX2gggItMIICKTCCAa+gAwIBAgIBATAKBggqhkjOPQQDAjBNMRIw
> EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAa
> BgNVBAMME1Vuc3RydW5nIEhpZ2h3YXkgQ0EwHhcNMTYwNTA3MDIzNjU1WhcNMTgw
> NTA3MDIzNjU1WjBNMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZ
> FglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5nIEhpZ2h3YXkgQ0EwdjAQBgcq
> hkjOPQIBBgUrgQQAIgNiAASqSixrp/Zj0Omnzho8bLONYgrPsxrL3DTmJkqiyZ4T
> we/LK3+/iwBgWnohKrOVvO1POtaDHdBuiUjX2CBM66Fg18NSyvwzEJEtFLutFL7S
> cjDYA8JzPLClw0zt/YBad+CjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/
> BAQDAgEGMB0GA1UdDgQWBBQljt8tUXiPDOyHKiL71P6+BnbrBzAfBgNVHSMEGDAW
> gBQljt8tUXiPDOyHKiL71P6+BnbrBzAKBggqhkjOPQQDAgNoADBlAjB6dhfujag2
> xQEgOUr19iWwAyOhu9nHUfcqXhGb6i3nDuKfeIU7Am/WzvAAmqAWXyQCMQDTLKaN
> vf2k//JcW+4+xapVhW83t8UdlMk0+Eoe/YnKPj/a1WIOuzzh6zJtCYjlimYxggHG
> MIIBwgIBATBSME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkW
> CXNhbmRlbG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQQIBATANBglg
> hkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
> DQEJBTEPFw0xNzAzMjUyMjAzMDhaMC8GCSqGSIb3DQEJBDEiBCBVLdLuXLxMfE0g
> f5iiUZ8DHuEAdNZ0Jlp90Mpz5ovlfTB5BgkqhkiG9w0BCQ8xbDBqMAsGCWCGSAFl
> AwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG
> SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB
> KDAKBggqhkjOPQQDAgRnMGUCMQDmDq9zppgmB3z2t2Cvm9HJv3I9DoSBKwa1qLfC
> UjYjlNmOG1tMAtis2Npb0iSNUeoCMGtb29/7sCKh4DmhhHJZ0uCqMy4S0kBTs+fs
> ptGOqCHimlPZPuO6TefYxZTFFzZRHA==
> -----END PKCS7-----
> 
> 
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 21 Apr 2017 17:54:36 +0000

Kent, 

> On Apr 20, 2017, at 6:55 PM, Max Pritikin (pritikin) <[email-masked]> wrote:
> 
>> 

Here is a diff that shows what I mean:
	https://github.com/pritikin/libjwt/commit/da7b8b9b59c26f4af6edefaeafb34ffc1f207cca

In summary: JWS defines a {header}.{payload}.signature method. You don’t really need a JWT library to do that. I was new to the space and wanted a quick ramp up so I used the libjwt library to experiment and found that it hardcoded the {header} information and thus couldn’t support the x5c header we were discussing. With normal, simple, JWS via a JSON library, you’d just add this element like any other normal JSON but because I was using a jwt abstraction I had to update the library’s abstraction layer to support arbitrary JSON additions to the header. 

- max

---

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Apr 2017 19:50:06 +0000

Hi Max,

I think what you're trying to say is that the x5c header is not under
the signature and therefore can be added after the fact using any text-
editing tool. Is that right?

Actually, for that matter, I imagine that the entire thing could be 
constructed without the use of a JWT library - simple openssl/shell
script may work? - what do you think?  

For instance, here's a script for base64url:
https://raw.githubusercontent.com/Moodstocks/moodstocks-api-clients/master/bash/base64url.sh

K.

-----ORIGINAL MESSAGE-----

Kent, 

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 21 Apr 2017 22:51:07 +0000

> On Apr 21, 2017, at 1:50 PM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Max,
> 

No, "In the JWS Compact Serialization, no JWS Unprotected Header is used” [RFC7515]. Therefore everything in the header is under the signature. 
Here is the specification:
	https://tools.ietf.org/html/rfc7515#section-5.1

   5.  Compute the JWS Signature in the manner defined for the
       particular algorithm being used over the JWS Signing Input
       ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
       BASE64URL(JWS Payload)).  The "alg" (algorithm) Header Parameter
       MUST be present in the JOSE Header, with the algorithm value
       accurately representing the algorithm used to construct the JWS
       Signature.

So for the original example down below the “JWS Protected Header” is:

{
"typ": "JWT",
"alg": "ES256",

What I mean is that the full header, and the x5c entry, are all simple JSON structures that we already know how to deal with if we were able to build the JSON in the first place. The diffs I pointed to were because I made the mistake of thinking a JWT library would be needed… but then this limited abstraction of the library got in my way. Now that I know better i’ll avoid the extra abstraction layer (those just cause trouble).

> script may work? - what do you think?  

Yup! That was my long winded point! :)

> https://raw.githubusercontent.com/Moodstocks/moodstocks-api-clients/master/bash/base64url.sh

That script would base64 encode the header json, then the payload json, put them together with a “.” between them before calling a simple “sign operation” of the appropriate type. In my example below I used ES256 which is defined in here: 
	https://tools.ietf.org/html/rfc7518#section-3.4

I can see how this is done using the openssl API but I don’t know if there is a CLI tool to perform this operation. A quick google search shows folks doing this:
	echo -n “${BASE64HEADER_DOT_BASE64PAYLOAD}" | openssl dgst -binary -sha256 -sign “${PRIVATE_KEY}"
Which works ok. If you use “-hmac” and a password you get something you can verify on https://jwt.io but we’ll want to stick with ES256 I’m sure. 

Interestingly my example token is failing my local attempt to use ”openssl dgst” to verify it. So I’ve probably got something to fix. Now that I see how to do testing using openssl like this I can have my own little hackathon. ;) 

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 21 Apr 2017 23:52:53 +0000

Kent, 

> On Apr 21, 2017, at 4:51 PM, Max Pritikin (pritikin) <[email-masked]> wrote:
> 
>> 

Ah. If you look at dgst.c from your openssl distribution you’ll see its just doing:
	EVP_DigestSignFinal(ctx, buf, &len)) 
then dumping the resulting signature. The format of this is a ASN1 encoding of the r and s values that are the actual signature.

You can see this by exploding the output from openssl dgst via asn1parse: 
pritikin@ubuntu:~/tmp/jwt$ openssl asn1parse -in signature.sign -inform DER
    0:d=0  hl=2 l=  69 cons: SEQUENCE          
    2:d=1  hl=2 l=  32 prim: INTEGER           :1EF9060ADA81C288C4FE2E3585BFF6379FF03467EB0D7D848D568604A1C53864
   36:d=1  hl=2 l=  33 prim: INTEGER           :EAD5AD3F8FB7092D14903C8B08D0D83EE91E898EA8D3A5944F13F8B6652372D1

So to do everything in script-land with openssl tools you need to extract the r and s values and format them correctly as specified in JWA [RFC7518, section 3.4 step 2 and 3). I’ll have to think about how you could do this from a shell script. Its interesting to note here that we have almost the simplest example of ASN1 possible and it still sounds hard to work with. :) Shrug, it isn’t like the JWA 64-octet sequence is actually that much easier from shell commands. 

My example did this extraction, padding, and binary concatenation using the openssl API ECDSA_SIG_get0 (see libjwt, jwt.c:544). 

What I think what we want is a “jws_digest” tool that does only this part. It’d work like the above openssl commands but instead of ASN1 encoding the signature it would use RFC7518 instead.

- max

---

From: Kent Watsen <[email-masked]>
Date: Mon, 24 Apr 2017 18:36:01 +0000

> So to do everything in script-land with openssl tools you need to extract
> the r and s values and format them correctly as specified in JWA [RFC7518,
> section 3.4 step 2 and 3). I’ll have to think about how you could do this
> from a shell script. 

Your signature.sign file is probably 66 bytes, right?   Assuming 'R' and 'S' are in order, I think you can snip 2-bytes off the front of the file and have the signature.

> Its interesting to note here that we have almost the simplest example of
> ASN1 possible and it still sounds hard to work with. :) Shrug, it isn’t
> like the JWA 64-octet sequence is actually that much easier from shell
> commands. 

But all we need to do is compute the encoded signature value BASE64URL(JWS Signature), we can use the script I found before for this part...

Kent