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

From: Kent Watsen <[email-masked]>
Date: Wed, 3 May 2017 01:22:57 +0000

I've had some time now to investigate JWS, in particular, reproducing some examples in RFCs 7515 and 7520 using nothing but shell scripts and the `openssl` command line utility.

I want to like JWS, but I wish the header was in a more technology-neutral format, it being JSON seems weird to me.  Had this been done, it would be a nice general-purpose signature format.  Size wise, JWS grows the size of the data 33% when b64 encoding it for the "compact serialization" form, which is actually a 65-character alphabet including '.'.  It seems that a binary header could've also allowed for a binary payload and signature, which would've been perfect, in my opinion.  [Of course, the entire binary blob could still be base64url-encoded for those that want it, without forcing it on those that don’t]

The example voucher you obtained from mcr wasn't as trimmed down as it could've been, using the -noattr and -nocert options, which is one reason the asn1parse dump looks as busy as it does.  Another being that the owner/domain-cert-trusted-ca encode very different certs (is one ec while the other is rsa?)

In the end, JWS appears to be just another signature format with its own set of peculiarities.  And given that we already have to support ASN.1 (the voucher encodes both an X.509 cert as well as a X.509 certificate chain), not to mention the need for the MASA to have a PKIX infrastructure, it's not clear to me if this is a good trade at all.

Lastly, as mentioned before, my netconf zerotouch draft uses CMS/PKCS7 elsewhere.  While it would be trivial to update the draft to use a JWS-based format, it would be awkward for clients to have to consider it at all.

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: Kent Watsen <[email-masked]>
Date: Wed, 3 May 2017 01:33:23 +0000

BTW, ES256 uses the P-256 curve (aka secp256r1) which has since been deprecated.  I got a kick out of RFC 7518 giving it a "recommended+" rating  ;)

K.

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

Kent

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

The dumps:

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 9 May 2017 18:04:55 +0000

> On May 2, 2017, at 7:22 PM, Kent Watsen <[email-masked]> wrote:
> 
> 

Excellent. I look forward to hearing what tool you used to convert the openssl dgst signature to the JWS form. 

> I want to like JWS, but I wish the header was in a more technology-neutral format, it being JSON seems weird to me.

Given that we’re already using JSON (with discussion of CBOR) this doesn’t seem relevant since we aren’t technology-neutral either. I don’t know that there is such a thing as a technology neutral header. 

>  Had this been done, it would be a nice general-purpose signature format.  Size wise, JWS grows the size of the data 33% when b64 encoding it for the "compact serialization" form, which is actually a 65-character alphabet including '.'.  It seems that a binary header could've also allowed for a binary payload and signature, which would've been perfect, in my opinion.  [Of course, the entire binary blob could still be base64url-encoded for those that want it, without forcing it on those that don’t]

In either PKCS7 or JWT we’re using a base64 encoding to transmit the final result over the HTTPS/REST interface. With ACE discussions moving toward CoAP w/ CBOR they’ll have the option of “CWT” or “PKCS7 binary in a CBOR”.

> The example voucher you obtained from mcr wasn't as trimmed down as it could've been, using the -noattr and -nocert options, which is one reason the asn1parse dump looks as busy as it does.  Anothe…

I read this as an argument in favor of a strict profile of PKCS7 if we’re going to stick with that format. Of course Postel’s law (“be conservative in what you do, be liberal in what you accept”) implies that relying parties would have to deal with the more complex ASN1 encodings — which results in the basic issue of complex ASN1 parsers on the endpoints.  

> Lastly, as mentioned before, my netconf zerotouch draft uses CMS/PKCS7 elsewhere.  While it would be trivial to update the draft to use a JWS-based format, it would be awkward for clients to have t…

But with that approach we’ll never kill off asn1. :(

- 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-----
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 22 May 2017 16:14:41 -0400

Kent Watsen <[email-masked]> wrote:
    > BTW, ES256 uses the P-256 curve (aka secp256r1) which has since been
    > deprecated.  I got a kick out of RFC 7518 giving it a "recommended+"
    > rating  ;)

Yeah, in my work, I've had to sue secp256r1 because the examples are in that,
and the libraries are up-to-date for it.

But I'd rather be using Ed25519: it becomed bleeding edge work.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-