Subject: [pkix] Certificate with Multiple Signers?

From: Jeffrey Walton <[email-masked]>
Date: Fri, 3 Apr 2015 20:36:09 -0400

I'm trying to find some reading on PKIX certificates modulo multiple
signers. I'm getting lots of hits back, but they are for related
technologies, like CMS and RFC 4135.

Is there any IETF reading on the subject? Perhaps an old RFC or a discussion?

(I know why I want it. Now I'm trying to figure out why its a bad idea
(otherwise, we would likely have it)).

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 04 Apr 2015 06:00:43 +0200

> (otherwise, we would likely have it)).

Since there is no software out there which reads such certificates, you are
free to to do whatever you want :-)

It might be easier creating an entirely new certificate container.

BTW, multiple signers *is* probably a bad idea...

Anders

>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Santosh Chokhani <[email-masked]>
Date: Sat, 4 Apr 2015 12:11:39 +0000

I am not sure if there is any reading on it.

But, it can be accomplished by algorithm OID.  The OID semantics can dictate if two or more algorithms created the signature and how the signature is embedded.  The ASN.1 for SIGNED MACRO can accommodate that using new algorithm OID for multiple signature algorithms (and signers).

The fields like AIA and CDP can also accommodate them.

However, Issuer DN cannot.  Neither can AKID, but with AIA, AKID can be viewed as of less or no value.

Of course you will need to define your own path validation engine in terms of checking revocation using all applicable signer CDPs.

In short, lot of undefined, but one can create a profile to do this within V3 if one can live with single Issuer.

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Jeffrey Walton
Sent: Friday, April 03, 2015 8:36 PM
To: PKIX
Subject: [pkix] Certificate with Multiple Signers?

I'm trying to find some reading on PKIX certificates modulo multiple signers. I'm getting lots of hits back, but they are for related technologies, like CMS and RFC 4135.

(I know why I want it. Now I'm trying to figure out why its a bad idea (otherwise, we would likely have it)).

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 04 Apr 2015 15:05:06 +0200

> In short, lot of undefined, but one can create a profile to do this within V3 if one can live with single Issuer.

How useful would that be since there's probably no certificate processing SW out there that is likely to handle even just reading such a certificate?

Anyway, regardless if this is about adding trust through multiple attesters or if it is a crypto-algorithm thing, a more practical solution would be defining an extension holding URLs to the additional information.
By doing that you could migrate to a "better" system rather than requiring an over-the-board rewrite of everything.

Anders

---

From: John Lowry <[email-masked]>
Date: Sat, 4 Apr 2015 12:08:03 -0400

It could be useful for an authority to bind a set of attributes to a primary certificate
issued by a separate authority.  This may meet your needs without having a second
signer on the certificate.  Private extensions to an AC are certainly possible too although it
would seem constructive to bring any significant or useful extension to the working group.

See RFC 3281 and RFC 4486.  (There may be newer versions available.)

John

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 04 Apr 2015 18:37:09 +0200

> See RFC 3281 and RFC 4486.  (There may be newer versions available.)

Yes, this is still another possible application.

Now we just need to hear what Jeffrey actually had in mind :-)

Anders

>
> John
>
>
> On Apr 4, 2015, at 9:05 AM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 4 Apr 2015 16:52:52 -0400

> Now we just need to hear what Jeffrey actually had in mind :-)

I wanted to experiment with dual-signed certificates. The setup would
be a server that is accessible to the outside world, like a web server
with a X.509 certificate. Because its publicly accessible, it needs a
signature using a public CA. Internally, we use custom software, so we
certify it ourselves and don't need a public CA signature.

The internal software does not bother loading the CA Zoo. It loads all
the required certs for path validation, so it does not suffer the
"which directory" problem. The software does not even need things like
AKI's or DN's - it knows exactly what certificates should be used.

Avoiding the CA Zoo reduces attack surface, and *not* placing our CA
in the Zoo further reduces attack surface. So we don't suffer
Diginotars and SuperFishes; and we don't contribute to the problem.

I *think* multiple signers could be useful in practice. For example,
look at PKI bridging :). Or even what Google does with Google Internet
Authority G2/GeoTrust Global CA.

The thing with the Google/GeoTrust is GeoTrust certified Google's CA
(critical, CA:TRUE, pathlen:0). An additional signer could be used to
avoid the issues associated with a public CA certifying an external CA
(like governance, policy, procedure and cost).

Jeff

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 6 Apr 2015 15:38:48 +0000

Personally I don't see the point.  If what you're worried about is an active MitM who has access to a trust anchor and can issue impersonation certs, your options (in order of decreasing availability and effectiveness) are really only (a) client PKI authentication, (b) limiting the number of trust anchors in authorized clients, (c) DANE [1], or (d) pinning.  

These are the only techniques that obviate this kind of threat, and everything except client authN has limited software support available.  

Also, note that (b), (c), and (d) have the problem of being client-specific, meaning that if the *server* also wants assurance it has to have some means of verifying that the client is configured as expected.  Good luck with that.

-- T

[1] Technically DANE is a specific instance of (b), in that it can provide an out-of-band signal that tells the client which CA to expect and effectively reduces the number of anchors to 1, but getting a DANE record to the client can be a problem in itself whereas an enterprise can control the trust anchors in most clients via methods like standardized installs if they really want to.  

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Jeffrey Walton
Sent: Saturday, April 04, 2015 4:53 PM
To: Anders Rundgren
Cc: PKIX
Subject: Re: [pkix] Certificate with Multiple Signers?

> Now we just need to hear what Jeffrey actually had in mind :-)

I wanted to experiment with dual-signed certificates. The setup would be a server that is accessible to the outside world, like a web server with a X.509 certificate. Because its publicly accessible, it needs a signature using a public CA. Internally, we use custom software, so we certify it ourselves and don't need a public CA signature.

The internal software does not bother loading the CA Zoo. It loads all the required certs for path validation, so it does not suffer the "which directory" problem. The software does not even need things like AKI's or DN's - it knows exactly what certificates should be used.

Avoiding the CA Zoo reduces attack surface, and *not* placing our CA in the Zoo further reduces attack surface. So we don't suffer Diginotars and SuperFishes; and we don't contribute to the problem.

I *think* multiple signers could be useful in practice. For example, look at PKI bridging :). Or even what Google does with Google Internet Authority G2/GeoTrust Global CA.

The thing with the Google/GeoTrust is GeoTrust certified Google's CA (critical, CA:TRUE, pathlen:0). An additional signer could be used to avoid the issues associated with a public CA certifying an external CA (like governance, policy, procedure and cost).

Jeff

On Sat, Apr 4, 2015 at 12:37 PM, Anders Rundgren <[email-masked]> wrote:
>> It could be useful for an authority to bind a set of attributes to a 
>> primary certificate issued by a separate authority.  This may meet 
>> your needs without having a second signer on the certificate.  
>> Private extensions to an AC are certainly possible too although it

---

From: Michael StJohns <[email-masked]>
Date: Mon, 06 Apr 2015 12:52:15 -0400

>(otherwise, we would likely have it)).

It's mainly a bad idea because the SignerInfo is distributed throughout the certificate (e.g. IssuerName, AKI extension, and another copy of the SignatureAlgorithm) rather than collected at the bottom with the signature itself.   You'd need a pretty massive re-write of the standard to fix this.

Instead you could use either a signed extension (i.e. I think this is how you get signed time stamps into the cert) or AC as an endorsement of said certificate.   

Mike

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Apr 2015 11:11:12 -0400

Jeff,

The short answer is that X.509 and RFC 5280 do not support more than
one sig per cert. There are numerous reasons for this, including the
complexity that would arise with respect to revocation, path discovery,
path validation, etc.

Steve

---

From: [email-masked]
Date: Wed, 8 Apr 2015 04:56:57 +1000 (EST)

Without knowing why you think you need it, I don't think you need it. 
 
1. If you want to to have two more more authorities signing off on the certificate before it's issued, then do so, and have just one of them digitally sign the certificate.  The CP can specify what's going on, and the certificate OID can codify the special business process. 
 
2.  If you want the certificate issued to a subject to chain to two or more different but valid roots (for instance because the one certificate is issued in compliance with two different communities of interest, or audit regimes etc) tehn issue two certificates from the different CAs to the one subject.  Then, when the subject is trying to assert compliance with community of interest No. 1, they send to the RP a certificate chain anchored at Root 1, and when they want to demonstrate compliance with community of interest No. 2, they send a certificate chain anchored at Root 2. 
 
See slides 9-11 of the slide deck here: [ http://lockstep.com.au/library/pki/demystifying_international_cr ]( http://lockstep.com.au/library/pki/demystifying_international_cr ).
 
But maybe I'm not even warm. 
 
Cheers, 
 
Steve Wilson.
 
Lockstep 
http://lockstep.com.au 
----------------------
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 
new smart ID solutions that enhance privacy and prevent identity theft.

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 7 Apr 2015 16:04:11 -0400

> 2.  If you want the certificate issued to a subject to chain to two or more
> different but valid roots (for instance because the one certificate is
> issued in compliance with two different communities of interest, or audit
> regimes etc) tehn issue two certificates from the different CAs to the one
> subject.  Then, when the subject is trying to assert compliance with
> community of interest No. 1, they send to the RP a certificate chain
> anchored at Root 1, and when they want to demonstrate compliance with
> community of interest No. 2, they send a certificate chain anchored at Root
> 2.
Thanks Steve.

This is similar to what I am trying to accomplish; but I'm also what I
am trying to avoid. I'm trying to avoid it because it complicates
operations. For example, rather than configuring different
certificates based on a network interface (external vs internal), I
wanted to certify one certificate and serve the certificate and one
chain (well, two chains but that's just an implementation detail).

One certificate, one chain, and one server configuration makes it easy
on everyone. External software could use a CA from the CA Zoo; while
internal software could forgo the zoo and use the internal authority.

Thanks for the slides. I'll check them out later today. It may shot a
big hole in what I envisioned (as if lack of software support was not
a big enough problem).

Jeff

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 8 Apr 2015 13:13:25 +0000

I think it should be pretty clear by now that two servers and two certificates makes life easier for everyone.

Your use case is in a very small corner and doesn't deserve a standards fix.  This conversation alone has taken at least an order of magnitude more time than it would to stand up and configure a second server.

Don't let a misconception of elegance get in the way of "good enough."

-- T 

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Jeffrey Walton
Sent: Tuesday, April 07, 2015 4:04 PM
To: [email-masked]
Cc: PKIX
Subject: Re: [pkix] Certificate with Multiple Signers?

> 2.  If you want the certificate issued to a subject to chain to two or 
> more different but valid roots (for instance because the one 
> certificate is issued in compliance with two different communities of 
> interest, or audit regimes etc) tehn issue two certificates from the 
> different CAs to the one subject.  Then, when the subject is trying to 
> assert compliance with community of interest No. 1, they send to the 
> RP a certificate chain anchored at Root 1, and when they want to 
> demonstrate compliance with community of interest No. 2, they send a 
> certificate chain anchored at Root 2.
Thanks Steve.

This is similar to what I am trying to accomplish; but I'm also what I am trying to avoid. I'm trying to avoid it because it complicates operations. For example, rather than configuring different certificates based on a network interface (external vs internal), I wanted to certify one certificate and serve the certificate and one chain (well, two chains but that's just an implementation detail).

One certificate, one chain, and one server configuration makes it easy on everyone. External software could use a CA from the CA Zoo; while internal software could forgo the zoo and use the internal authority.

Thanks for the slides. I'll check them out later today. It may shot a big hole in what I envisioned (as if lack of software support was not a big enough problem).

Jeff