Re: [Anima-bootstrap] Voucher signing method

["Max Pritikin (pritikin)" <[e-mail]>]

> On Apr 19, 2017, at 3:59 PM, Kent Watsen <[e-mail]> 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) <[e-mail]> 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:[e-mail]] On Behalf Of Max Pritikin (pritikin)
>> Sent: Wednesday, April 19, 2017 2:45 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [Anima-bootstrap] Voucher signing method
>> 
>> 
>>> On Apr 19, 2017, at 1:01 AM, peter van der Stok <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>> 
>> _______________________________________________
>> Anima-bootstrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
> 
>