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

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

Kent, 

> On Apr 21, 2017, at 4:51 PM, Max Pritikin (pritikin) <[e-mail]> wrote:
> 
>> 
>> On Apr 21, 2017, at 1:50 PM, Kent Watsen <[e-mail]> wrote:
>> 
>> Hi Max,
>> 
>> I think what you're trying to say is that the x5c header is not under
>> the signature and therefore can be added after the fact using any text-
>> editing tool. Is that right?
> 
> No, "In the JWS Compact Serialization, no JWS Unprotected Header is used” [RFC7515]. Therefore everything in the header is under the signature. 
> Here is the specification:
> 	https://tools.ietf.org/html/rfc7515#section-5.1
> 
>   5.  Compute the JWS Signature in the manner defined for the
>       particular algorithm being used over the JWS Signing Input
>       ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
>       BASE64URL(JWS Payload)).  The "alg" (algorithm) Header Parameter
>       MUST be present in the JOSE Header, with the algorithm value
>       accurately representing the algorithm used to construct the JWS
>       Signature.
> 
> So for the original example down below the “JWS Protected Header” is:
> 
> {
> "typ": "JWT",
> "alg": "ES256",
> "x5c": ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug", "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNVHQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA76kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDBHIx18"]
> }
> 
> What I mean is that the full header, and the x5c entry, are all simple JSON structures that we already know how to deal with if we were able to build the JSON in the first place. The diffs I pointed to were because I made the mistake of thinking a JWT library would be needed… but then this limited abstraction of the library got in my way. Now that I know better i’ll avoid the extra abstraction layer (those just cause trouble).
> 
>> Actually, for that matter, I imagine that the entire thing could be 
>> constructed without the use of a JWT library - simple openssl/shell
>> script may work? - what do you think?  
> 
> Yup! That was my long winded point! :)
> 
>> For instance, here's a script for base64url:
>> https://raw.githubusercontent.com/Moodstocks/moodstocks-api-clients/master/bash/base64url.sh
> 
> That script would base64 encode the header json, then the payload json, put them together with a “.” between them before calling a simple “sign operation” of the appropriate type. In my example below I used ES256 which is defined in here: 
> 	https://tools.ietf.org/html/rfc7518#section-3.4
> 
> I can see how this is done using the openssl API but I don’t know if there is a CLI tool to perform this operation. A quick google search shows folks doing this:
> 	echo -n “${BASE64HEADER_DOT_BASE64PAYLOAD}" | openssl dgst -binary -sha256 -sign “${PRIVATE_KEY}"
> Which works ok. If you use “-hmac” and a password you get something you can verify on https://jwt.io but we’ll want to stick with ES256 I’m sure. 
> 
> Interestingly my example token is failing my local attempt to use ”openssl dgst” to verify it. So I’ve probably got something to fix. Now that I see how to do testing using openssl like this I can have my own little hackathon. ;) 

Ah. If you look at dgst.c from your openssl distribution you’ll see its just doing:
	EVP_DigestSignFinal(ctx, buf, &len)) 
then dumping the resulting signature. The format of this is a ASN1 encoding of the r and s values that are the actual signature.

You can see this by exploding the output from openssl dgst via asn1parse: 
pritikin@ubuntu:~/tmp/jwt$ openssl asn1parse -in signature.sign -inform DER
    0:d=0  hl=2 l=  69 cons: SEQUENCE          
    2:d=1  hl=2 l=  32 prim: INTEGER           :1EF9060ADA81C288C4FE2E3585BFF6379FF03467EB0D7D848D568604A1C53864
   36:d=1  hl=2 l=  33 prim: INTEGER           :EAD5AD3F8FB7092D14903C8B08D0D83EE91E898EA8D3A5944F13F8B6652372D1

So to do everything in script-land with openssl tools you need to extract the r and s values and format them correctly as specified in JWA [RFC7518, section 3.4 step 2 and 3). I’ll have to think about how you could do this from a shell script. Its interesting to note here that we have almost the simplest example of ASN1 possible and it still sounds hard to work with. :) Shrug, it isn’t like the JWA 64-octet sequence is actually that much easier from shell commands. 

My example did this extraction, padding, and binary concatenation using the openssl API ECDSA_SIG_get0 (see libjwt, jwt.c:544). 

What I think what we want is a “jws_digest” tool that does only this part. It’d work like the above openssl commands but instead of ASN1 encoding the signature it would use RFC7518 instead.

- max

> 
> - max
> 
>> 
>> K.
>> 
>> -----ORIGINAL MESSAGE-----
>> 
>> Kent, 
>> 
>>> On Apr 20, 2017, at 6:55 PM, Max Pritikin (pritikin) <[e-mail]> wrote:
>>> 
>>>> 
>>>> On Apr 20, 2017, at 6:51 PM, Kent Watsen <[e-mail]> wrote:
>>>> 
>>>> 
>>>> Hi Max,
>>>> 
>>>> I'd like to reproduce your experiment, but I can't find a library
>>>> that supports the 'x5c' header.  What do you mean that you added
>>>> it (the x5c header) to the JWS?
>>> 
>>> 
>>> The x5c header is defined in JWT but the library I used off github (libjwt) didn’t support it. After looking at the code more closely I’m not sure a jwt abstraction layer is really even needed; JWS is pretty simple to use directly. I’ve forked libjwt and will upload my diff to github tomorrow so you can see what i mean.
>> 
>> Here is a diff that shows what I mean:
>> 	https://github.com/pritikin/libjwt/commit/da7b8b9b59c26f4af6edefaeafb34ffc1f207cca
>> 
>> In summary: JWS defines a {header}.{payload}.signature method. You don’t really need a JWT library to do that. I was new to the space and wanted a quick ramp up so I used the libjwt library to experiment and found that it hardcoded the {header} information and thus couldn’t support the x5c header we were discussing. With normal, simple, JWS via a JSON library, you’d just add this element like any other normal JSON but because I was using a jwt abstraction I had to update the library’s abstraction layer to support arbitrary JSON additions to the header. 
>> 
>> - max
>> 
>>> 
>>>> 
>>>> Separately, I don't think "-----BEGIN CERTIFICATE-----" is valid
>>>> for the 'domain-cert-trusted-ca' field, for which the YANG in 
>>>> the voucher-02 draft says is a "binary" type field called 
>>>> 'trusted-ca-certificate'.  If it's type binary, then it's 
>>>> encoded as just the base64 of the DER, with no PEM header/footer
>>>> ceremony. See here:
>>>> 
>>>> https://tools.ietf.org/html/draft-ietf-netmod-yang-json-10#section-6.6.
>>> 
>>> Totally true. This was discovered at the hackathon too … I just didn’t fix it before looking at the JWT stuff.
>>> 
>>> - max
>>> 
>>> 
>>>> 
>>>> Kent
>>>> 
>>>> 
>>>> -----ORIGINAL MESSAGE-----
>>>> 
>>>> Folks, in Chicago we discussed the signing method for vouchers. 
>>>> 
>>>> Because the voucher is JSON, and there is expectation of a CBOR encoding for future work, there is an open discussion point about using the JWS/COSE signing methods; if not JWT/CWT. There was brief discussion of this at IETF98 and one person indicated they liked PKCS7, others indicates JWT and others did not speak up. Fully meeting minutes might provide more information but my recollection was that we’d move the discussion to the list. This thread is for that discussion. 
>>>> 
>>>> The current text of draft-ietf-anima-voucher-02 is:
>>>> 
>>>>> The voucher is signed a PKCS#7 SignedData structure, as specified by Section 9.1
>>>>> of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690.
>>>> 
>>>> 
>>>> For concrete discussion, the proposed change is:
>>>> 
>>>>> The voucher is a JWT [RFC7519] signed token.
>>>> 
>>>> 
>>>> I’ve updated my tooling that was used during the IETF98 hackathon to support a JWT token format; I did this as homework to be informed for the discussion. 
>>>> 
>>>> MY POSITION: is that I appreciate the simplicity of the JWS signing and feel it is a good match for us. It was easy enough to implement, was a refreshing change from the ASN1 complexity of PKCS7, and seems to provide a good path toward CBOR/COSE in a future document without maintaining PKCS7/CMS technical debt or revisiting/rewriting too much. 
>>>> 
>>>> QUESTION FOR THE WORKING GROUP: What is your position? Why? 
>>>> 
>>>> What follows is a dump of the raw JWS before signing (the equivalent PKCS7/CMS structure would be the SignedData asn1 structures which is hard to capture). After that is an encoded and signed voucher. Further below is an example of a PKCS7 signed voucher. 
>>>> 
>>>> Please note these characteristics:
>>>> 
>>>> a) From JWT RFC7519 "JWTs are always represented using the JWS Compact Serialization”. There are some JWT headers that overlap with voucher fields. I’m using JWT here; but the distinction between JWS/JWT is not fundamental to our discussion. The important point is JWS vs PKCS7. 
>>>> 
>>>> b) I’ve added the x5c header to the JWS. This is used to carry the certificate chain of the signer. Our current voucher format indicates PKCS7 which supports an equivalent field called “CertificateSet structure”. Its in the BRSKI document that we specify "The entire certificate chain, up to and including the Domain CA, MUST be included in the CertificateSet structure”. With the transition to JWT we’d be specifying that the x5c header be fully populated up to an including the Domain CA etc. 
>>>> 
>>>> c) From these examples we can’t directly compare size encodings. I don’t think this is a significant aspect of the conversation but can create comparable examples if folks feel that is necessary. 
>>>> 
>>>> The dumps:
>>>> 
>>>> A debug dump of the JWT form before encoding:
>>>> {
>>>> "typ": "JWT",
>>>> "alg": "ES256",
>>>> "x5c": ["MIIBdjCCAR2gAwIBAgIBATAKBggqhkjOPQQDAjArMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMREwDwYDVQQDDAhWZW5kb3JDQTAeFw0xNzA0MDMxNTE1NDVaFw0xODA0MDMxNTE1NDVaMC0xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxEzARBgNVBAMMClZlbmRvck1BU0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT9GTrDd0GWgwcuSy8LCn0waMeknpLznajZzqWlLhrPwshgIPIPvbyY6IyCo4uBYU/e4OO6TQD9UVLlyU5R6cA6ozAwLjALBgNVHQ8EBAMCBaAwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwCgYIKoZIzj0EAwIDRwAwRAIgAQ8YR2IdLodEE8k+JxpBOIAGuzCeT9BmFOVhFUb8eJMCIC23Goss6manRjNSmh6+2oB9tsRbjmnnwuMlDXR8fzug", "MIIBnTCCAUOgAwIBAgIJAK9Pd5G+/r0UMAoGCCqGSM49BAMCMCsxFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxETAPBgNVBAMMCFZlbmRvckNBMB4XDTE3MDQwMzE0MTAwNVoXDTE4MDQwMzE0MTAwNVowKzEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczERMA8GA1UEAwwIVmVuZG9yQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASunsQL2PVOSFWWp0oCjlqF8iVPPpEgJct931CZQ6assp07otmfgZqXsk1JYRTlKCGjROxrAiVRQsB54ioA0yu0o1AwTjAdBgNVHQ4EFgQUR4oEpb4YFuelkMrQjlnKtM01ovEwHwYDVR0jBBgwFoAUR4oEpb4YFuelkMrQjlnKtM01ovEwDAYDVR0TBAUwAwEB/zAKBggqhkjOPQQDAgNIADBFAiEA+SSOhiNQ23RWA76kZ/2u70FCpU8OsU7X9IRiWGDgIAgCIFLu8FnJuqPx10sgHvIzqI5BgOcwCa5vFQZdCDBHIx18"]
>>>> }
>>>> .
>>>> {
>>>> "ietf-voucher:voucher": {
>>>>    "assertion": "logging",
>>>>    "domain-cert-trusted-ca": "-----BEGIN CERTIFICATE-----\nMIIBUjCB+qADAgECAgkAwP4qKsGyQlYwCgYIKoZIzj0EAwIwFzEVMBMGA1UEAwwM\nZXN0RXhhbXBsZUNBMB4XDTE3MDMyNTIyMTc1MFoXDTE4MDMyNTIyMTc1MFowFzEV\nMBMGA1UEAwwMZXN0RXhhbXBsZUNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE\nRVrNlEN2ocYscAILBU7NggABo0JgA1rEGdYdCQj1nHKL6xKONJIUfBibe6iMVYd3\nRUmPwaPiHNZJ98kRwHIwnKMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQU+dVX\naXoucU1godNF0bycS1U5W54wCgYIKoZIzj0EAwIDRwAwRAIgNsCGjpEjuvz6OKJ/\n3rOvMc2ZfDhD02K+0PCVFJGCQGwCIAzf3BS6x9kKSROJJvxDSpg0QK9+b9LSFkbZ\nM1PW98AN\n-----END CERTIFICATE-----\n",
>>>>    "nonce": "ea7102e8e88f119e",
>>>>    "serial-number": "PID:1 SN:widget1",
>>>>    "serial-number-issuer": "36097E3DEA39316EA4CE5C695BE905E78AF2FB5A",
>>>>    "version": "1"
>>>> }
>>>> }
>>>> .
>>>> [signature goes here]
>>>> 
>>>> As per JWT RFC7519 this is what it looks like after URL-safe encoding. You can see that now the signature is included  (look to the second to last line to see the second “.” followed by a valid signature): 
>>>> 
>>>> eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsICAgICJ4NWMiOlsiTUlJQmRqQ0NBUjJnQXdJQkFnSUJBVEFLQmdncWhrak9QUVFEQWpBck1SWXdGQVlEVlFRS0RBMURhWE5qYnlCVGVYTjBaVzF6TVJFd0R3WURWUVFEREFoV1pXNWtiM0pEUVRBZUZ3MHhOekEwTURNeE5URTFORFZhRncweE9EQTBNRE14TlRFMU5EVmFNQzB4RmpBVUJnTlZCQW9NRFVOcGMyTnZJRk41YzNSbGJYTXhFekFSQmdOVkJBTU1DbFpsYm1SdmNrMUJVMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ5R1RyRGQwR1dnd2N1U3k4TENuMHdhTWVrbnBMem5halp6cVdsTGhyUHdzaGdJUElQdmJ5WTZJeUNvNHVCWVUvZTRPTzZUUUQ5VVZMbHlVNVI2Y0E2b3pBd0xqQUxCZ05WSFE4RUJBTUNCYUF3SHdZRFZSMGpCQmd3Rm9BVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdBUThZUjJJZExvZEVFOGsrSnhwQk9JQUd1ekNlVDlCbUZPVmhGVWI4ZUpNQ0lDMjNHb3NzNm1hblJqTlNtaDYrMm9COXRzUmJqbW5ud3VNbERYUjhmenVnIiwiTUlJQm5UQ0NBVU9nQXdJQkFnSUpBSzlQZDVHKy9yMFVNQW9HQ0NxR1NNNDlCQU1DTUNzeEZqQVVCZ05WQkFvTURVTnBjMk52SUZONWMzUmxiWE14RVRBUEJnTlZCQU1NQ0ZabGJtUnZja05CTUI0WERURTNNRFF3TXpFME1UQXdOVm9YRFRFNE1EUXdNekUwTVRBd05Wb3dLekVXTUJRR0ExVUVDZ3dOUTJselkyOGdVM2x6ZEdWdGN6RVJNQThHQTFVRUF3d0lWbVZ1Wkc5eVEwRXdXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU3Vuc1FMMlBWT1NGV1dwMG9DamxxRjhpVlBQcEVnSmN0OTMxQ1pRNmFzc3AwN290bWZnWnFYc2sxSllSVGxLQ0dqUk94ckFpVlJRc0I1NGlvQTB5dTBvMUF3VGpBZEJnTlZIUTRFRmdRVVI0b0VwYjRZRnVlbGtNclFqbG5LdE0wMW92RXdId1lEVlIwakJCZ3dGb0FVUjRvRXBiNFlGdWVsa01yUWpsbkt0TTAxb3ZFd0RBWURWUjBUQkFVd0F3RUIvekFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUVBK1NTT2hpTlEyM1JXQTc2a1ovMnU3MEZDcFU4T3NVN1g5SVJpV0dEZ0lBZ0NJRkx1OEZuSnVxUHgxMHNnSHZJenFJNUJnT2N3Q2E1dkZRWmRDREJISXgxOCJdfQ.eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2dnaW5nIiwiZG9tYWluLWNlcnQtdHJ1c3RlZC1jYSI6Ii0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLVxuTUlJQlVqQ0IrcUFEQWdFQ0Fna0F3UDRxS3NHeVFsWXdDZ1lJS29aSXpqMEVBd0l3RnpFVk1CTUdBMVVFQXd3TVxuWlhOMFJYaGhiWEJzWlVOQk1CNFhEVEUzTURNeU5USXlNVGMxTUZvWERURTRNRE15TlRJeU1UYzFNRm93RnpFVlxuTUJNR0ExVUVBd3dNWlhOMFJYaGhiWEJzWlVOQk1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVxuUlZyTmxFTjJvY1lzY0FJTEJVN05nZ0FCbzBKZ0ExckVHZFlkQ1FqMW5IS0w2eEtPTkpJVWZCaWJlNmlNVllkM1xuUlVtUHdhUGlITlpKOThrUndISXduS012TUMwd0RBWURWUjBUQkFVd0F3RUIvekFkQmdOVkhRNEVGZ1FVK2RWWFxuYVhvdWNVMWdvZE5GMGJ5Y1MxVTVXNTR3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnTnNDR2pwRWp1dno2T0tKL1xuM3JPdk1jMlpmRGhEMDJLKzBQQ1ZGSkdDUUd3Q0lBemYzQlM2eDlrS1NST0pKdnhEU3BnMFFLOStiOUxTRmtiWlxuTTFQVzk4QU5cbi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS1cbiIsIm5vbmNlIjoiZWE3MTAyZThlODhmMTE5ZSIsInNlcmlhbC1udW1iZXIiOiJQSUQ6MSBTTjp3aWRnZXQxIiwic2VyaWFsLW51bWJlci1pc3N1ZXIiOiIzNjA5N0UzREVBMzkzMTZFQTRDRTVDNjk1QkU5MDVFNzhBRjJGQjVBIiwidmVyc2lvbiI6IjEifX0.QkTUpcxv6Ng6ylyWYnlqun-5SFhD1XwLIW1kD7Y9dNwioheNMcVnowkELl_EMClyOWuLvvWuoCHAcWz_UA0IGw
>>>> 
>>>> 
>>>> Here is an equivalent PKCS7 voucher via asn1 dump. You’d have to look at the binary if you really want to decode it. This voucher was generated by MCR during the hackathon: 
>>>> 
>>>> pritikin@ubuntu:~/src/brski-project/brski_msgs$ openssl asn1parse -in mcr.voucher.txt.pkcs7
>>>> 0:d=0  hl=4 l=2706 cons: SEQUENCE          
>>>> 4:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
>>>> 15:d=1  hl=4 l=2691 cons: cont [ 0 ]        
>>>> 19:d=2  hl=4 l=2687 cons: SEQUENCE          
>>>> 23:d=3  hl=2 l=   1 prim: INTEGER           :01
>>>> 26:d=3  hl=2 l=  15 cons: SET               
>>>> 28:d=4  hl=2 l=  13 cons: SEQUENCE          
>>>> 30:d=5  hl=2 l=   9 prim: OBJECT            :sha256
>>>> 41:d=5  hl=2 l=   0 prim: NULL              
>>>> 43:d=3  hl=4 l=1644 cons: SEQUENCE          
>>>> 47:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
>>>> 58:d=4  hl=4 l=1629 cons: cont [ 0 ]        
>>>> 62:d=5  hl=4 l=1625 prim: OCTET STRING      :{"ietf-voucher:voucher":{"nonce":"62a2e7693d82fcda2624de58fb6722e5","created-on":"2017-01-01T00:00:00.000Z","device-identifier":"00-d0-e5-f2-00-01","assertion":"logged","owner":"MIIEEzCCAvugAwIBAgIJAK6rFouvk+7YMA0GCSqGSIb3DQEBCwUAMIGfMQsw\nCQYDVQQGEwJDQTEQMA4GA1UECAwHT250YXJpbzEPMA0GA1UEBwwGT3R0YXdh\nMRowGAYDVQQKDBFPd25lciBFeGFtcGxlIE9uZTERMA8GA1UECwwITm90IFZl\ncnkxGzAZBgNVBAMMEm93bmVyMS5leGFtcGxlLmNvbTEhMB8GCSqGSIb3DQEJ\nARYSb3duZXIxQGV4YW1wbGUuY29tMB4XDTE3MDMyNTE2MjkzNFoXDTE3MDQy\nNDE2MjkzNFowgZ8xCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8w\nDQYDVQQHDAZPdHRhd2ExGjAYBgNVBAoMEU93bmVyIEV4YW1wbGUgT25lMREw\nDwYDVQQLDAhOb3QgVmVyeTEbMBkGA1UEAwwSb3duZXIxLmV4YW1wbGUuY29t\nMSEwHwYJKoZIhvcNAQkBFhJvd25lcjFAZXhhbXBsZS5jb20wggEiMA0GCSqG\nSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4QYAEnTtXgiKqsfSVYkgkHddFcP34\nOU3YP7ibrsgx0i9cyj7xOzWHOF2PsoKBgTRH75MSMhTl5UidrCszlluK+qp4\nd3Zg31oQM/HDmyRJyRpY+PC1n5Vx/Mj5VagRQbqG7XTDQCfCrhqIKrKBTuPQ\n4vYKeL0tQk4UJlPIoZXEmBk5dkn/Fzl9AfIZSvUzQ1QAhQ9oaLz5Nf5MWHPK\nUY+6b2zA/yQaXduPrVuxp7xCj11C/Ljlhl1/Hx16MJrV33MCbd+RKW711D/3\n0XlWSqEprdbKbqw8WMPjuJ1aoX8aQEWoL+xbomRQQJJoFaMPlzgdDcfoAHDU\nTsxd0+FN8pFHAgMBAAGjUDBOMB0GA1UdDgQWBBSqp5TwQtHsQy9oYLZb0D5W\n+licHDAfBgNVHSMEGDAWgBSqp5TwQtHsQy9oYLZb0D5W+licHDAMBgNVHRME\nBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBgSQGacjwxmbRrrBhW63gY5KaW\nim76rG45p3uh9A8WUfMWryCUufrFOm/QEJnlUUK3QX4KEVj2eywb9gsfkiCE\nyaJzxe665Q2BrWwe3rGVkAhO/fn8upec4E1ASc31ASaF8m+pYqCCPSflL5kV\nMefHG4lEs3XJkHceClRzyXvjb5Kj/u02C5YCjcALYd8/kcSbf4joe1GufvKF\n5wvPBPkRVfbW2KagL+jw62j+8U6oB7FbxtFyqQP1YoZGia9MkPKnK+yg5o/0\ncZ57hgk4mQmM1i82RrUZQVoBP3CD5LdBJZfJoXstRlXe6dX7+TisdSAspp5e\nhNm0BcqdLK+z8ntt\n"}}
>>>> 1691:d=3  hl=4 l= 557 cons: cont [ 0 ]        
>>>> 1695:d=4  hl=4 l= 553 cons: SEQUENCE          
>>>> 1699:d=5  hl=4 l= 431 cons: SEQUENCE          
>>>> 1703:d=6  hl=2 l=   3 cons: cont [ 0 ]        
>>>> 1705:d=7  hl=2 l=   1 prim: INTEGER           :02
>>>> 1708:d=6  hl=2 l=   1 prim: INTEGER           :01
>>>> 1711:d=6  hl=2 l=  10 cons: SEQUENCE          
>>>> 1713:d=7  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
>>>> 1723:d=6  hl=2 l=  77 cons: SEQUENCE          
>>>> 1725:d=7  hl=2 l=  18 cons: SET               
>>>> 1727:d=8  hl=2 l=  16 cons: SEQUENCE          
>>>> 1729:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
>>>> 1741:d=9  hl=2 l=   2 prim: IA5STRING         :ca
>>>> 1745:d=7  hl=2 l=  25 cons: SET               
>>>> 1747:d=8  hl=2 l=  23 cons: SEQUENCE          
>>>> 1749:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
>>>> 1761:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
>>>> 1772:d=7  hl=2 l=  28 cons: SET               
>>>> 1774:d=8  hl=2 l=  26 cons: SEQUENCE          
>>>> 1776:d=9  hl=2 l=   3 prim: OBJECT            :commonName
>>>> 1781:d=9  hl=2 l=  19 prim: UTF8STRING        :Unstrung Highway CA
>>>> 1802:d=6  hl=2 l=  30 cons: SEQUENCE          
>>>> 1804:d=7  hl=2 l=  13 prim: UTCTIME           :160507023655Z
>>>> 1819:d=7  hl=2 l=  13 prim: UTCTIME           :180507023655Z
>>>> 1834:d=6  hl=2 l=  77 cons: SEQUENCE          
>>>> 1836:d=7  hl=2 l=  18 cons: SET               
>>>> 1838:d=8  hl=2 l=  16 cons: SEQUENCE          
>>>> 1840:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
>>>> 1852:d=9  hl=2 l=   2 prim: IA5STRING         :ca
>>>> 1856:d=7  hl=2 l=  25 cons: SET               
>>>> 1858:d=8  hl=2 l=  23 cons: SEQUENCE          
>>>> 1860:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
>>>> 1872:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
>>>> 1883:d=7  hl=2 l=  28 cons: SET               
>>>> 1885:d=8  hl=2 l=  26 cons: SEQUENCE          
>>>> 1887:d=9  hl=2 l=   3 prim: OBJECT            :commonName
>>>> 1892:d=9  hl=2 l=  19 prim: UTF8STRING        :Unstrung Highway CA
>>>> 1913:d=6  hl=2 l= 118 cons: SEQUENCE          
>>>> 1915:d=7  hl=2 l=  16 cons: SEQUENCE          
>>>> 1917:d=8  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
>>>> 1926:d=8  hl=2 l=   5 prim: OBJECT            :secp384r1
>>>> 1933:d=7  hl=2 l=  98 prim: BIT STRING        
>>>> 2033:d=6  hl=2 l=  99 cons: cont [ 3 ]        
>>>> 2035:d=7  hl=2 l=  97 cons: SEQUENCE          
>>>> 2037:d=8  hl=2 l=  15 cons: SEQUENCE          
>>>> 2039:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Basic Constraints
>>>> 2044:d=9  hl=2 l=   1 prim: BOOLEAN           :255
>>>> 2047:d=9  hl=2 l=   5 prim: OCTET STRING      [HEX DUMP]:30030101FF
>>>> 2054:d=8  hl=2 l=  14 cons: SEQUENCE          
>>>> 2056:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Key Usage
>>>> 2061:d=9  hl=2 l=   1 prim: BOOLEAN           :255
>>>> 2064:d=9  hl=2 l=   4 prim: OCTET STRING      [HEX DUMP]:03020106
>>>> 2070:d=8  hl=2 l=  29 cons: SEQUENCE          
>>>> 2072:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Subject Key Identifier
>>>> 2077:d=9  hl=2 l=  22 prim: OCTET STRING      [HEX DUMP]:0414258EDF2D51788F0CEC872A22FBD4FEBE0676EB07
>>>> 2101:d=8  hl=2 l=  31 cons: SEQUENCE          
>>>> 2103:d=9  hl=2 l=   3 prim: OBJECT            :X509v3 Authority Key Identifier
>>>> 2108:d=9  hl=2 l=  24 prim: OCTET STRING      [HEX DUMP]:30168014258EDF2D51788F0CEC872A22FBD4FEBE0676EB07
>>>> 2134:d=5  hl=2 l=  10 cons: SEQUENCE          
>>>> 2136:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
>>>> 2146:d=5  hl=2 l= 104 prim: BIT STRING        
>>>> 2252:d=3  hl=4 l= 454 cons: SET               
>>>> 2256:d=4  hl=4 l= 450 cons: SEQUENCE          
>>>> 2260:d=5  hl=2 l=   1 prim: INTEGER           :01
>>>> 2263:d=5  hl=2 l=  82 cons: SEQUENCE          
>>>> 2265:d=6  hl=2 l=  77 cons: SEQUENCE          
>>>> 2267:d=7  hl=2 l=  18 cons: SET               
>>>> 2269:d=8  hl=2 l=  16 cons: SEQUENCE          
>>>> 2271:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
>>>> 2283:d=9  hl=2 l=   2 prim: IA5STRING         :ca
>>>> 2287:d=7  hl=2 l=  25 cons: SET               
>>>> 2289:d=8  hl=2 l=  23 cons: SEQUENCE          
>>>> 2291:d=9  hl=2 l=  10 prim: OBJECT            :domainComponent
>>>> 2303:d=9  hl=2 l=   9 prim: IA5STRING         :sandelman
>>>> 2314:d=7  hl=2 l=  28 cons: SET               
>>>> 2316:d=8  hl=2 l=  26 cons: SEQUENCE          
>>>> 2318:d=9  hl=2 l=   3 prim: OBJECT            :commonName
>>>> 2323:d=9  hl=2 l=  19 prim: UTF8STRING        :Unstrung Highway CA
>>>> 2344:d=6  hl=2 l=   1 prim: INTEGER           :01
>>>> 2347:d=5  hl=2 l=  13 cons: SEQUENCE          
>>>> 2349:d=6  hl=2 l=   9 prim: OBJECT            :sha256
>>>> 2360:d=6  hl=2 l=   0 prim: NULL              
>>>> 2362:d=5  hl=3 l= 228 cons: cont [ 0 ]        
>>>> 2365:d=6  hl=2 l=  24 cons: SEQUENCE          
>>>> 2367:d=7  hl=2 l=   9 prim: OBJECT            :contentType
>>>> 2378:d=7  hl=2 l=  11 cons: SET               
>>>> 2380:d=8  hl=2 l=   9 prim: OBJECT            :pkcs7-data
>>>> 2391:d=6  hl=2 l=  28 cons: SEQUENCE          
>>>> 2393:d=7  hl=2 l=   9 prim: OBJECT            :signingTime
>>>> 2404:d=7  hl=2 l=  15 cons: SET               
>>>> 2406:d=8  hl=2 l=  13 prim: UTCTIME           :170325220308Z
>>>> 2421:d=6  hl=2 l=  47 cons: SEQUENCE          
>>>> 2423:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest
>>>> 2434:d=7  hl=2 l=  34 cons: SET               
>>>> 2436:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:552DD2EE5CBC4C7C4D207F98A2519F031EE10074D674265A7DD0CA73E68BE57D
>>>> 2470:d=6  hl=2 l= 121 cons: SEQUENCE          
>>>> 2472:d=7  hl=2 l=   9 prim: OBJECT            :S/MIME Capabilities
>>>> 2483:d=7  hl=2 l= 108 cons: SET               
>>>> 2485:d=8  hl=2 l= 106 cons: SEQUENCE          
>>>> 2487:d=9  hl=2 l=  11 cons: SEQUENCE          
>>>> 2489:d=10 hl=2 l=   9 prim: OBJECT            :aes-256-cbc
>>>> 2500:d=9  hl=2 l=  11 cons: SEQUENCE          
>>>> 2502:d=10 hl=2 l=   9 prim: OBJECT            :aes-192-cbc
>>>> 2513:d=9  hl=2 l=  11 cons: SEQUENCE          
>>>> 2515:d=10 hl=2 l=   9 prim: OBJECT            :aes-128-cbc
>>>> 2526:d=9  hl=2 l=  10 cons: SEQUENCE          
>>>> 2528:d=10 hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
>>>> 2538:d=9  hl=2 l=  14 cons: SEQUENCE          
>>>> 2540:d=10 hl=2 l=   8 prim: OBJECT            :rc2-cbc
>>>> 2550:d=10 hl=2 l=   2 prim: INTEGER           :80
>>>> 2554:d=9  hl=2 l=  13 cons: SEQUENCE          
>>>> 2556:d=10 hl=2 l=   8 prim: OBJECT            :rc2-cbc
>>>> 2566:d=10 hl=2 l=   1 prim: INTEGER           :40
>>>> 2569:d=9  hl=2 l=   7 cons: SEQUENCE          
>>>> 2571:d=10 hl=2 l=   5 prim: OBJECT            :des-cbc
>>>> 2578:d=9  hl=2 l=  13 cons: SEQUENCE          
>>>> 2580:d=10 hl=2 l=   8 prim: OBJECT            :rc2-cbc
>>>> 2590:d=10 hl=2 l=   1 prim: INTEGER           :28
>>>> 2593:d=5  hl=2 l=  10 cons: SEQUENCE          
>>>> 2595:d=6  hl=2 l=   8 prim: OBJECT            :ecdsa-with-SHA256
>>>> 2605:d=5  hl=2 l= 103 prim: OCTET STRING      [HEX DUMP]:3065023100E60EAF73A69826077CF6B760AF9BD1C9BF723D0E84812B06B5A8B7C252362394D98E1B5B4C02D8ACD8DA5BD2248D51EA02306B5BDBDFFBB022A1E039A1847259D2E0AA332E12D24053B3E7ECA6D18EA821E29A53D93EE3BA4DE7D8C594C51736511C
>>>> 
>>>> And this is the “encoded” form:
>>>> -----BEGIN PKCS7-----
>>>> 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 mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>> 
>>> _______________________________________________
>>> 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