Max Pritikin (pritikin) <priti...@cisco.com> wrote:
> 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.
I feel dumb, because I was sure that I looked for such a sentence, and I
didn't find it. Good that it is there.
>> 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.
Huh, this is actually surprising...
I guess we need the Registrar to keep the same thing there, and really the
voucher *HAS* to be issued for this key in order for the Pledge to get out of
provisional state...
> 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.
Yes, that's an assumption.
The *VOUCHER* that results has to match the certificate in the TLS.
So it makes sense for the PLEDGE to indicate what certificate it is
expecting.
That lets the Registrar be built using a variety of certificates for
load balancing purposes, and deals with a race condition that could occur if
the Registrar's certificate is renewed during the imprinting process.
If a Registrar wants/needs to update it's cmcRA cert, it could present
the previously signed voucher to the MASA with previous...
>> 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.
I would like it to be just the RA cert.
>> 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:
Are you saying that pinned-domain-cert should not be populated in the
voucher request ("VR") from Registrar->MASA?
> 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.
So, our pinned-domain-cert in the VR would include the entire chain?
What format would we use? Is it just concatenated DER of certificates?
>> 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.
I believe it should be possible, but that I may not have access to the right
API from ruby-openssl. I've now upstreamed one patch for ruby-openssl, so
I'll probably fix that and upstream and another patch.
>> 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.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
