[Anima] PKCS7 certificate SignerData certificates

[Michael Richardson <[e-mail]>]

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.

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.

Both the JRC (Registrar) and the MASA SHOULD validate signed requests are in
fact signed by the key they claim is making the request.

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.
  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.

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.

  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.


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.

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.




--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-