I’ve commented inline about these discussion.
I’ve also prepared a set of diffs to help bring clarity as per the discussion.
The diffs are in this branch:
https://github.com/anima-wg/anima-bootstrap/commit/bec6d97207aa8faaa600d60622c9b4650ee04934
> On Sep 7, 2017, at 9:19 AM, Michael Richardson <[email protected]> wrote:
>
>
> Max Pritikin (pritikin) <[email protected]> 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…
The registrar “keeps” this field by populating the prior-signed-voucher-request
(also preserving the Pledges signature over the proximity assertion).
>
>> 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…
There are two places where consistent use of Registrar cert on both legs is
referenced.
First BRSKI-08 s4.3 indicates the MASA "MAY verify” the pledge’s proximity
assertion is “consistent with the [Registrar’s Registrar's 'TLS client
certificate]”. The Registrar’s TLS client certificate chain root certificate is
then used to populate the ‘pinned-domain-cert’ (final paragraph s4.3).
Second BRSKI-08 s4.4 indicates how the Pledge completes the provisional TLS
authentication: "The 'pinned-domain-cert' element of the voucher contains the
domain CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust
anchor to immediately complete authentication of the provisional TLS
connection."
The normative language here allows for Pledges that don’t make the proximity
assertion. This also allows a Registrar to present a cert to the Pledge that is
*different* than the cert it presents to the MASA; so long as they are issued
by the same CA and so long as the MASA allows for the discrepancy. We *could*
strengthen this normative statement like so:
“If the Pledge provides a proximity assertion then the MASA MUST
verify…”
The current logic is softer to allow for more flexibility in Pledge behavior.
See my next comment:
>>> 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.
Where “just the RA cert” is a simplification, true. I think the current
language of using the pinned-domain-cert provides a set of benefits:
a) allows the RAs to change certs as needed between voucher requests
and deployments
b) simplifies log verification as its always root CA certs in the log
c) Ensures Pledges “pin” a root cert instead of a subcert within the
tree
d) For Pledges that don’t do EST they have a CA cert rather than just
an RA
(note: s4.7 indicates only that Pledges “SHOULD” continue with
EST)
Point (d) is important. If we change to a ‘registrar-cert’ we’d need to
strengthen that recommendation to a “MUST”.
>>> 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?
Its populated via the prior-signed-voucher-request (see 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.
>
> 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?
Current language is *only* the Registrar’s cert.
1) The Pledge attests to the seen “proximity-registrar-cert” by extracting the
Registrar’s TLS server cert from the TLS handshake. This is a single cert not a
chain. This new voucher request leaf name is now clearer in this point.
2) The MASA attests to the seen “pinned-domain-cert” by extracting the
Registrar’s *root CA certificate* from the PKCS#7 signature.
The changes in the above branch don’t effect the normative behavior but do
provide clarity; I suggest we adopt them. Beyond that the question at hand is:
Q1) should we make “registrar-cert” or “domain-cert” consistent around
“registrar” or “domain” or maintain the current differences?
Q2) if we move to “chain” should we move all the way to “domain-chain”? [1]
My thinking is to accept my branch’s diffs but not move toward chains.
- max
[1] What would ‘chain’ look like?
x5c is well defined as a JSON field. I’d use the structure as is. Something
like the language of https://tools.ietf.org/html/rfc7515#section-4.1.6 modified
to this:
The "proximity-domain-chain” parameter contains the X.509 public key
certificate or certificate chain [RFC5280] corresponding to the key
used for TLS server authentication by the Registrar the Pledge is
communicating with.
I have NOT made this modification.
>>> 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 <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
