Subject: [Anima-bootstrap] Voucher signing method

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 18 Apr 2017 18:08:17 +0000

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

---

From: peter van der Stok <[email-masked]>
Date: Wed, 19 Apr 2017 09:01:04 +0200

Hi Max,

thanks for the examples.
During IETF98, I was the one to speak up in favour of #pkcs7;
One reason only: It is transported by EST that is used by BRSKI.
All the code is already present.
Doing JWS/COSE or JWT/CWT needs additional code.
I am sensitive to the payload size argument though.

But, suppose the JWS or JWT is adopted to reduce the payload,
where will the optimizations stop?
Will you envisage to optimize the EST payloads as well?

Cheerio,

Peter

Max Pritikin (pritikin) schreef op 2017-04-18 20:08:
> 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.
> 
> 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.
> 
> 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.
> 
> 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:
> 
>    "x5c":
> ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug",
> "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNVHQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA76kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDBHIx18"]
> }
> .
> {
>        "domain-cert-trusted-ca": "-----BEGIN
> CERTIFICATE-----\nMIIBUjCB+qADAgECAgkAwP4qKsGyQlYwCgYIKoZIzj0EAwIwFzEVMBMGA1UEAwwM\nZXN0RXhhbXBsZUNBMB4XDTE3MDMyNTIyMTc1MFoXDTE4MDMyNTIyMTc1MFowFzEV\nMBMGA1UEAwwMZXN0RXhhbXBsZUNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE\nRVrNlEN2ocYscAILBU7NggABo0JgA1rEGdYdCQj1nHKL6xKONJIUfBibe6iMVYd3\nRUmPwaPiHNZJ98kRwHIwnKMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQU+dVX\naXoucU1godNF0bycS1U5W54wCgYIKoZIzj0EAwIDRwAwRAIgNsCGjpEjuvz6OKJ/\n3rOvMc2ZfDhD02K+0PCVFJGCQGwCIAzf3BS6x9kKSROJJvxDSpg0QK9+b9LSFkbZ\nM1PW98AN\n-----END
> CERTIFICATE-----\n",
>        "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):
> 
>
eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsICAgICJ4NWMiOlsiTUlJQmRqQ0NBUjJnQXdJQkFnSUJBVEFLQmdncWhrak9QUVFEQWpBck1SWXdGQVlEVlFRS0RBMURhWE5qYnlCVGVYTjBaVzF6TVJFd0R3WURWUVFEREFoV1pXNWtiM0pEUVRBZUZ3MHhOekEwTURNeE5URTFORFZhRncweE9EQTBNRE14TlRFMU5EVmFNQzB4RmpBVUJnTlZCQW9NRFVOcGMyTnZJRk41YzNSbGJYTXhFekFSQmdOVkJBTU1DbFpsYm1SdmNrMUJVMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ5R1RyRGQwR1dnd2N1U3k4TENuMHdhTWVrbnBMem5halp6cVdsTGhyUHdzaGdJUElQdmJ5WTZJeUNvNHVCWVUvZTRPTzZUUUQ5VVZMbHlVNVI2Y0E2b3pBd0xqQUxCZ05WSFE4RUJBTUNCYUF3SHdZRFZSMGpCQmd3Rm9BVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdBUThZUjJJZExvZEVFOGsrSnhwQk9JQUd1ekNlVDlCbUZPVmhGVWI4ZUpNQ0lDMjNHb3NzNm1hblJqTlNtaDYrMm9COXRzUmJqbW5ud3VNbERYUjhmenVnIiwiTUlJQm5UQ0NBVU9nQXdJQkFnSUpBSzlQZDVHKy9yMFVNQW9HQ0NxR1NNNDlCQU1DTUNzeEZqQVVCZ05WQkFvTURVTnBjMk52SUZONWMzUmxiWE14RVRBUEJnTlZCQU1NQ0ZabGJtUnZja05CTUI0WERURTNNRFF3TXpFME1UQXdOVm9YRFRFNE1EUXdNekUwTVRBd05Wb3dLekVXTUJRR0ExVUVDZ3dOUTJselkyOGdVM2x6ZEdWdGN6RVJNQThHQTFVRUF3d0lWbV
Z1Wkc5eVEwRXdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU3Vuc1FMMlBWT1NGV1dwMG9DamxxRjhpVlBQcEVnSmN0OTMxQ1pRNmFzc3AwN290bWZnWnFYc2sxSllSVGxLQ0dqUk94ckFpVlJRc0I1NGlvQTB5dTBvMUF3VGpBZEJnTlZIUTRFRmdRVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdId1lEVlIwakJCZ3dGb0FVUjRvRXBiNFlGdWVsa01yUWpsbkt0TTAxb3ZFd0RBWURWUjBUQkFVd0F3RUIvekFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUVBK1NTT2hpTlEyM1JXQTc2a1ovMnU3MEZDcFU4T3NVN1g5SVJpV0dEZ0lBZ0NJRkx1OEZuSnVxUHgxMHNnSHZJenFJNUJnT2N3Q2E1dkZRWmRDREJISXgxOCJdfQ.eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2dnaW5nIiwiZG9tYWluLWNlcnQtdHJ1c3RlZC1jYSI6Ii0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLVxuTUlJQlVqQ0IrcUFEQWdFQ0Fna0F3UDRxS3NHeVFsWXdDZ1lJS29aSXpqMEVBd0l3RnpFVk1CTUdBMVVFQXd3TVxuWlhOMFJYaGhiWEJzWlVOQk1CNFhEVEUzTURNeU5USXlNVGMxTUZvWERURTRNRE15TlRJeU1UYzFNRm93RnpFVlxuTUJNR0ExVUVBd3dNWlhOMFJYaGhiWEJzWlVOQk1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVxuUlZyTmxFTjJvY1lzY0FJTEJVN05nZ0FCbzBKZ0ExckVHZFlkQ1FqMW5IS0w2eEtPTkpJVWZCaWJlNmlNVllkM1xuUlVtUHdhUGlITlpKOThrUndISXduS012T
UMwd0RBWURWUjBUQkFVd0F3RUIvekFkQmdOVkhRNEVGZ1FVK2RWWFxuYVhvdWNVMWdvZE5GMGJ5Y1MxVTVXNTR3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnTnNDR2pwRWp1dno2T0tKL1xuM3JPdk1jMlpmRGhEMDJLKzBQQ1ZGSkdDUUd3Q0lBemYzQlM2eDlrS1NST0pKdnhEU3BnMFFLOStiOUxTRmtiWlxuTTFQVzk4QU5cbi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS1cbiIsIm5vbmNlIjoiZWE3MTAyZThlODhmMTE5ZSIsInNlcmlhbC1udW1iZXIiOiJQSUQ6MSBTTjp3aWRnZXQxIiwic2VyaWFsLW51bWJlci1pc3N1ZXIiOiIzNjA5N0UzREVBMzkzMTZFQTRDRTVDNjk1QkU5MDVFNzhBRjJGQjVBIiwidmVyc2lvbiI6IjEifX0.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:
> 
>    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/yQaX
duPrVuxp7xCj11C/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"}}
>  2077:d=9  hl=2 l=  22 prim: OCTET STRING      [HEX
> DUMP]:0414258EDF2D51788F0CEC872A22FBD4FEBE0676EB07
>  2108:d=9  hl=2 l=  24 prim: OCTET STRING      [HEX
> DUMP]:30168014258EDF2D51788F0CEC872A22FBD4FEBE0676EB07
>  2436:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX
> DUMP]:552DD2EE5CBC4C7C4D207F98A2519F031EE10074D674265A7DD0CA73E68BE57D
>  2605:d=5  hl=2 l= 103 prim: OCTET STRING      [HEX
> DUMP]:3065023100E60EAF73A69826077CF6B760AF9BD1C9BF723D0E84812B06B5A8B7C252362394D98E1B5B4C02D8ACD8DA5BD2248D51EA02306B5BDBDFFBB022A1E039A1847259D2E0AA332E12D24053B3E7ECA6D18EA821E29A53D93EE3BA4DE7D8C594C51736511C
> 
> 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-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 19 Apr 2017 18:45:22 +0000

> On Apr 19, 2017, at 1:01 AM, peter van der Stok <[email-masked]> wrote:
> 
> Hi Max,
> 
> thanks for the examples.

I thought so but wasn’t sure and the minutes didn’t appear to be available. 

> All the code is already present.

Yes: Enrollment over Secure Transport (EST) is *not* intended to be a new enrollment protocol (instead it focused on clarifying how simple CMC messages could be used when a secure transport is available). As such the /cacerts response is a CMC subset "PKCS#7 "certs-only” response”. 

That is a really heavy structure to deliver what is essentially, but not exactly, the JWT x5c certificate chain. :(

> Will you envisage to optimize the EST payloads as well?

The EST discussion in the -06 concise draft is introduced as: "describes EST extensions necessary to enable fully automated bootstrapping”. It adds a couple of telemetry (success/fail messages) and mandates a few options that were defined in EST but has so far avoided redefining any EST messages. 

Thoughts: 

a) The voucher currently contains the x5c header necessary to deliver the CA certificate to move the existing TLS connection out of the provisional state — but this is not mandated to be the entire /cacerts chain. The client is instructed that:
	the domainCAcert is not a complete distribution of the EST 
	section 4.1.3 CA Certificate Response.
and
	The Pledge MUST request the full EST Distribution of CA Certificates
	message.  See RFC7030, section 4.1.
One approach is to ensure the voucher x5c header does contain everything necessary. This would allow a client that does not continue to use EST to have a full /cacerts equivalent response. Within BRSKI itself this would solve the discussion. 

We’re encroaching on redefining that header though (see RFC7515#section-4.1.6 where it x5c is defined — its a chain directly to the root without any cross certifications). If we include PKI /cacerts into there we need to change that definition via a new header type so that we can cover the oldwithnew, newwithold etc stuff from PKI land.

b) Realistically any PKI client really “MUST” keep their ca certificates up to date. (BRSKI tries to frame this as optional to ensure a clean integration point for non-PKI type deployments). Therefore we could assume that /cacerts will be called and therefore embark on your point: an optimization of at least this EST payload. If we do take that path I’d lean toward a general purpose “discovery” document that details a bunch of information about the service including the x5c (or new form) header — thus making this a valuable addition and driving alignment toward the token concepts rather than just a new format. I’m worried about adding that but do see the value in that it allows a client to avoid any CMS/PKCS#7.

Boy, either approach is redefining a message form that almost defined in a prior protocol. A great topic to hear folks on this list comment on. 

- max

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 19 Apr 2017 20:24:50 +0000

About a), I don't think putting all the CA certs in the voucher is a good idea. EST should be used instead. I don’t think it is right for someone to expect the voucher to distribute its roots of trust. What if a CA cert gets revoked of expires? EST has the transitional certs that allow for root CA cert update, but I don't think we can expect someone to rerun BRSKI in order to get its new root of trust. 

The cert chain in the voucher should only enable the client to establish a trust relationship with the server. So, I think only one root cert for the domain should be carried in the voucher. The rest of the certs in the chain of the server cert should be sent by the server in the TLS negotiation. 

About b), optimizing the cacerts response. The truth is that cacerts can grow a lot in size. The enroll response could also be big for constrained environments depending on algorithms used. Some thoughts have been proposed in pkix/tls in the past to shrink certs like caching and compression, but they have some disadvantages. DTLS also provides a fragmentation mechanism in the handshake to accommodate for large records (ca certs in this case). Thus optimizing the responses might not be necessary, or even easy for that matter. 

Let's say you still wanted to think about it. I don't think JWT or CBOR would add any shrinkage to an ASN.1 cert chain. Now if you are contemplating using a new free-form JSON certificate format (instead of CMS) and then using JWT or CBOR to secure and shrink it, I am not sure about size improvements. CMS' ASN.1 is not human friendly, but I would be interested if writing the cert fields in free-form JSON and encoding with CBOR/JWT would really lead to a shorter total size. In other words, I am not sure going beyond JSON vouchers/tokens when talking about new encodings (JWT, CBOR) is something we should tackle.

Rgs,
Panos

-----Original Message-----
From: Anima-bootstrap [mailto:[email-masked]] On Behalf Of Max Pritikin (pritikin)
Sent: Wednesday, April 19, 2017 2:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Anima-bootstrap] Voucher signing method

> But, suppose the JWS or JWT is adopted to reduce the payload, where 
> will the optimizations stop?

Thoughts: 

- max

>> 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 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.
>> hard to capture). After that is an encoded and signed voucher. 
>> Further below is an example of a PKCS7 signed voucher.
>> 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.
>> 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.
>> ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN
>> 0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1
>> NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwW
>> TATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzq
>> WlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAM
>> CBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAw
>> RAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2
>> oB9tsRbjmnnwuMlDXR8fzug", 
>> "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNp
>> c2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4M
>> DQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG
>> 9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpE
>> gJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNV
>> HQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQj
>> lnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA7
>> 6kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDB
>> HIx18"]
>> }
>> .
>> {
>> CERTIFICATE-----\nMIIBUjCB+qADAgECAgkAwP4qKsGyQlYwCgYIKoZIzj0EAwIwFzE
>> VMBMGA1UEAwwM\nZXN0RXhhbXBsZUNBMB4XDTE3MDMyNTIyMTc1MFoXDTE4MDMyNTIyMT
>> c1MFowFzEV\nMBMGA1UEAwwMZXN0RXhhbXBsZUNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DA
>> QcDQgAE\nRVrNlEN2ocYscAILBU7NggABo0JgA1rEGdYdCQj1nHKL6xKONJIUfBibe6iM
>> VYd3\nRUmPwaPiHNZJ98kRwHIwnKMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQU+dV
>> X\naXoucU1godNF0bycS1U5W54wCgYIKoZIzj0EAwIDRwAwRAIgNsCGjpEjuvz6OKJ/\n
>> 3rOvMc2ZfDhD02K+0PCVFJGCQGwCIAzf3BS6x9kKSROJJvxDSpg0QK9+b9LSFkbZ\nM1P
>> W98AN\n-----END
>> CERTIFICATE-----\n",
>> 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):
>> 
> eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsICAgICJ4NWMiOlsiTUlJQmRqQ0NBUjJnQX
> dJQkFnSUJBVEFLQmdncWhrak9QUVFEQWpBck1SWXdGQVlEVlFRS0RBMURhWE5qYnlCVGVY
> TjBaVzF6TVJFd0R3WURWUVFEREFoV1pXNWtiM0pEUVRBZUZ3MHhOekEwTURNeE5URTFORF
> ZhRncweE9EQTBNRE14TlRFMU5EVmFNQzB4RmpBVUJnTlZCQW9NRFVOcGMyTnZJRk41YzNS
> bGJYTXhFekFSQmdOVkJBTU1DbFpsYm1SdmNrMUJVMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3
> Foa2pPUFFNQkJ3TkNBQVQ5R1RyRGQwR1dnd2N1U3k4TENuMHdhTWVrbnBMem5halp6cVds
> TGhyUHdzaGdJUElQdmJ5WTZJeUNvNHVCWVUvZTRPTzZUUUQ5VVZMbHlVNVI2Y0E2b3pBd0
> xqQUxCZ05WSFE4RUJBTUNCYUF3SHdZRFZSMGpCQmd3Rm9BVVI0b0VwYjRZRnVlbGtNclFq
> bG5LdE0wMW92RXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdBUThZUjJJZExvZEVFOGsrSn
> hwQk9JQUd1ekNlVDlCbUZPVmhGVWI4ZUpNQ0lDMjNHb3NzNm1hblJqTlNtaDYrMm9COXRz
> UmJqbW5ud3VNbERYUjhmenVnIiwiTUlJQm5UQ0NBVU9nQXdJQkFnSUpBSzlQZDVHKy9yMF
> VNQW9HQ0NxR1NNNDlCQU1DTUNzeEZqQVVCZ05WQkFvTURVTnBjMk52SUZONWMzUmxiWE14
> RVRBUEJnTlZCQU1NQ0ZabGJtUnZja05CTUI0WERURTNNRFF3TXpFME1UQXdOVm9YRFRFNE
> 1EUXdNekUwTVRBd05Wb3dLekVXTUJRR0ExVUVDZ3dOUTJselkyOGdVM2x6ZEdWdGN6RVJN
> QThHQTFVRUF3d0lWbV 
> Z1Wkc5eVEwRXdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU3Vuc1FMMlBW
> T1NGV1dwMG9DamxxRjhpVlBQcEVnSmN0OTMxQ1pRNmFzc3AwN290bWZnWnFYc2sxSllSVG
> xLQ0dqUk94ckFpVlJRc0I1NGlvQTB5dTBvMUF3VGpBZEJnTlZIUTRFRmdRVVI0b0VwYjRZ
> RnVlbGtNclFqbG5LdE0wMW92RXdId1lEVlIwakJCZ3dGb0FVUjRvRXBiNFlGdWVsa01yUW
> psbkt0TTAxb3ZFd0RBWURWUjBUQkFVd0F3RUIvekFLQmdncWhrak9QUVFEQWdOSUFEQkZB
> aUVBK1NTT2hpTlEyM1JXQTc2a1ovMnU3MEZDcFU4T3NVN1g5SVJpV0dEZ0lBZ0NJRkx1OE
> ZuSnVxUHgxMHNnSHZJenFJNUJnT2N3Q2E1dkZRWmRDREJISXgxOCJdfQ.eyJpZXRmLXZvd
> WNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2dnaW5nIiwiZG9tYWluLWNlcnQtdHJ
> 1c3RlZC1jYSI6Ii0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLVxuTUlJQlVqQ0IrcUFEQ
> WdFQ0Fna0F3UDRxS3NHeVFsWXdDZ1lJS29aSXpqMEVBd0l3RnpFVk1CTUdBMVVFQXd3TVx
> uWlhOMFJYaGhiWEJzWlVOQk1CNFhEVEUzTURNeU5USXlNVGMxTUZvWERURTRNRE15TlRJe
> U1UYzFNRm93RnpFVlxuTUJNR0ExVUVBd3dNWlhOMFJYaGhiWEJzWlVOQk1Ga3dFd1lIS29
> aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVxuUlZyTmxFTjJvY1lzY0FJTEJVN05nZ0FCb
> zBKZ0ExckVHZFlkQ1FqMW5IS0w2eEtPTkpJVWZCaWJlNmlNVllkM1xuUlVtUHdhUGlITlp
> KOThrUndISXduS012T 
> UMwd0RBWURWUjBUQkFVd0F3RUIvekFkQmdOVkhRNEVGZ1FVK2RWWFxuYVhvdWNVMWdvZE5
> GMGJ5Y1MxVTVXNTR3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnTnNDR2pwRWp1dno2T0tKL
> 1xuM3JPdk1jMlpmRGhEMDJLKzBQQ1ZGSkdDUUd3Q0lBemYzQlM2eDlrS1NST0pKdnhEU3B
> nMFFLOStiOUxTRmtiWlxuTTFQVzk4QU5cbi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS1cb
> iIsIm5vbmNlIjoiZWE3MTAyZThlODhmMTE5ZSIsInNlcmlhbC1udW1iZXIiOiJQSUQ6MSB
> TTjp3aWRnZXQxIiwic2VyaWFsLW51bWJlci1pc3N1ZXIiOiIzNjA5N0UzREVBMzkzMTZFQ
> TRDRTVDNjk1QkU5MDVFNzhBRjJGQjVBIiwidmVyc2lvbiI6IjEifX0.QkTUpcxv6Ng6yly
> WYnlqun-5SFhD1XwLIW1kD7Y9dNwioheNMcVnowkELl_EMClyOWuLvvWuoCHAcWz_UA0IG
> w
> :{"ietf-voucher:voucher":{"nonce":"62a2e7693d82fcda2624de58fb6722e5","
> created-on":"2017-01-01T00:00:00.000Z","device-identifier":"00-d0-e5-f
> 2-00-01","assertion":"logged","owner":"MIIEEzCCAvugAwIBAgIJAK6rFouvk+7
> YMA0GCSqGSIb3DQEBCwUAMIGfMQsw\nCQYDVQQGEwJDQTEQMA4GA1UECAwHT250YXJpbzE
> PMA0GA1UEBwwGT3R0YXdh\nMRowGAYDVQQKDBFPd25lciBFeGFtcGxlIE9uZTERMA8GA1U
> ECwwITm90IFZl\ncnkxGzAZBgNVBAMMEm93bmVyMS5leGFtcGxlLmNvbTEhMB8GCSqGSIb
> 3DQEJ\nARYSb3duZXIxQGV4YW1wbGUuY29tMB4XDTE3MDMyNTE2MjkzNFoXDTE3MDQy\nN
> DE2MjkzNFowgZ8xCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8w\nDQYDVQQHD
> AZPdHRhd2ExGjAYBgNVBAoMEU93bmVyIEV4YW1wbGUgT25lMREw\nDwYDVQQLDAhOb3QgV
> mVyeTEbMBkGA1UEAwwSb3duZXIxLmV4YW1wbGUuY29t\nMSEwHwYJKoZIhvcNAQkBFhJvd
> 25lcjFAZXhhbXBsZS5jb20wggEiMA0GCSqG\nSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4Q
> YAEnTtXgiKqsfSVYkgkHddFcP34\nOU3YP7ibrsgx0i9cyj7xOzWHOF2PsoKBgTRH75MSM
> hTl5UidrCszlluK+qp4\nd3Zg31oQM/HDmyRJyRpY+PC1n5Vx/Mj5VagRQbqG7XTDQCfCr
> hqIKrKBTuPQ\n4vYKeL0tQk4UJlPIoZXEmBk5dkn/Fzl9AfIZSvUzQ1QAhQ9oaLz5Nf5MW
> HPK\nUY+6b2zA/yQaX 
> duPrVuxp7xCj11C/Ljlhl1/Hx16MJrV33MCbd+RKW711D/3\n0XlWSqEprdbKbqw8WMPju
> J1aoX8aQEWoL+xbomRQQJJoFaMPlzgdDcfoAHDU\nTsxd0+FN8pFHAgMBAAGjUDBOMB0GA
> 1UdDgQWBBSqp5TwQtHsQy9oYLZb0D5W\n+licHDAfBgNVHSMEGDAWgBSqp5TwQtHsQy9oY
> LZb0D5W+licHDAMBgNVHRME\nBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBgSQGacjwxm
> bRrrBhW63gY5KaW\nim76rG45p3uh9A8WUfMWryCUufrFOm/QEJnlUUK3QX4KEVj2eywb9
> gsfkiCE\nyaJzxe665Q2BrWwe3rGVkAhO/fn8upec4E1ASc31ASaF8m+pYqCCPSflL5kV\
> nMefHG4lEs3XJkHceClRzyXvjb5Kj/u02C5YCjcALYd8/kcSbf4joe1GufvKF\n5wvPBPk
> RVfbW2KagL+jw62j+8U6oB7FbxtFyqQP1YoZGia9MkPKnK+yg5o/0\ncZ57hgk4mQmM1i8
> 2RrUZQVoBP3CD5LdBJZfJoXstRlXe6dX7+TisdSAspp5e\nhNm0BcqdLK+z8ntt\n"}}
>> DUMP]:3065023100E60EAF73A69826077CF6B760AF9BD1C9BF723D0E84812B06B5A8B
>> 7C252362394D98E1B5B4C02D8ACD8DA5BD2248D51EA02306B5BDBDFFBB022A1E039A1
>> 847259D2E0AA332E12D24053B3E7ECA6D18EA821E29A53D93EE3BA4DE7D8C594C5173
>> 6511C

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 19 Apr 2017 21:29:09 +0000

> On Apr 19, 2017, at 2:24 PM, Panos Kampanakis (pkampana) <[email-masked]> wrote:
> 

Yes, this captures the current draft’s position: The voucher provides sufficient information to trust the registrar, the pledge communicates with the registrar to obtain the rest of the PKI information. 

> Let's say you still wanted to think about it. I don't think JWT or CBOR would add any shrinkage to an ASN.1 cert chain. Now if you are contemplating using a new free-form JSON certificate format (i…

I think you’re touching on three issues we should keep them distinct:
1) How a bundle of PKIX certificate is distributed as in the EST /cacerts message. This is what is being discussed.
2) out-of-scope: PKIX certificate format.
3) out-of-scope: Size of certificate chains and complexity of the PKI hierarchy.

Lets focus on (1) for now.

Given that the payloads are full certificates (2 and 3) I don’t think its going to benefit us to try and chose based on the pure size of the structure. I didn’t even bother to ensure comparable structures when I started this thread.

I think Peter’s point is that moving to JWT for the voucher signature but depending on PKCS#7 in the /cacerts exchange results in client’s being required to handle both formats. This is defensible based on the (lack of) complexity in JWT and the relatively clean way BRSKI *only extends* EST but isn’t optimal for clients. Ensuring that the client can use JWT all the way through requires overloading that one EST call. That’s a more substantial impact on EST but is implied by a transition to JWT. Its a really good point. 

Cheers, 

- max

---

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Apr 2017 21:59:19 +0000

> I think Peter’s point is that moving to JWT for the voucher signature
> but depending on PKCS#7 in the /cacerts exchange results in client’s
> being required to handle both formats.

This is one of my issues, when thinking about the NETCONF zerotouch
bootstrapping draft, as all the other structures in the are ASN.1,
and no one has expressed interest in tiny encodings yet.  I'd prefer
it if the voucher draft supported both encodings, and then BRSKI and NETCONF zerotouch can cherry-pick their preferred encoding.

Kent

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

Cheers, 

- max

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 19 Apr 2017 22:08:46 +0000

> On Apr 19, 2017, at 3:59 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> it if the voucher draft supported both encodings,

How would you do this? The voucher draft clearly indicates a specific encoding (e.g. PKCS#7 SignedData).
Would you suggest we enhance this to support either JWT or PKCS#7 (maybe CMS) and suggest protocols signal their preferred method? 

That would allow us to close the issue for the voucher document but I’m conflicted. I don’t want to introduce this as an option that lives with us for as long as vouchers are used. :( 

- max

> and then BRSKI and NETCONF zerotouch can cherry-pick their preferred encoding.
> 
> Kent
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Apr 2017 11:36:34 -0400

peter van der Stok <[email-masked]> wrote:
    > thanks for the examples.  During IETF98, I was the one to speak up in
    > favour of #pkcs7; One reason only: It is transported by EST that is
    > used by BRSKI.  All the code is already present.  Doing JWS/COSE or
    > JWT/CWT needs additional code.  I am sensitive to the payload size
    > argument though.

I disagree with your argument.

a) it's not TLS even if TLS has to do many similar things.  The TLS data
   packet/frame format is not just a series of PKCS7 payloads...
   So for many implementers, it means reaching down into their PKIX library
   and learning new things.  For some, this may mean switching TLS libraries.
   There is work there for the developers.
   {I've been down this path, which is how I produced the PKCS7 object Max
   decoded}

   Also, if on the client, one has an ASN1-free (or very lite) RPK TLS
   implementation, I think that one can implement BRSKI while short-cutting
   much of the ASN1 parsing that EST appears to need.

b) if you replace DTLS with OSCOAP, then the argument goes in the other
   direction.

c) On the Registrar level, the TLS may well be done in the framework, or
    in an entirely different process [That in itself is a challenge].
    This is because the TLS is done at the web load balancer level, while
    the application code runs inside an application code (django, rails,
    j2ee, node.js) framework.

d) Ditto for the MASA.

    > will the optimizations stop?  Will you envisage to optimize the EST
    > payloads as well?

Not in BRSKI as produced by ANIMA.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Apr 2017 11:48:48 -0400

Panos Kampanakis (pkampana) <[email-masked]> wrote:
    > About a), I don't think putting all the CA certs in the voucher is a
    > good idea. EST should be used instead. I don’t think it is right for
    > someone to expect the voucher to distribute its roots of trust. What if
    > a CA cert gets revoked of expires? EST has the transitional certs that
    > allow for root CA cert update, but I don't think we can expect someone
    > to rerun BRSKI in order to get its new root of trust.

If we are worried that the CA cert will get revoked during the validity
period of the voucher, then that implies that the pledge is going to check
CRLs and/or OCSP.
The voucher can have an expiry date, but that is only meaningful to a pledge
with a clock.  Pledges use nonces to avoid that requirement.

I don't think we say anything about the pledge putting some upper time limit
on issuing nonce->getting-voucher.  Pledges could well have relative time.

It's the job of the MASA to validate all the right CAs and CRLs, etc. and to
pick a voucher expiration time to be short enough that the pledge does not
need to worry about such things.

My opinion is that manufacturers should in many cases, simply directly pin
the public key of the owner, and issue vouchers short (and often) enough so
that there are no issues like you describe.

    > The cert chain in the voucher should only enable the client to
    > establish a trust relationship with the server. So, I think only one
    > root cert for the domain should be carried in the voucher. The rest of
    > the certs in the chain of the server cert should be sent by the server
    > in the TLS negotiation.

That works well in the private CA situation, but not in the WebPKI situation
where the root cert would be "Comodo", and every server they have validated
would be a potential owner.  But it also works poorly in a big enterprises
(a multinational oil company) where there are many potential owners of the
pledge, but a central (hierarchy of-) CA which is going to enroll all the pledges.

    > about size improvements. CMS' ASN.1 is not human friendly, but I would
    > be interested if writing the cert fields in free-form JSON and encoding
    > with CBOR/JWT would really lead to a shorter total size. In other
    > words, I am not sure going beyond JSON vouchers/tokens when talking
    > about new encodings (JWT, CBOR) is something we should tackle.

Remember that the goal isn't to initialize the pledge's trusted certificate
store for all future operations. It's just to get the pledge enrolled into
the domain's CA.  Likely all E[cd]DSA operations.

Once the device is connected to the ACP, if a NOC controller wants to
initialize a more complex set of identities, that can be done.