Kent,
> On Apr 21, 2017, at 4:51 PM, Max Pritikin (pritikin) <[email protected]>
> wrote:
>
>>
>> On Apr 21, 2017, at 1:50 PM, Kent Watsen <[email protected]> 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) <[email protected]>
>>> wrote:
>>>
>>>>
>>>> On Apr 20, 2017, at 6:51 PM, Kent Watsen <[email protected]> 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>> _______________________________________________
>>> 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
