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 List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
