Menu
▾
▴
ejbca-develop
|
From: Arshad N. <ars...@st...> - 2012-05-24 20:33:43
|
Hi, Not sure if I'm reading this correctly, but does EJBCA have support for issuing/understanding certificates with the nameConstraints (OID 2.5.29.30) extension in them, so it can only issue certificates that conform to the constraint? I don't see any reference to this constraint in its documentation. I did find an old e-mail that seems to indicate that PrimeKey does NOT recommend this extension: http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html Unfortunately, because of all the problems recently with CAs being compromised, TTP CAs are now planning to enforce the use of this extension to limit their liability. However, the CA software must be able to support the use of the constraint and check all CSRs to see if the constraint is satisfied before issuing the certificate. I'm unable to find anything in EJBCA docs that indicate this is supported; can someone please provide some clarification? Thanks. Arshad Noor StrongAuth, Inc. |
|
From: Tomas G. <to...@pr...> - 2012-05-25 06:58:37
|
Hi Arshad, Currently you can use custom extensions to implement name constraints. We have done that for customers. The main responsibility is for the client, when verifying the certificate chain, to reject certificate violating the constraints. The client implementations for this is currently not perfect, with different flaws on various platforms, as our testing shows. I'd expect this to work better and be more widely deployed in the future though. Cheers, Tomas On 05/24/2012 10:14 PM, Arshad Noor wrote: > Hi, > > Not sure if I'm reading this correctly, but does EJBCA have support > for issuing/understanding certificates with the nameConstraints (OID > 2.5.29.30) extension in them, so it can only issue certificates that > conform to the constraint? I don't see any reference to this > constraint in its documentation. > > I did find an old e-mail that seems to indicate that PrimeKey does > NOT recommend this extension: > > http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html > > Unfortunately, because of all the problems recently with CAs being > compromised, TTP CAs are now planning to enforce the use of this > extension to limit their liability. However, the CA software must > be able to support the use of the constraint and check all CSRs to > see if the constraint is satisfied before issuing the certificate. > I'm unable to find anything in EJBCA docs that indicate this is > supported; can someone please provide some clarification? Thanks. > > Arshad Noor > StrongAuth, Inc. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Arshad N. <ars...@st...> - 2012-05-25 16:33:59
|
Hi Tomas,
Thanks for your response; I will look into the Custom Extensions
section of the EJBCA documentation and see how easy/difficult it is
to include the constraint in CA certificates.
However, I believe you and I may have a misunderstanding about how
the nameConstraints extension is used - although this is not the first
time RFC 5280 has been misunderstood :-). Here is how I understand it:
Section 4.2.1.10 of RFC 5280 says:
The name constraints extension, which MUST be used only in a CA
certificate, indicates a name space within which all subject names
in subsequent certificates in a certification path MUST be located.
My understanding is that the constraint exists primarily for the use
of the CA software (like EJBCA) to constrain the certificates is issues
to only the permitted sub-trees.
I do not believe application software (such as browsers, e-mail, VPN
software, etc.) need care about the nameConstraints extension even
though they see it in the CA certificates of the chain. The reason is,
they have other ways of verifying the permitted subtree.
For example, a browser checks the subjectAltName extension for the
FQDN and matches it up with the FQDN of the web-site it is connected
to. If they do not match, you get the proverbial warnings. Since the
use of SAN is universal for server SSL certificates, what would it
matter if the nameConstraint had a completely different FQDN in the
permitted sub-tree (as long as the site and the SAN FQDN matched?
Similarly, Maul User Agents are able to verify the use of a digital
certificate for S/MIME against the e-mail header - which has the
sender and recipients' e-mail addresses. What would the RFC822 name
in the nameConstraint tell the MUA that it doesn't already know?
I believe the nameConstraints extension exists primarily for the use
of CA software vendors so that issuers of certificates can constrain
the issuance of digital certificates to permit or exclude sub-trees.
Am I misunderstanding this?
Arshad Noor
StrongAuth, Inc.
On 05/24/2012 11:58 PM, Tomas Gustavsson wrote:
>
> Hi Arshad,
>
> Currently you can use custom extensions to implement name constraints.
> We have done that for customers.
>
> The main responsibility is for the client, when verifying the
> certificate chain, to reject certificate violating the constraints.
> The client implementations for this is currently not perfect, with
> different flaws on various platforms, as our testing shows.
>
> I'd expect this to work better and be more widely deployed in the future
> though.
>
> Cheers,
> Tomas
>
> On 05/24/2012 10:14 PM, Arshad Noor wrote:
>> Hi,
>>
>> Not sure if I'm reading this correctly, but does EJBCA have support
>> for issuing/understanding certificates with the nameConstraints (OID
>> 2.5.29.30) extension in them, so it can only issue certificates that
>> conform to the constraint? I don't see any reference to this
>> constraint in its documentation.
>>
>> I did find an old e-mail that seems to indicate that PrimeKey does
>> NOT recommend this extension:
>>
>> http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html
>>
>> Unfortunately, because of all the problems recently with CAs being
>> compromised, TTP CAs are now planning to enforce the use of this
>> extension to limit their liability. However, the CA software must
>> be able to support the use of the constraint and check all CSRs to
>> see if the constraint is satisfied before issuing the certificate.
>> I'm unable to find anything in EJBCA docs that indicate this is
>> supported; can someone please provide some clarification? Thanks.
>>
>> Arshad Noor
>> StrongAuth, Inc.
|
|
From: Arshad N. <ars...@st...> - 2012-05-25 16:47:41
|
I was a little hasty; I should have clarified that since the constraint allows for more than one permitted sub-tree, there will be other permitted sub-tree besides the one for which the certificate-issuance is allowed. Arshad Noor StrongAuth, Inc. On 05/25/2012 09:33 AM, Arshad Noor wrote: > > For example, a browser checks the subjectAltName extension for the > FQDN and matches it up with the FQDN of the web-site it is connected > to. If they do not match, you get the proverbial warnings. Since the > use of SAN is universal for server SSL certificates, what would it > matter if the nameConstraint had a completely different FQDN in the > permitted sub-tree (as long as the site and the SAN FQDN matched? > |
|
From: ejbca-support <ejb...@pr...> - 2012-05-25 17:31:30
|
On 2012-05-25 18:33, Arshad Noor wrote: > Hi Tomas, > > Thanks for your response; I will look into the Custom Extensions > section of the EJBCA documentation and see how easy/difficult it is > to include the constraint in CA certificates. > > However, I believe you and I may have a misunderstanding about how > the nameConstraints extension is used - although this is not the first > time RFC 5280 has been misunderstood :-). Here is how I understand it: > > > Section 4.2.1.10 of RFC 5280 says: > > The name constraints extension, which MUST be used only in a CA > certificate, indicates a name space within which all subject names > in subsequent certificates in a certification path MUST be located. > > My understanding is that the constraint exists primarily for the use > of the CA software (like EJBCA) to constrain the certificates is issues > to only the permitted sub-trees. As I understand it, name constraints is a part of path validation which means that clients indeed MUST check them as well. There was a giant discussion on PKIX recently where there was a proposal to make this a SHOULD since some leading clients do not implement this check. The prime target for name constraints are Sub-CA certificates; a root may do whatever it wants. EJBCA does currently not check name constraints but that will be added at a future date. Regards Anders > > I do not believe application software (such as browsers, e-mail, VPN > software, etc.) need care about the nameConstraints extension even > though they see it in the CA certificates of the chain. The reason is, > they have other ways of verifying the permitted subtree. > > For example, a browser checks the subjectAltName extension for the > FQDN and matches it up with the FQDN of the web-site it is connected > to. If they do not match, you get the proverbial warnings. Since the > use of SAN is universal for server SSL certificates, what would it > matter if the nameConstraint had a completely different FQDN in the > permitted sub-tree (as long as the site and the SAN FQDN matched? > > Similarly, Maul User Agents are able to verify the use of a digital > certificate for S/MIME against the e-mail header - which has the > sender and recipients' e-mail addresses. What would the RFC822 name > in the nameConstraint tell the MUA that it doesn't already know? > > I believe the nameConstraints extension exists primarily for the use > of CA software vendors so that issuers of certificates can constrain > the issuance of digital certificates to permit or exclude sub-trees. > > Am I misunderstanding this? > > Arshad Noor > StrongAuth, Inc. > > > On 05/24/2012 11:58 PM, Tomas Gustavsson wrote: >> >> Hi Arshad, >> >> Currently you can use custom extensions to implement name constraints. >> We have done that for customers. >> >> The main responsibility is for the client, when verifying the >> certificate chain, to reject certificate violating the constraints. >> The client implementations for this is currently not perfect, with >> different flaws on various platforms, as our testing shows. >> >> I'd expect this to work better and be more widely deployed in the future >> though. >> >> Cheers, >> Tomas >> >> On 05/24/2012 10:14 PM, Arshad Noor wrote: >>> Hi, >>> >>> Not sure if I'm reading this correctly, but does EJBCA have support >>> for issuing/understanding certificates with the nameConstraints (OID >>> 2.5.29.30) extension in them, so it can only issue certificates that >>> conform to the constraint? I don't see any reference to this >>> constraint in its documentation. >>> >>> I did find an old e-mail that seems to indicate that PrimeKey does >>> NOT recommend this extension: >>> >>> http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html >>> >>> Unfortunately, because of all the problems recently with CAs being >>> compromised, TTP CAs are now planning to enforce the use of this >>> extension to limit their liability. However, the CA software must >>> be able to support the use of the constraint and check all CSRs to >>> see if the constraint is satisfied before issuing the certificate. >>> I'm unable to find anything in EJBCA docs that indicate this is >>> supported; can someone please provide some clarification? Thanks. >>> >>> Arshad Noor >>> StrongAuth, Inc. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: Tomas G. <to...@pr...> - 2012-05-25 17:35:15
|
Arshad, this time I believe in my interpretation :-). Since the usage of name constraints have been actualized with the latest SSL hacks. The future usage of name constraints is layed out in a spec by Mozilla. This is the spec public CAs will have to adhere to. The spec specifies how clients should interpret this. You can never have an extension like this for the sole purpose of issuing CA software. Since the purpose is to prevent rogue CAs, who can do whatever they want, the final verdict is in the path validation algorithm in the client. If you read the path validation algorithm part in rfc5280, I think you will find the name constraints there, during path validation. (I am mobile so I cant give references to the Mozilla spec or rfc right now). The matching of altnames etc Is a completely other, unrelated thing. The purpose of name constraints is that clients should not accept a www.google.com certificate issued by the (hacked) strongauth ca, although that ca is certified by VeriSign, and issues a correct certificate with the correct distinguished name and altnames. The path validation tells the client that the strongauth ca is only permitted to issue certificates with altnames and DNs from the strongauth domain. Cheers, Tomas Arshad Noor <ars...@st...> skrev: Hi Tomas, Thanks for your response; I will look into the Custom Extensions section of the EJBCA documentation and see how easy/difficult it is to include the constraint in CA certificates. However, I believe you and I may have a misunderstanding about how the nameConstraints extension is used - although this is not the first time RFC 5280 has been misunderstood :-). Here is how I understand it: Section 4.2.1.10 of RFC 5280 says: The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. My understanding is that the constraint exists primarily for the use of the CA software (like EJBCA) to constrain the certificates is issues to only the permitted sub-trees. I do not believe application software (such as browsers, e-mail, VPN software, etc.) need care about the nameConstraints extension even though they see it in the CA certificates of the chain. The reason is, they have other ways of verifying the permitted subtree. For example, a browser checks the subjectAltName extension for the FQDN and matches it up with the FQDN of the web-site it is connected to. If they do not match, you get the proverbial warnings. Since the use of SAN is universal for server SSL certificates, what would it matter if the nameConstraint had a completely different FQDN in the permitted sub-tree (as long as the site and the SAN FQDN matched? Similarly, Maul User Agents are able to verify the use of a digital certificate for S/MIME against the e-mail header - which has the sender and recipients' e-mail addresses. What would the RFC822 name in the nameConstraint tell the MUA that it doesn't already know? I believe the nameConstraints extension exists primarily for the use of CA software vendors so that issuers of certificates can constrain the issuance of digital certificates to permit or exclude sub-trees. Am I misunderstanding this? Arshad Noor StrongAuth, Inc. On 05/24/2012 11:58 PM, Tomas Gustavsson wrote: > > Hi Arshad, > > Currently you can use custom extensions to implement name constraints. > We have done that for customers. > > The main responsibility is for the client, when verifying the > certificate chain, to reject certificate violating the constraints. > The client implementations for this is currently not perfect, with > different flaws on various platforms, as our testing shows. > > I'd expect this to work better and be more widely deployed in the future > though. > > Cheers, > Tomas > > On 05/24/2012 10:14 PM, Arshad Noor wrote: >> Hi, >> >> Not sure if I'm reading this correctly, but does EJBCA have support >> for issuing/understanding certificates with the nameConstraints (OID >> 2.5.29.30) extension in them, so it can only issue certificates that >> conform to the constraint? I don't see any reference to this >> constraint in its documentation. >> >> I did find an old e-mail that seems to indicate that PrimeKey does >> NOT recommend this extension: >> >> http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html >> >> Unfortunately, because of all the problems recently with CAs being >> compromised, TTP CAs are now planning to enforce the use of this >> extension to limit their liability. However, the CA software must >> be able to support the use of the constraint and check all CSRs to >> see if the constraint is satisfied before issuing the certificate. >> I'm unable to find anything in EJBCA docs that indicate this is >> supported; can someone please provide some clarification? Thanks. >> >> Arshad Noor >> StrongAuth, Inc. _____________________________________________ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _____________________________________________ Ejbca-develop mailing list Ejb...@li... https://lists.sourceforge.net/lists/listinfo/ejbca-develop |
|
From: ejbca-support <ejb...@pr...> - 2012-05-25 07:46:25
|
Hi Arshad,
Name Constraints have indeed gotten more attention by the PKI
community lately. EJBCA can "as is" support NCs. However, there
is *currently* no GUI support; you have to provide the data as a
DER string. Fortunately this is not overly complex to create and
here is an example of such:
Permitted
[1]Subtrees (0..Max):
RFC822 Na...@ex...
[2]Subtrees (0..Max):
Directory Address:
O=EXAMPLE
C=US
Excluded=None
This is a Java program that creates the DER code which must be code into hex in
a custom extension using the NC OID:
import org.bouncycastle.asn1.ASN1EncodableVector;
import org.bouncycastle.asn1.DERObjectIdentifier;
import org.bouncycastle.asn1.DERObject;
import org.bouncycastle.asn1.DERSequence;
import org.bouncycastle.asn1.DERTaggedObject;
import org.bouncycastle.asn1.DERUTF8String;
import org.bouncycastle.asn1.x509.GeneralName;
import org.bouncycastle.asn1.x509.X509Name;
import java.io.FileOutputStream;
public class KBBC
{
static ASN1EncodableVector v = new ASN1EncodableVector(); // this is the OtherName
static ASN1EncodableVector vec = new ASN1EncodableVector(); // this is the inner data
static void addRFC822 (String rfc822name) throws Exception
{
vec.add (new DERSequence (new GeneralName(GeneralName.rfc822Name,rfc822name)));
}
public static void main (String[] args) throws Exception
{
addRFC822 ("@example.com");
vec.add (new DERSequence (new GeneralName(GeneralName.directoryName,new X509Name ("O=EXAMPLE,C=US"))));
v.add (new DERTaggedObject(false, 0, new DERSequence(vec)));
DERObject gn = new DERSequence (v);
FileOutputStream fos = new FileOutputStream (args[0]);
fos.write (gn.getDEREncoded ());
fos.close ();
}
}
Regards,
Anders Rundgren
tech support
On 2012-05-24 22:14, Arshad Noor wrote:
> Hi,
>
> Not sure if I'm reading this correctly, but does EJBCA have support
> for issuing/understanding certificates with the nameConstraints (OID
> 2.5.29.30) extension in them, so it can only issue certificates that
> conform to the constraint? I don't see any reference to this
> constraint in its documentation.
>
> I did find an old e-mail that seems to indicate that PrimeKey does
> NOT recommend this extension:
>
> http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html
>
> Unfortunately, because of all the problems recently with CAs being
> compromised, TTP CAs are now planning to enforce the use of this
> extension to limit their liability. However, the CA software must
> be able to support the use of the constraint and check all CSRs to
> see if the constraint is satisfied before issuing the certificate.
> I'm unable to find anything in EJBCA docs that indicate this is
> supported; can someone please provide some clarification? Thanks.
>
> Arshad Noor
> StrongAuth, Inc.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
|
|
From: Arshad N. <ars...@st...> - 2012-05-25 16:35:53
|
Thank you, Anders; I will give this a shot. However, once I've added the custom extension to EJBCA, will EJBCA restrict the issuance of digital certificates based on the values in the constraint? That is, will it ensure that server SSL certificates are issued only to "strongauth.com" if the permitted sub-tree has such a restriction for DNS names? Arshad Noor StrongAuth, Inc. On 05/25/2012 12:46 AM, ejbca-support wrote: > Hi Arshad, > Name Constraints have indeed gotten more attention by the PKI > community lately. EJBCA can "as is" support NCs. However, there > is *currently* no GUI support; you have to provide the data as a > DER string. Fortunately this is not overly complex to create and > here is an example of such: > > Permitted > [1]Subtrees (0..Max): > RFC822 Na...@ex... > [2]Subtrees (0..Max): > Directory Address: > O=EXAMPLE > C=US > Excluded=None > > This is a Java program that creates the DER code which must be code into hex in > a custom extension using the NC OID: > > import org.bouncycastle.asn1.ASN1EncodableVector; > import org.bouncycastle.asn1.DERObjectIdentifier; > import org.bouncycastle.asn1.DERObject; > import org.bouncycastle.asn1.DERSequence; > import org.bouncycastle.asn1.DERTaggedObject; > import org.bouncycastle.asn1.DERUTF8String; > import org.bouncycastle.asn1.x509.GeneralName; > import org.bouncycastle.asn1.x509.X509Name; > > > import java.io.FileOutputStream; > > > public class KBBC > { > static ASN1EncodableVector v = new ASN1EncodableVector(); // this is the OtherName > static ASN1EncodableVector vec = new ASN1EncodableVector(); // this is the inner data > > static void addRFC822 (String rfc822name) throws Exception > { > vec.add (new DERSequence (new GeneralName(GeneralName.rfc822Name,rfc822name))); > } > > public static void main (String[] args) throws Exception > { > addRFC822 ("@example.com"); > vec.add (new DERSequence (new GeneralName(GeneralName.directoryName,new X509Name ("O=EXAMPLE,C=US")))); > v.add (new DERTaggedObject(false, 0, new DERSequence(vec))); > DERObject gn = new DERSequence (v); > FileOutputStream fos = new FileOutputStream (args[0]); > fos.write (gn.getDEREncoded ()); > fos.close (); > } > } > > > Regards, > Anders Rundgren > tech support > > > On 2012-05-24 22:14, Arshad Noor wrote: >> Hi, >> >> Not sure if I'm reading this correctly, but does EJBCA have support >> for issuing/understanding certificates with the nameConstraints (OID >> 2.5.29.30) extension in them, so it can only issue certificates that >> conform to the constraint? I don't see any reference to this >> constraint in its documentation. >> >> I did find an old e-mail that seems to indicate that PrimeKey does >> NOT recommend this extension: >> >> http://osdir.com/ml/java.ejbca.devel/2006-02/msg00092.html >> >> Unfortunately, because of all the problems recently with CAs being >> compromised, TTP CAs are now planning to enforce the use of this >> extension to limit their liability. However, the CA software must >> be able to support the use of the constraint and check all CSRs to >> see if the constraint is satisfied before issuing the certificate. >> I'm unable to find anything in EJBCA docs that indicate this is >> supported; can someone please provide some clarification? Thanks. >> >> Arshad Noor >> StrongAuth, Inc. >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Ejbca-develop mailing list >> Ejb...@li... >> https://lists.sourceforge.net/lists/listinfo/ejbca-develop > |
