Re: [Anima] PKCS7 certificate SignerData certificates

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

> On Sep 5, 2017, at 6:09 PM, Michael Richardson <[e-mail]> 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.
> 
> 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.

The voucher-request has this additional requirement:

s3.3 of BRSKI-07,
      The request is a "YANG-defined JSON
      document that has been signed using a PKCS#7 structure" as
      described in [I-D.ietf-anima-voucher] using the JSON encoded
      described in [RFC7951].  The Registrar MUST sign the request.  The
      entire Registrar certificate chain, up to and including the Domain
      CA, MUST be included in the PKCS#7 structure.

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

s3.3 of BRSKI-07,

      The MASA validation checks before issuing a voucher are as follows:
      [additional requirements removed for brevity]

      Voucher signature consistency:  The MASA MUST verify that the voucher
      request is signed by a Registrar.  This is confirmed by verifying
      that the id-kp-cmcRA extended key usage extension field (as
      detailed in EST RFC7030 section 3.6.1) exists in the certificate
      of the entity that signed the voucher request.  This verification
      is only a consistency check that the unauthenticated domain CA
      intended this to be a Registrar.  Performing this check provides
      value to domain PKI by assuring the domain administrator that the
      MASA service will only respect claims from authorized Registration
      Authorities of the domain.  (The requirement for the Registrar to
      include the Domain CA certificate in the signature structure was
      stated above).

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

Actually this pinned-domain-cert is thus, from s3.2 of BRSKI-07,

   pinned-domain-cert:  In a Pledge voucher request this is the
      Registrar certificate as extracted from the TLS handshake (for
      example the first certificate in the TLS 'certificate_list'
      sequence (see [RFC5246]).  This MUST be populated in a Pledge's
      voucher request if the "proximity" assertion is populated.

I was wondering earlier today if this was confusing. We could add a leaf for “tls-domain-cert” or something. An additional point is that the *assumption* is that this is the same cert as the id-kp-cmcRA cert in the chain discussed above and in s3.3 but maybe that is an assumption too far and we should support bags of certs and arbitrary complexity? I’m tired of this PKI mess.

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

The reason s3.3. mandates the entire chain, including the domain CA certificate, is to allow the above consistency checks. But originally this was so that the domainCA certificate would be used for the pinned cert. Moving to just the RA cert in the pinned-domain-cert field would be a simplification? The text of the voucher-05 leaf description seems to allow this.

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

This is the current language and *not* that the pinned-domain-cert is populated at all. In fact if you look at the new voucher-request-yang branch and Example (2) of the voucher requests you see:

   {
       "ietf-voucher-request:voucher": {
           "created-on": "2017-01-01T00:00:02.000Z",
           "assertion": "TBD",
           "idevid-issuer": "base64encodedvalue=="
           "serial-number": "JADA123456789"
       }
   }

I was considering opening an issue about this TBD and the resulting uncertainty about the meaning of the pinned-domain-cert in this situation. 

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

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

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

- max

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