-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PKCS7 data support #7282
PKCS7 data support #7282
Conversation
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1587 to 1597 in a0256fc
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1600 to 1610 in a0256fc
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1642 to 1652 in a0256fc
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1655 to 1665 in a0256fc
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1694 to 1704 in a0256fc
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1707 to 1717 in a0256fc
This comment was generated by todo based on a
|
/rebase |
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1587 to 1597 in a36794b
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1600 to 1610 in a36794b
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1642 to 1652 in a36794b
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1655 to 1665 in a36794b
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1694 to 1704 in a36794b
This comment was generated by todo based on a
|
-> error valueconnectedhomeip/src/crypto/CHIPCryptoPALOpenSSL.cpp Lines 1707 to 1717 in a36794b
This comment was generated by todo based on a
|
src/crypto/CHIPCryptoPAL.h
Outdated
@@ -36,6 +36,8 @@ | |||
namespace chip { | |||
namespace Crypto { | |||
|
|||
const size_t kMax_x509_Certificate_Length = 1024; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does this come from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it appears the CSR (or elements thereof) is limited to 1024 bytes. I'm not seeing the actual certificate size limit in the spec though. I assume there has to be a limit. I'm just looking for confirmation that this is correctly set to that limit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So now I see that this was changed to 600 bytes. And indeed, the spec does clarify that the root CA certificate must be 600 or fewer bytes. But do we have different limits for ICA or NOC? This part wasn't clear to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, only root certificates have a defined max length, but this ensures standard compact sizing when dealing with a full certificate chain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I guess then I don't understand how we're supposed to succeed in this PR. It looks like the PR attempts to also store CA and leaf certs within kMax_x509_Certificate_Length bytes, even though this is only guaranteed to fit the root cert.
This doesn't seem like it will work. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 600 limit is for DAC and PAI and PAA which are DER.
For opcerts, RCAC, ICAC and NOC are supposed to be TLV certs and max 400 bytes.
Add mbedTLS implementation for PKCS7 and Pubkey Extraction methodsconnectedhomeip/src/crypto/tests/CHIPCryptoPALTest.cpp Lines 1438 to 1448 in 9136fa8
This comment was generated by todo based on a
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- PKCS Fixing company for Chris #7 is not called-out anywhere in spec
- OpCSR response has a CSR in PKCS Update cxx_rules #10
- Credentials on device are supposed to be Matter TLV certificates (see
6.4. Operational Certificate Encoding
in 0.7-core ballot version.
So the question really is: why is PKCS #7 format entering the picture at this time? What is the usage expected of introducing this in the codebase?
Most PKI systems deliver cert chain in PKCS7 format ... spec does not specify that but most Commissioners will benefit from this API. |
So is the point of this PR to add optional implementation-specific things that only some commissioners will use? Why would this code not only exist in a particular commissioning example? The code for how the chain resulting from a CSR comes in can be illustrated, but is really code that will be particular to every implementation. The PKCS 7 code added here does not appear to be used, just added to the library. Is there a subsequent PR that will introduce code depending on it? |
PKCS7 is a generic standard to encode chain certificates just as pkcs10 provides a standard way to request a certificate. We also know that commissioners will not be just apps but can also be devices. So this will have utility across many implementations - otherwise we are paving the way for forks early on in the project. Do you propose a way for a comissioner to receive a certificate chain other than pkcs7 ? We will be happy to look at it if you provide implementation example. And yes, we will push additional PR's that will make use of this function. |
/rebase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve this PR, conditional on ensuring that commissionee devices (accessories) do not see an increase flash cost due to the insertion of PKCS7 support, which only commissioner <-> CA communication would ever use, and only in some cases.
Thanks. Makes sense. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
* Add APIs to work with PKCS7 data * Initial mbedTLS function support, not yet implemented as mbedtls does not currently support pkcs7 * Update mbedTLS tests, define certificate size as per spec * Update with Andy's suggestions * Fixed duplicate changes in cryptopal * Restyle changes
Problem
Change overview
What's in this PR
Testing
How was this tested? (at least one bullet point required)
* Unit tests were added for validating certificate extraction from PKCS7 format.
* An additional test file was added, X509_PKCS7Extraction_test_vectors.h, containing dummy certificate data to be used for the added unit test.