> On Apr 19, 2017, at 3:59 PM, Kent Watsen <[email protected]> wrote: > > >> 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,
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 > > > -----ORIGINAL MESSAGE----- > >> 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-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
