Re: [openssl-users] Re: OpenSSL PKI Tutorial updated
Le 27/03/2014 11:14, Jeffrey Walton a écrit : On Thu, Mar 27, 2014 at 5:47 AM, Stefan H. Holek ste...@epy.co.at wrote: On 25.03.2014, at 17:44, Zack Williams wrote: ... 3. Is there a reason to not set a pathLen in the basicConstraints section of the Root CA's (to 1, to allow a maximum of one layer of CA's below the Root), but to do so on the Intermediate CA's? Pathlen is not used on root CA certs. ... RFC 5280 might disagree. For example, section 6.1.2 (k): (k) max_path_length: this integer is initialized to n, is decremented for each non-self-issued certificate in the path, and may be reduced to the value in the path length constraint field within the basic constraints extension of a CA certificate. No disagreement here. Initial value of the max_path_len is set to the length of certificate chain, and it's not taken from the BasicConstraints extension of the trust anchor. The rest of the phrase (after the first comma) explains how it will decrease, but it's detailed later in the algo. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: OpenSSL PKI Tutorial updated
Le 25/03/2014 23:08, Zack Williams a écrit :
On Tue, Mar 25, 2014 at 10:54 AM, Erwann Abalea
erwann.aba...@keynectis.com wrote:
2. I couldn't figure out what the [additional_oids] section of the
Expert example's root-ca.conf file is for - either through research or
going through the commit history. Could you elaborate on what that
accomplishes?
https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html
The OIDs are used in the CertificatePolicies extension of a subordinate CA
of this root CA.
For a policyId to be acceptable for an end-user certificate, this same
policyId (or the special value anyPolicy) MUST be present in all CAs between
this end-user cert and the root CA. The root CA is special in that it
doesn't need to contain any CertificatePolicies extension.
So these are used to group or link the certificate chain together?
No, it's about authorized uses of certificates.
Certificate policy is defined by the X.509 recommendation as:
A named set of rules that indicates the applicability of a certificate
to a particular community and/or class of application with common
security requirements. For example, a particular certificate policy
might indicate applicability of a type of certificate to the
authentication of electronic data interchange transactions for the
trading of goods within a given price range.
What identifies a specific CP is a policyId, and it's represented by an
OID. Having a policyId declared or not in a CA allows for its issuing CA
to allow or deny the right of this subCA to deliver certificates that
can be used in accordance to this CP.
Is there guidance for generating and naming this OID? Given an OID in this form:
1.3.6.1.4.1.X.Y.Z
I'm assuming that you would register the top level number (X) with the
IANA (or other appropriate issuing body), but is there guidance to
setting Y and Z, which are 7 and 8 or 9 respectively in the Expert
example?
No guidance necessary, everyone is free to shape its OID space as wanted.
3. Is there a reason to not set a pathLen in the basicConstraints
section of the Root CA's (to 1, to allow a maximum of one layer of
CA's below the Root), but to do so on the Intermediate CA's?
Because it's not used by the standardized validation algorithm (RFC5280
section 6, X.509 section 10).
I looked through RFC5280 section 6.1.4 (m), and it appears that
setting the pathLen would apply to the Root CA, and would cause
section (l) to fail on CA's created beyond the depth specified. Am I
interpreting the RFC incorrectly?
You overlooked this, in 6.1:
[...]
To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions:
(a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;
(b) certificate 1 is issued by the trust anchor;
(c) certificate n is the certificate to be validated (i.e., the
target certificate); and
(d) for all x in {1, ..., n}, the certificate was valid at the
time in question.
[...]
Point (b) is important.
Now look at 6.1.2 (Initialization), point (k):
-
(k) max_path_length: this integer is initialized to n, is
decremented for each non-self-issued certificate in the path,
and may be reduced to the value in the path length constraint
field within the basic constraints extension of a CA
certificate.
-
and you'll understand that any BasicConstraints:pathLenConstraint set in
the Trust Anchor isn't used at all.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: OpenSSL PKI Tutorial updated
Le 25/03/2014 17:44, Zack Williams a écrit : On Fri, Mar 21, 2014 at 12:25 AM, Stefan H. Holek ste...@epy.co.at wrote: I have updated the OpenSSL PKI Tutorial at Read the Docs. The tutorial provides three complete PKI examples you can play through and the prettiest configuration files this side of Neptune. Check it out! https://pki-tutorial.readthedocs.org/ This is really awesome. I've been trying to make sense of the config files for cert generation and align to best practices (when I can find them), and having good documentation is great. A few questions: 1. Is there a reason you're not using SHA-256 hash by default - it appears that SHA1 is being recommended against currently: http://www.digicert.com/sha-2-ssl-certificates.htm Good point. 2. I couldn't figure out what the [additional_oids] section of the Expert example's root-ca.conf file is for - either through research or going through the commit history. Could you elaborate on what that accomplishes? https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html The OIDs are used in the CertificatePolicies extension of a subordinate CA of this root CA. For a policyId to be acceptable for an end-user certificate, this same policyId (or the special value anyPolicy) MUST be present in all CAs between this end-user cert and the root CA. The root CA is special in that it doesn't need to contain any CertificatePolicies extension. 3. Is there a reason to not set a pathLen in the basicConstraints section of the Root CA's (to 1, to allow a maximum of one layer of CA's below the Root), but to do so on the Intermediate CA's? Because it's not used by the standardized validation algorithm (RFC5280 section 6, X.509 section 10). __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: OpenSSL PKI Tutorial updated
On Tue, Mar 25, 2014 at 10:54 AM, Erwann Abalea erwann.aba...@keynectis.com wrote: 2. I couldn't figure out what the [additional_oids] section of the Expert example's root-ca.conf file is for - either through research or going through the commit history. Could you elaborate on what that accomplishes? https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html The OIDs are used in the CertificatePolicies extension of a subordinate CA of this root CA. For a policyId to be acceptable for an end-user certificate, this same policyId (or the special value anyPolicy) MUST be present in all CAs between this end-user cert and the root CA. The root CA is special in that it doesn't need to contain any CertificatePolicies extension. So these are used to group or link the certificate chain together? Is there guidance for generating and naming this OID? Given an OID in this form: 1.3.6.1.4.1.X.Y.Z I'm assuming that you would register the top level number (X) with the IANA (or other appropriate issuing body), but is there guidance to setting Y and Z, which are 7 and 8 or 9 respectively in the Expert example? 3. Is there a reason to not set a pathLen in the basicConstraints section of the Root CA's (to 1, to allow a maximum of one layer of CA's below the Root), but to do so on the Intermediate CA's? Because it's not used by the standardized validation algorithm (RFC5280 section 6, X.509 section 10). I looked through RFC5280 section 6.1.4 (m), and it appears that setting the pathLen would apply to the Root CA, and would cause section (l) to fail on CA's created beyond the depth specified. Am I interpreting the RFC incorrectly? Thanks, Zack __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
