Comments (9)
- All relevant standards seems to agree that the minimum size for a DirectoryString is 1.
- As you quote yourself, we SHOULD handle the value of 0, it's the CA that should force it to be positive.
- Note that version 3 means it conforms to RFC5280. The RFC says: "Implementations SHOULD be prepared to accept any version certificate", that includes unknown versions.
from openssl.
Hello @joyantaDebnath,
It is not clear to me in items 1. and 2. in your comment whether you are noting that OpenSSL will allow such certificates to be created, or just that is does not complain when verifying such certificates.
RFC 5280 is a profile of X.509, and sometimes RFC 5280 imposes restrictions on what a conforming CA may do that X.509 does not. However, RFC 5280 generally recommends that implementations of certificate validation be able to accept any valid X.509 certification path, even if the certificates were not issued in conformance with RFC 5280.
As noted in https://github.com/openssl/openssl/blob/master/doc/man1/openssl-verification-options.pod, OpenSSL has an -x509_strict flag, which should result in verification throwing a flag if the certificates were not issued in conformance with RFC 5280. Did you try this flag?
While RFC 5280 requires serial numbers to be positive, X.509 does not. So, it seems reasonable for OpenSSL to be able to issue certificates with a serial number of 0, but perhaps should flag such certificates when verifying them (but only if the -x509_strict flag is set).
The issue with empty issuer and subject names is more complex. RFC 5280 does allow for empty subject names in end-entity certificates, but not in CA certificates. RFC 5280 also says that the issuer field must contain a non-empty name. According to https://github.com/openssl/openssl/blob/master/doc/man1/openssl-verification-options.pod, OpenSSL checks for this if the -x509_strict flag is set.
The complexity is that X.509 used to allow both the issuer and subject fields to contain empty (null) names. However, it seems that has changed, and the edition from 10/2019 matches RFC 5280 in only allowing empty (null) names in the subject field of end-entity certificates.
As for the version number, that may be question for the IETF PKIX mail list. As @kroeckx noted, RFC 5280 says:
This [version] field describes the version of the encoded certificate. When extensions are used, as expected in this profile, version MUST be 3 (value is 2). If no extensions are present, but a UniqueIdentifier is present, the version SHOULD be 2 (value is 1); however, the version MAY be 3. If only basic fields are present, the version SHOULD be 1 (the value is omitted from the certificate as the default value); however, the version MAY be 2 or 3.
Implementations SHOULD be prepared to accept any version certificate. At a minimum, conforming implementations MUST recognize version 3 certificates.
Generation of version 2 certificates is not expected by implementations based on this profile.
This text in RFC 5280 is nearly identical to what was in the original version of the IETF PKIX profile (RFC 2459).
The question is whether "any version certificate" meant version 1, 2, and 3, or was it also intended to include versions that had not yet been defined? I would guess that it only intended to mean that implementations should be prepared to accept version 1, 2, and 3 certificates. I don't see how an implementation created today could be prepared to accept a version 4, 5, or 6 certificate. But, I can see how it could be interpreted the other way.
from openssl.
from openssl.
Hello @kroeckx,
Yes, you are correct and I misread @joyantaDebnath's comment. I thought @joyantaDebnath was talking about empty distinguished names (i.e., names that are SEQUENCE of 0 relative distinguished names -- 30 00):
The issuer field MUST contain a non-empty distinguished name (DN).
If the comment actually meant that it allowed the issuer and subject field to contain AttributeTypeAndValue structures where the attribute value corresponding to the attribute type is of type DirectoryString and the value is a string of length 0, then that would seem to not be allowed by the ASN.1 (e.g., c="US", o="My Company", ou="").
from openssl.
Hello @dcooper16,
Sorry for the confusion. I am concerned about only certificate chain validation, not issuance. RFC 5280 puts additional restrictions on X.509 format during certificate chain validation. My argument is implementations should conform to RFC 5280 for inter-operability and possibly security reasons.
(1) @kroeckx is spot on for (1). Please , look at this sample certificate that I created: empty_string.pem
In this certificate, the UTF8String in stateOrProvinceName attribute of Subject RDN is an empty string of SIZE 0(bytes --> 0C 00), which is not allowed by RFC 5280 as @kroeckx showed. OpenSSL does not report any error or warning for such case. I tested an found such noncompliance case is also present for Issuer RDN. It should be an easy fix to enforce this length constraints.
(2) Yes, RFC 5280 is confusing here. What do you mean by gracefully handling certificates with 0 or negative serial number
? This can be accept or reject? How about you reject such values for serial number at least with the x509_strict flag?
(3) Version 3 certificate is in the market for more than two/three decades till today. Do you think version 4, 5, 6, .... will come soon? Though the RFC 5280 says Implementations SHOULD be prepared to accept any version certificate
, I think this sentence needs to be carefully interpreted. In my opinion, any version is still within the allowed versions (1, 2, or 3). The RFC 5280 also explicitly mentioned that When extensions are used, as expected in this profile, version MUST be 3
. That means, extensions are not allowed for version > 3. Please, look at this version 9 certificate with extensions. OpenSSL does not report any error or warning. version_9.pem. How about at least enforce this in x509_strict flag?
from openssl.
from openssl.
from openssl.
from openssl.
Hello @joyantaDebnath,
I'm not an OpenSSL developer, so I won't speak to what checks OpenSSL should or should not perform to check that a CA didn't issue a malformed certificate (e.g., invalid version number or attribute value in a directory name with an invalid length).
(1) @kroeckx is spot on for (1).
Okay. In case case, I would guess this doesn't only apply to the issuer and subject name, but anywhere that a distinguished name might appear (CRL distribution points, issuing distribution point, name constraints, etc.). Have you tried other similar errors, such as a countryName attribute (2.5.4.6) that isn't a PrintableString of length 2 (e.g., one that is encoded as UTF8String or has a length of 3)?
(2) Yes, RFC 5280 is confusing here. What do you mean by
gracefully handling certificates with 0 or negative serial number
? This can be accept or reject?
I agree that "gracefully handling" is rather vague. It seems that RFC 2459 didn't say anything against CAs issuing certificates with a serial number of 0 or a negative serial number. RFC 3280 required conforming CAs to only use positive serial numbers, and added this text about gracefully handling 0 and negative serial numbers. The text wasn't changed in RFC 5280.
I would guess that either accepting or rejecting would count as "gracefully handling." I can imagine an example of not "gracefully handling" would be treating "02 01 FF" as 255 instead of -1, and thus "02 01 FF" as being the same as "02 02 00 FF."
(3) Version 3 certificate is in the market for more than two/three decades till today. Do you think version 4, 5, 6, .... will come soon? Though the RFC 5280 says
Implementations SHOULD be prepared to accept any version certificate
, I think this sentence needs to be carefully interpreted. In my opinion, any version is still within the allowed versions (1, 2, or 3).
As noted above, I agree. I think the sentence in RFC 5280 meant that implementations should be prepared to accept version 1, 2, and 3 certificates, not versions that had yet to be defined.
RFC 5280 puts additional restrictions on X.509 format during certificate chain validation. My argument is implementations should conform to RFC 5280 for inter-operability and possibly security reasons.
Can you explain what you mean by this? Section 6.1 of RFC 5280 says:
While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks.
Step (f) in Section 6.3.3 imposes a restriction that does not appear in X.509 -- when validating a CRL, the certification path for CRL must start at the same trust anchor as the certification path for the target certificate -- but I can't think of any other additional restrictions that RFC 5280 puts on validation. It has, however, been many years since I looked at RFC 5280.
from openssl.
Related Issues (20)
- Error when creating DSA key with parameter set of 512 numbits HOT 4
- Will OpenSSL consider supporting the RSA signature padding algorithm defined in ISO9796-2?
- Retrieve the names of available signature algorithms in the age of providers HOT 17
- X509_STORE_CTX_set0_dane, SSL_get0_dane, and SSL_DANE are undocumented
- Status query about CVE-2010-0928 HOT 1
- SSL_shutdown() gives SIGPIPE exception. How not to get SIGPIPE?
- Shared library should be allowed for iOS HOT 5
- Support FIPS-compliant PKCS#12 files and create them by default in FIPS mode HOT 13
- Unable to encrypt private key with encryption algo AES-256-CBC using i2d_PKCS8PrivateKey_nid_bio API HOT 2
- Support for UTF-16/32 encoded buffer in ASN1_get_object HOT 2
- [3.4] 70-test_quic_tserver.t transient failure on NonStop in thread model HOT 8
- memory leak SSL_connect 3.2.x HOT 13
- Could you provide a method to get random value k in DSA/ECDSA? HOT 1
- Test failures HOT 6
- In OpenSSL 3, ASN1_item_verify*() can return 2 on error. HOT 1
- (Premium contract) OpenSSL 1.1.1y version string needs to be fixed HOT 3
- ThreadLocalStorage leak in openssl 3.3.1 HOT 11
- Add safe way to pass shared secret to `openssl mac` and/or `openssl dgst -hmac` HOT 3
- Missing function to get compressed public EC key
- The switches `386`, `no-asm` and `no-sse2` don't disable emission of SSE2 instructions when compiling HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openssl.