> On Apr 19, 2017, at 2:24 PM, Panos Kampanakis (pkampana) <[email protected]> > 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. > > 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.
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. > 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. 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 > > Rgs, > Panos > > > > -----Original Message----- > From: Anima-bootstrap [mailto:[email protected]] On Behalf Of > Max Pritikin (pritikin) > Sent: Wednesday, April 19, 2017 2:45 PM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [Anima-bootstrap] Voucher signing method > > >> On Apr 19, 2017, at 1:01 AM, peter van der Stok <[email protected]> wrote: >> >> Hi Max, >> >> thanks for the examples. >> During IETF98, I was the one to speak up in favour of #pkcs7; > > I thought so but wasn’t sure and the minutes didn’t appear to be available. > >> One reason only: It is transported by EST that is used by BRSKI. >> 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. :( > >> 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? > > 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 > >> >> Cheerio, >> >> Peter >> >> >> >> Max Pritikin (pritikin) schreef op 2017-04-18 20:08: >>> 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": >>> ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN >>> 0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1 >>> NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwW >>> TATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzq >>> WlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAM >>> CBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAw >>> RAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2 >>> oB9tsRbjmnnwuMlDXR8fzug", >>> "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNp >>> c2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4M >>> DQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG >>> 9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpE >>> gJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNV >>> HQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQj >>> lnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA7 >>> 6kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDB >>> HIx18"] >>> } >>> . >>> { >>> "ietf-voucher:voucher": { >>> "assertion": "logging", >>> "domain-cert-trusted-ca": "-----BEGIN >>> 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", >>> "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): >>> >> 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 >>> 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-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"}} >>> 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]:552DD2EE5CBC4C7C4D207F98A2519F031EE10074D674265A7DD0CA73E68BE57 >>> D >>> 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]:3065023100E60EAF73A69826077CF6B760AF9BD1C9BF723D0E84812B06B5A8B >>> 7C252362394D98E1B5B4C02D8ACD8DA5BD2248D51EA02306B5BDBDFFBB022A1E039A1 >>> 847259D2E0AA332E12D24053B3E7ECA6D18EA821E29A53D93EE3BA4DE7D8C594C5173 >>> 6511C >>> And this is the “encoded” form: >>> -----BEGIN PKCS7----- >>> 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 protected] >>> https://www.ietf.org/mailman/listinfo/anima-bootstrap > > _______________________________________________ > Anima-bootstrap mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima-bootstrap _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
