> On Sep 5, 2017, at 6:09 PM, Michael Richardson <[email protected]> wrote:
>
>
> PKCS7 artifacts have three things in them:
> 1) the content (technically optional, but we need them)
> 2) a set of SignerInfo objects on the content.
> 3) within the SignerData, a bag of certificates, one or more of which has
> signed the content, and the rest which may be useful to establish a trust
> path to a CA.
Not that it matters to BRSKI, but:
The PKCS#7 structure MAY also contain revocation objects for any
intermediate CAs between the voucher-issuer and the trust anchor
known to the recipient.
> Max and Kent do we need to say anything about what's in this bag of
> certificates, or whether or not they can/should be used to validate a voucher
> or voucher request.
S6 in the voucher draft says:
The PKCS#7 structure SHOULD also contain all the certificates leading
up to and including the signer's trust anchor certificate known to
the recipient.
and S5.4 in the NETCONF zerotouch draft says:
The device MUST first authenticate the ownership voucher by
validating the signature on it to one of its preconfigured trust
anchors (see Section 5.1).
Perhaps it should add "using any addiiotional intermediate certificates
stapled to the voucher"?
> Both the JRC (Registrar) and the MASA SHOULD validate signed requests are in
> fact signed by the key they claim is making the request.
Indeed, and what Max posted seems to show that it's covered.
> In a signed voucher request from the pledge to the registrar the
> pinned-domain-cert is that of the *PLEDGE* (signed with it's IDevID).
> a) is that certificate also included in the PKCS7 bag of certificates?
> I think the answer SHOULD be yes.
Yes, see the SHOULD from S6 above.
> b) is there any operationally valid reason why there should be additional
> certificates in the PKCS7 bag?
> I can not come up with one. The registrar is never going to validate
> any chain that the manufacturer might have used internally to set up
> their CA for their IDevID. It cares about the end-certificate only.
None that I can think of.
> In a signed voucher request from the JRC (registrar) to the MASA the
> pinned-domain-cert is that of the *Registrar* (signed with it's cmcRA marked
> certificate from the domain owner's CA).
>
> a) is that certificate also included in the PKCS7 bag of certificates?
> I think the answer SHOULD be yes.
The signer of the PKCS7 SHOULD put its certificate into the SignedData
struct. Whether the same certificate is also in the payload of the
PKCS7 is inconsequential.
>> b) is there any operationally valid reason why there should be additional
>> certificates in the PKCS7 bag?
>>
>> Yes. At least the domain owner's CA and any certificates in between
>> the Registrar and the CA SHOULD be presented.
>> Should the domain owner be using a WebPKI of some sort, I think that
>> it SHOULD send it all.
>>
>> Given pinned-domain-cert (vs our previous ideas), the issued voucher
>> is going to be pinned to the Registrar's cert (not some DN specified
>> chain). But, the audit log probably ought to include the entire chain.
>>
>> Additionally, the entire chain MAY be needed in order to properly invoke
>> the sales channel integration.
>>
>> If you agree with my analysis, I will cook up some text for the newly
>> created 3.2 Examples section to explain this. Some adaptation of the
>> text above.
>
> I think we’re close to agreeing. Some comments:
>
> I like the jwt approach to certs where they include an entire “x5c” chain
> rather than a single cert. Maybe we should be copying that? In particular
> I like it better than trying to specify extra stuff in the certificate bag.
> The less we depend on the pkcs#7 structure the better and I’m willing to
> change the above uses to meet that goal.
I like a chain more than a single cert as well. I'm ambivalent to the
TA cert being provided, but I'm okay with it if it alignd better with
x5c.
>> In my code I'm doing:
>>
>> i. extract the first certificate from the PKCS7 bag, and use it to
>> verify the PKCS7, telling the verifyer not to validate the chain,
>> and not to use any certificates from the PKCS7.
>> I found that I could not find a way to access the content of the PKCS7
>> content without verifying first. I don't know if this is a ruby-openssl,
>> or underlying libssl limitation yet.
>
> This is an important point. In openssl I believe I was able to crack into the
> details without verifying and then go back and verify once I’d extracted the
> cert bags.
Wah? First, we can't assume the 1st cert is the one you want. In ASN.1
parlance, it is a SET (not a SEQUENCE). Next, my code [1] validated the
voucher's signature first - I don't understand the need to be out-of-order
here. Last, yes, you can access the contents without verification using
the smime -noverify flag.
[1]
https://github.com/netconf-wg/zero-touch/blob/master/openssl-test/device/removable-storage-device/Makefile
>> ii. I look at the content now, parse the JSON, pull pinned-domain-cert out.
>> iii. I then use the pinned-domain-cert to verify the PKCS7 again. Perhaps
>> I could do a memcpy() against what I had in step (i), and avoid the
>> second signature check if it was the same.
>>
>> I could probably be more flexible in (i) by permitting it to use the bag of
>> certificates, but telling it not to validate any chain. I feel like there
>> may be an attack lurking here because I wouldn't know which certificate
>> actually validated the object, but that's just a gut instinct.
>> {But, the above change makes the same code directly useable on the MASA as
>> well. But, really, it's only four lines}
>>
>> Alternatively, in step (i), I should try all the certificates until one
>> works, guarding aginst there being more than one.
>
> Dunno the options. I brought my code up this evening to relook at the
> pinned-cert discussion in this exact area but didn’t make any progress.
> I’ll try and look at it tomorrow.
If you have separately verified the signer cert (e.g., valid chain, etc.),
then you can use `smime -noverify -signer ...` which *only* verifies that
the signer cert signed the content (but skips verifying if the signer cert
is itself valid).
K.
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
