Subject: Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 02 Aug 2010 15:31:42 +0200

On Wed, 28 Jul 2010 23:03:44 +0200, Brian Smith <[email-masked]>  
wrote:

> Adam Langley wrote:
>> On Tue, Jul 27, 2010 at 6:35 AM, Yngve Nysaeter Pettersen
>> <[email-masked]> wrote:
>> > Based on the ongoing PKIX discussion about an update of OCSP, I
>> > (finally) realized the the problem my multiple-ocsp TLS extension is
>> > designed to fix can be fixed in another way, by adding an OCSP
>> > extension instead.
>>
>> I would welcome not having to change TLS to support multiple
>> OCSP responses.
>>
>> However, with TLS changes, we can deploy without any action on
>> the part of the OCSP responders. That makes it a possibility. If we
>> are beholden to updating the responders then I fear that it'll never
>> happen.
>
> Plus, it is a privacy issue. If you rely on the CAs to provide this
> extension in their OCSP responses, then any CAs that want OCSP traffic  
> (for
> user tracking) can just omit the OCSP extension. The multiple OCSP method
> lets the server improve the user's privacy without any cooperation from  
> the
> CAs involved.

This issue will not be any different from the current situation; When they  
check OCSP, clients only check the site certificate. If they check  
revocation for intermediates they use CRLs. In fact, for Opera's part, we  
retrieve CRLs while verifying the certificate, OCSP after the certificate  
has been checked, so CRLs are more "dangerous" from that perspective.

As for your MITM scenario, if the intention is to detect which computers  
access a certain site, then the attacker will already have that  
information when he performs the MITM attack.

Opera does not send or accept cookies in OCSP/CRL requests, so there would  
be no extra information available.

> (Most TLS clients issue their OCSP requests before they've
> authenticated the server's Certificate and (lack of) CertificateStatus
> messages, so while a CA wouldn't be able to force clients to make the  
> OCSP
> requests, a MiTM can still force them to do so. This could be prevented
> by moving the CertificateStatus and CertificateRequest before the
> ServerKeyExchange, and making the ServerKeyExchange signature work like  
> the
> CertificateVerify signature, hashing all the prior handshake messages.  
> This
> is something that should be considered for extensions like Snap Start  
> that
> modify the structure of the handshake, and for the next versions of TLS).
>
> Regards,
> Brian
>

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 03 Aug 2010 04:26:31 +1200

"Yngve Nysaeter Pettersen" <[email-masked]> writes:

>check OCSP, clients only check the site certificate. If they check revocation
>for intermediates they use CRLs. In fact, for Opera's part, we retrieve CRLs
>while verifying the certificate, OCSP after the certificate has been checked,
>so CRLs are more "dangerous" from that perspective.

Just out of interest, is this a pure performance optimisation, or a tacit 
recognition of the fact that no public CA cert has ever been revoked no matter 
how negligently the CA has behaved [0] (and it's unlikely that one ever will 
because the collateral damage incurred makes it politically untenable), 
therefore there's no need to spend too much time on revocation checks?

What do other implementations do?  Does anyone check CA certs for revocation
when they process a cert chain?

Peter.

[0] At least as of a few months ago.

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 02 Aug 2010 18:45:13 +0200

On Mon, 02 Aug 2010 18:26:31 +0200, Peter Gutmann  
<[email-masked]> wrote:

>> revocation

AFAIK, currently all the major browsers check for OCSP for the site  
certificates (IE for Vista and later, XP requires a preference change  
IIRC), I am not quite sure about CRLs, but checking intermediates is a  
requirement for Extended Validation verification. I didn't see any need to  
distinguish the cases, so we check CRLs for all certificates that identify  
them (and if one certificate have a CRL defined, we require them for all  
certificates below the Root, except the ones we check OCSP for, or we  
remove the padlock)

Previously, intermediate CA roots were usually issued just to the CA that  
owned the Root, now I am seeing a tendency to issue intermediate CA  
certificates to larger companies, for example. Worst case, it might be  
that it is only a question of time before an intermediate CA have to be  
revoked (That is different from revoking a Root, where the collateral  
damage will be huge if it ever happens, but in such a case the Root key  
has probably been compromised).

The optimization benefits for my proposals, is that the client need to  
check fewer online revocation resources than before, and they will  
preferably be more up to date, in the best case it does not have to check  
any online resources since the server provided them all. For the CA, there  
will ultimately be less traffic to the server, and it will depend less on  
the number of users, and more on the number of customers.

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 2 Aug 2010 11:57:46 -0500

Yngve Nysaeter Pettersen wrote:
> > (for user tracking) can just omit the OCSP extension. The multiple OCSP
> > method lets the server improve the user's privacy without any
cooperation
> > from the CAs involved.

Right. What I am saying is that your proposed extension would improve on the
current situation.

> information when he performs the MITM attack.

That is true, but often the case where Eve tells Malory that Alice did
something is less problematic than the case where Eve tricks Alice into
telling Malory herself. This would be the case when the MiTM is exploiting a
vulnerability in a web browser's OCSP and/or CRL processing. But even purely
a matter of privacy, it is something that should be avoided whenever
practical.

> be no extra information available.

It still discloses information about the user's software (browser, operating
system, and some HTTP/TLS/networking settings), information about the user's
hardware, information about the user's location (via GEO-IP targeting),
information about the site that the user is trying to contact, the time at
which the user is attempting to contact the server. Over time, the CA can
build a profile of a user--including often his employer and/or home address,
possibly even uniquely identifying the user by name--simply using
information included in "anonymous" OCSP/CRL requests. The more certificates
the CA manages, the better a profile it can build of the user, more quickly.

Consequently, anything that can prevent the user from making OCSP and CRL
requests to the CA will be a significant privacy-enhancing improvement.

Regards,
Brian

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 04 Aug 2010 04:51:04 +1200

"Yngve Nysaeter Pettersen" <[email-masked]> writes:

>certificates (IE for Vista and later, XP requires a preference change IIRC),
>I am not quite sure about CRLs, but checking intermediates is a requirement
>for Extended Validation verification. I didn't see any need to distinguish
>the cases, so we check CRLs for all certificates that identify them (and if
>one certificate have a CRL defined, we require them for all certificates
>below the Root, except the ones we check OCSP for, or we remove the padlock)

How does this impact availability?  This would make the effective availability
of a site the same as that of the least reliable CRL/OCSP server in the chain.
Do you block on all the certs checking out, or perform it in a background
thread?  Again, blocking would make the response time of the site the same as
that of the slowest-responding CRL/OCSP server in the chain.

(Feel free to reply off-list if you prefer, I'm interested in the practical
aspects of this since it availability issues are something that's never really
considered when coming up with the PKI protocols themselves.  If anyone else
has any experience with this I'd be interested in your comments as well).

>certificates to larger companies, for example. Worst case, it might be that
>it is only a question of time before an intermediate CA have to be revoked

Oh, I know of cases where private-label (i.e. signed by public CAs but not
public CAs themselves) CA certs have been revoked, at the request of the
private-label CA, e.g. due to a change of business.  They then found out that
they could still issue certs because nothing seemed to pay attention to the
revocation :-).

>The optimization benefits for my proposals, is that the client need to check
>fewer online revocation resources than before, and they will preferably be
>more up to date, in the best case it does not have to check any online
>resources since the server provided them all.

What about having public CA certs contains a special indicator in them to tell 
apps that they're revocation-proof and there's no need to check CRLs and 
whatnot, since they'll never be revoked?  That would speed up checking quite a 
bit.

Peter.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 3 Aug 2010 20:46:38 +0100

In another thread, Kyle H today wrote:
"...why not change the ASN.1 to allow for multiple individual responses in a 
SEQUENCE or SET?"

This is another possible way forward for "Multiple OCSP".

I suppose it would need a new "responseType" OID - something like...
id-pkix-ocsp-multiple  OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

The "response" OCTET STRING would contain a SEQUENCE OF (or SET OF) 
BasicOCSPResponse (rather than just a single BasicOCSPResponse).

OCSP Clients would signal their support for id-pkix-ocsp-multiple by setting 
this OID in the Acceptable Response Types OCSP Request Extension.  OCSP 
Requests can already contain multiple "CertID"s which reference certificates 
issued by different Issuers, so Clients could explicitly list all the 
certificates they want status information for, rather than rely on the 
Responder to guess which certificates in which certificate chain might be 
relevant.

One disadvantage of this approach is that the various Server software would 
need to be updated before it would be able to "staple" this kind of Response.

However, compared to Yngve's OCSP Response Extension approach, id-pkix-ocsp-
multiple would be kinder to the Responders:
  - Responders would only send the (typically larger) id-pkix-ocsp-multiple 
Responses to Clients that have signalled that they support this responseType.
  - If a Client already has an OCSP Response for some of the Intermediate CA 
Certificate(s) in a chain, it needn't include a CertID for each of them in the 
OCSP Request.  This would further decrease unnecessary network traffic to/from 
the Responders.
  - Responders that use pre-generated Responses can use the same pre-generated 
Responses for both id-pkix-ocsp-basic and id-pkix-ocsp-multiple.

> the number of users, and more on the number of customers.

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Wed, 04 Aug 2010 16:40:07 +0200

On Tue, 03 Aug 2010 18:51:04 +0200, Peter Gutmann  
<[email-masked]> wrote:

>> IIRC),

Opera has a 15-20 second timeout for such operations, as well as AIA  
intermediate CA cert retrieval, and if the timeout is triggers the URL is  
marked as "don't use" for a few hours, so the delay will be on the first  
request only.

There are requirements in the Extended Validation guidelines for being  
able to download revocation responses within a few seconds even for low  
bandwidths.

The cases where we have run into trouble have been caused by OCSP/CRL  
responders that have been specified with HTTPS URLs (rather than HTTP) and  
where the TLS certificate of the responder referenced the same revocation  
resource (an example of this have been CAcert.org), which causes a bit of  
a trouble when you suspend all other connections to that specific server  
while negotiating a session (to avoid negotiating multiple sessions for  
the same server). We have currently "solved" this problem by immediately  
failing such loops (which does not affect the revocation request)

>> check

That would cause problems if the key is compromised

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Wed, 04 Aug 2010 16:40:05 +0200

> "...why not change the ASN.1 to allow for multiple individual responses  

I suspect that this is about responses for multiple certificates for the  
same issuer.

I am not sure how well this will work for clients like Opera, since we are  
associating the response with the URL for retrieving it, we don't add it  
to a repository.
I also suspect that we will seldom encounter a certificate that was  
matched by that response anyway.

> BasicOCSPResponse (rather than just a single BasicOCSPResponse).

If you mean that the sequence should include the OCSP responses for each  
intermediate, as well as the end entity certificate, that will not work  
unless the responder is signing with a certificate issued directly from  
the Root, and which is somehow designated as the signer fore each  
certificate in the chain.

If the signer of the end entity cert was allowed to sign responses for the  
intermediate, it would be allowed to create the revocation information  
about its own status (which should only be presented by the issuer  
itself), so it would need to be a designated responder cert issued by the  
Root.

Such a designated cert would probably become logistical problem for a Root  
hierarchy that have many independent intermediates, and essentially the  
Root issuer would have to maintain a revocation service for all subCAs.

Storing the full signed response from the issuer in the response would  
prevent such a logistical problem, but would create a larger response,  
which might cause other logistical problems.

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Aug 2010 19:47:48 +0200 (MEST)

Yngve Nysaeter Pettersen wrote:
> intermediate CA cert retrieval.

Why is Opera doing something as extremely dangerous as intermediate CA Cert
retrievel based on AIA?

In the original design, the certificate path validation algorithm
described in rfc-5280 works from the trust anchor downwards to the
end entity cert -- which makes a lot of sense security-wise.

Using any information in certificates that have not been verified to
perform resource-intensive operations is a security problem.  But
accessing an arbitrary URL presented in an completely unverified
End-Entity certificate is a "Freddy Krueger" waiting for his next victim. 

-Martin

---

From: Adam Langley <[email-masked]>
Date: Wed, 4 Aug 2010 14:01:54 -0400

> End-Entity certificate is a "Freddy Krueger" waiting for his next victim.

That seems a little hyperbolic. Accessing completely unverified URLs
is something that browsers do for every single web page.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Aug 2010 20:17:37 +0200 (MEST)

Adam Langley wrote:
> > perform resource-intensive operations is a security problem. Â But

There is a difference between something that is an internal part
of the PKI-Software's certificate chain building and the (mis-)behaviour
of applications on top of it.

It it true that the problems is magnitudes worse if the PKI software
does such things in Situations where a user or admin does not
expect this (like when a TLS server requests client certificates and
silently performs AIA retrieval for client certs with incomplete
paths but AIA extension.  Or when you double-click on a
certificate file "something.cer" in Windows explorer and CryptoAPI
does the retrieval secretly.

Anyhow, I think that a PKI-Software that performs intermediate cert
retrieval based on AIA-information of an unverified certificate is
a security nightmare waiting to happen.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Aug 2010 20:26:34 +0200 (MEST)

> is something that browsers do for every single web page.

Not really.

Example scenario:

newly booted PC. User logs on, starts the web Browser (about:blank homepage)
and navigates to the HTTPS-url for his online banking.  If HTTPS works
as designed, this should be a safe operation--any "unsafe" content
that the browser would be allowed to serve/access with the consent
of the user is the content served by the online bankings site.

Now if the browser performs AIA retrieval for unverified server
certs, then this scenario is suddenly completely unprotected against
active attacks where the attacker serves a manufactured server
certificate with crafted AIA (but matching the server identity
of the online banking account in the CN= or dNSName SAN.

Essentially, that "safe mode of operation" for your web browser is gone.

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 04 Aug 2010 20:30:13 +0200

> Why is Opera doing something as extremely dangerous as intermediate CA  

Opera, and AFAIK MSIE, retrieves these specified certificates in an  
attempt to complete the incomplete chain that the server sent, and there  
are too many of those servers around (As an example, try  
https://member.ruten.com.tw/user/login.htm in a few browsers, which is at  
the time of writing missing a Versign G2 intermediate cert).

Opera only accepts these certificates if they chain to an already known  
and trusted Root, and verify successfully once the chain is completed.  
Should the downloaded certificate turn out to be a Root it is  
automatically discarded. If they pass all of this, the certificate is  
cached.

The only other alternatives are to either display a certificate warning  
for those sites, or ship with every intermediate in the Root repository.

See also http://my.opera.com/yngve/blog/2007/12/21/new-w-not-in-kestrel4  
for background.

As for danger, I would think that it is no more dangerous than going to  
arbitrary websites are already, or downloading OCSP and CRLs (which are  
also specified in the certificate).

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Marsh Ray <[email-masked]>
Date: Wed, 04 Aug 2010 13:30:51 -0500

On 08/04/2010 01:01 PM, Adam Langley wrote:
> On Wed, Aug 4, 2010 at 1:47 PM, Martin Rex<[email-masked]>  wrote:

So if someone sent you a list of every known attack site you'd see no 
problem with visiting them all?

What if the attacker got to choose just one for you to visit?

Just got back from Defcon, the "top tweet" was "I strongly recommend 
against hitting jailbreakme.com from the #defcon wifi. Modifying that 
payload for malicious pwnage is not hard."
https://twitter.com/esizkur/status/20089522350

This is where the "in theory/practice there is/is not a difference 
between practice/theory" gets real. Probably the best approximation of 
the truth is somewhere in between.

Retrieving a cert via HTTP as part of the validation process is surely 
not as risky as running a web page with all types of active content and 
3rd party plugins, and if there's an exploitable bug in those lower HTTP 
or X509 layers, you're probably already owned.

But this isn't the kind of risk that's statistical, like earthquakes or 
meteors. The attacker gets to choose nearly all of the inputs to the 
transaction. He can thus select the tiniest, most vulnerable, part of 
the possible parameter space and only needs to be right once.

So is seems to me the best design principle is to avoid unnecessary 
interactions with unverified servers and handling unverified data as 
much as practical. When it's done, it should be with at least some 
justification and an acknowledgement it's a risk/benefit tradeoff.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Aug 2010 20:43:26 +0200 (MEST)

> automatically discarded. If they pass all of this, the certificate is  

As far as the AIA vulnerability is concerned, you're 0wnd as soon
as your software connects to the crafted URL in the crafted server
certificate.  It doesn't matter that whether you discard the reply
and abort the original browser connection at that point.  If you're
attacked, that URL is often not going to result in a certificate anyway.

> for those sites, or ship with every intermediate in the Root repository.

How about warning on first encounter and offer the User to download
and memorize the intermediate cert -- or to NOT download?

> also specified in the certificate).

As previously described, the certificate path validation algorithm
specified in rfc-5280 works from the trust anchor downwards to
the End Entity cert, and will reliably protect you from accessing
OCSP or CRL information from untrusted/unverified certificates.

AIA retrieval works upwards with information from completely unverified
and untrusted certs.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Aug 2010 21:15:22 +0200 (MEST)

> the time of writing missing a Versign G2 intermediate cert).

You mean that this web-server is sending a server certificate from a
certification path that ends at a self-signed rootCA which the browser
already trusts, but the server does not include the intermediate CA
certificate that is necessary to validate the server certificate?

An implementation compliant to any of the TLS v1.x specifications
would have to abort the handshake with such a server due to an
clear protocol violation.  The server MAY omit the self-signed
rootCA cert at the end of his certification path, but omitting
any of the intermediate CA certs is not permitted.

http://tools.ietf.org/html/rfc5246#page-48

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 4 Aug 2010 15:31:50 -0400

>attacked, that URL is often not going to result in a certificate anyway.

First, real browsers already allow mixed content frames with silent renegotiation *and* late-binding of request authentication, and you're worried about exploiting AIA retrieval?

Second, having identified a problem behavior, what's the fix?  Path discovery is critically important in bridged PKIs, so if chasing AIAs is a Bad Thing, what do we do instead?

>and memorize the intermediate cert -- or to NOT download?

I fail to see how this improves the situation, since we already know users are ill-equipped to make these decisions anyway.  In addition, components without a UI do what?

>OCSP or CRL information from untrusted/unverified certificates.

Only when the pool used by the PVM contains all the certificates identified in the path.  When the pool is incomplete, or the protocol provides no path (e.g., CMS allows SignedData to elide any and all certificates if the relying party can be expected to have *or discover* them), what does the PVM do?

Failing is "safe" from a security standpoint, but I'd contend that if you put that into a real system it would simply fail to meet any practical definition of the term "functional."

-- Tim

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Aug 2010 21:58:45 +0200 (MEST)

Miller, Timothy J. wrote:
> First, real browsers already allow mixed content frames with silent
> renegotiation *and* late-binding of request authentication, and you're
> worried about exploiting AIA retrieval?

There is a significant difference between being vulnerable to a content
from a site one has chosen to access through HTTPS and being vulnerable
to an arbitrary active attacker on every connect.

> 
> Second, having identified a problem behavior, what's the fix?
> Path discovery is critically important in bridged PKIs, so if
> chasing AIAs is a Bad Thing, what do we do instead?

I don't know who invented the concept of automatic AIA retrieval, but
my personal intuition points to the S/Mime camp.  S/Mime is notoriously
broken as far as the inclusion of certificates is concerned (being a
heritage from PKCS#7).

SSL & TLS on the other hand have had the clear requirement to send only
complete certification chains from the beginning.  So there this issue
does not exist unless the server is misconfigured and the server PKI
software is defective because it does not refuse to perform SSL handshakes
with incomplete certificate chains, something that the SSL & TLS specs
have never allowed and which is fairly trivial for the server software,
the credential management part in particular, to verify and report
to the admin upfront when setting up that server.

> I fail to see how this improves the situation, since we already know
> users are ill-equipped to make these decisions anyway.

This is a clear TLS protocol violation, so if anything deserves
a scary page to be presented to a user, this is such a situation.

>
> In addition, components without a UI do what?

Fail unconditionally.  That is the only safe reaction, and since
it is a clear TLS protocol violation, it is quite appropriate.

> Only when the pool used by the PVM contains all the certificates
> identified in the path.  When the pool is incomplete, or the protocol
> provides no path (e.g., CMS allows SignedData to elide any and all
> certificates if the relying party can be expected to have *or discover*
> them), what does the PVM do?

S/Mime and CMS are foobar.  An implementation of TLS should not try
to work around design flaws of a non-TLS protocol in such an insecure
and questionable fashion.

The sitation for TLS is clear, the server needs to provide a full
certificate chain and may omit only the self-signed root.

There is more flexibility in the TLS protocol (although not explicitly
written out) for verifying the client certificate.  The CertificateRequest	handshake message includes a list of certification authorities which
the server indicates to trust (i.e. being able to verify certs issued
by these CAs), so the client could build a certificate chain up to
one of the certification authorities announced by the server.

PKIs with bridge CAs are not natively supported by TLS for the server
certificate.  Adding support would be possible through a ClientHello
extension where the client announces the names of those bridge CAs.

> 
> Failing is "safe" from a security standpoint, but I'd contend that
> if you put that into a real system it would simply fail to meet any
> practical definition of the term "functional."

AIA is a pretty dangerous idea designed to work around design flaws
of an installed base of PKCS#7/CMS/SMime.  Ignoring the security
implications of such a hack is a bad idea, in particular for protocols
that originally do not suffer from such a design flaw.  And doing it
in a secretive fashion out of sight from the user of the technology
is a particularly bad idea!

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 04 Aug 2010 15:02:44 -0500

On 08/04/2010 02:31 PM, Miller, Timothy J. wrote:
> renegotiation *and* late-binding of request authentication, and
> you're worried about exploiting AIA retrieval?

If it's potentially a problem, then it needs to be worried about. Unlike 
mass-energy, insecurity not conserved. We have an unlimited supply of 
it, so having it in one place doesn't diminish it elsewhere. 
Unfortunately, our capacity to be concerned is finite so we end up 
prioritizing resources over "degrees of brokenness".

Historically, it's shown to be unreliable to expect a small security 
problem to stay small. The network changes dramatically over the years 
while the protocols largely stay the same. What seems obscure or 
unlikely in one context may end up enabling an entirely new vector of 
attack in another.

For example, is this outbound connection willing to authenticate with 
the credentials of the user? Nearly every form of user credentials have 
turned out to be forwardable in one way or another.

> Second, having identified a problem behavior, what's the fix?  Path
> discovery is critically important in bridged PKIs, so if chasing AIAs
> is a Bad Thing, what do we do instead?

Good question.

It may be enough to agree on what the security context of such a request 
ought to be. For example, what should be done with cookie headers that 
might be returned? How does this interact with same-origin policies? 
When are redirects valid? Maybe all this is covered in a document 
already, does every system implement it? Is there a thorough test suite 
or audit tool available?

> Failing is "safe" from a security standpoint, but I'd contend that if
> you put that into a real system it would simply fail to meet any

At some point we have to accept the fact that the entire purpose of 
security is to make the protected resource harder to access in one 
respect or another. The security/convenience tradeoff isn't going away, 
the best we can do is attempt to optimize it for the most common cases.

- Marsh

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 4 Aug 2010 16:14:33 -0400

>any of the intermediate CA certs is not permitted.

Consider:

- Agency A and Agency B each have internal PKIs.
- Agency A and Agency B mutually cross-certify.
- An End Entity from Agency A connects to an Agency B service.
- The service provides a ServerCertificate message containing it's certificate and the complete path.
- Complying with TLS1.2, the path supplied by the service may or may not include the Agency B's root CA certificate.

>From the user's perspective, the path supplied by the service is *both* compliant with TLS *and* incomplete, because it does not terminate at the Agency A trust anchor.  The server can do nothing to help, because the server has no way to predict *which* certificate path will be acceptable to the client, and in a large bridged environment the number of possible paths can be very, very large.

On the other hand, a browser has two options.  It can fail path validation (which usually results in a warning and a click-through), or it can enter path *discovery*, find the A->B cross certificate, and validate that path instead.  (While in the simple case here this is trivial, in the broader case--e.g., the FBCA environment--it is not.)

Failure is not the correct option because a trust path *does* exist.

I think the problem here is TLS presumes a simple PKI.  To quote from TLS1.2 7.4.2, "[The Server Certificate] message conveys the server's certificate chain to the client."  This is demonstrably not true (see above); the Server Certificate message conveys *one possible* chain to the client.  If that chain is not acceptable to the client, the client *must* find one that is.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 4 Aug 2010 16:33:51 -0400

See my other message.  The problem here is TLS does not admit of PKIs with more complex pathing requirements or inter-relationships.

-- Tim

>-----Original Message-----
>From: Martin Rex [mailto:[email-masked]]
>Sent: Wednesday, August 04, 2010 2:59 PM
>To: Miller, Timothy J.
>Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [pkix] [TLS] New version of Multiple OCSP mode of
>Certificate
>
>written out) for verifying the client certificate.  The
>CertificateRequest     handshake message includes a list of
>certification authorities which

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Aug 2010 22:39:08 +0200 (MEST)

> turned out to be forwardable in one way or another.

Possible problems;+

That crafted AIA-request could potentially "leak" information,
including sensitive information through a protocol of the attackers
choice to a target of the attackers choice (cookies, other
http-header-field contents, http-refererrers, basic authentication
credentials).

That crafted AIA-request could be accessing resources that are not
accessible to the attacker himself with a protocol of the attackers choice
and result in reaction that help the attacker in carrying out a more
complex attack (like opening ports on a NAT-style firewall).

That crafted AIA-request could potentially reuse existing credentials
or single sign-on information for a normally internal/trusted resource
with attacker-supplied URL arguments (cookie-based, rfc-4559-based
or client-certificate-based).

Even when the crafted AIA-request access resouces on some external
resouce (originally accessible to the attacker), the attacker might
entice the lighthearted AIA-follower to employ any kind of locally
available credentials by first playing DNS tricks on the client.
How safe is the installed base to inappropriate glue records
on _valid_ DNS lookup/responses -- something that should be doable
as a side effect of HTTP-redirects or multiple URLs with initial
failure of attacker-supplied AIA URIs?

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 04 Aug 2010 23:10:30 +0200

> http-header-field contents, http-refererrers, basic authentication

Opera's AIA/OCSP/CRL requests are sent with cookies, referrers, etc.  
disabled; and additionally anything which would cause a user-interaction  
will immediately cause the request to fail.

At most the request will display what it sends to other server from a  
clean install, the usual set of Accept headers and other normal HTTP  
headers.

> complex attack (like opening ports on a NAT-style firewall).

Opera have policies in place that prevent many kinds of cross  
network-category attacks, including that one.

As for AIA itself, I will note that it is documented in RFC 5280, sec.  
4.2.2.1 for precisely the purpose it is being used for by Opera

    In a public key certificate, the id-ad-caIssuers OID is used when the
    additional information lists certificates that were issued to the CA
    that issued the certificate containing this extension.  The
    referenced CA issuers description is intended to aid certificate
    users in the selection of a certification path that terminates at a
    point trusted by the certificate user.

The kind of crafted URLs you are concerned about can also be injected by  
way of OCSP and CRL URLs, and OCSP is AFAICT actually supported by more  
clients than AIA CA.

Also, injecting those URLs also indicate either the ability to trick the  
user into visiting the malicious site, or the attacker already have  
complete control over the user's unencrypted connection, in which case  
there are far easier ways to inject such URLs for most purposes.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Rob Stradling <[email-masked]>
Date: Wed, 4 Aug 2010 23:04:05 +0100

> I suspect that this is about responses for multiple certificates for the

I suspect not.  BasicOCSPResponse already allows a single Response to contain 
status information about multiple certificates for the same issuer.

In fact, BasicOCSPResponse already allows a single Response to contain status 
information about multiple certificates from *multiple issuers*.  The problem, 
of course, is that a BasicOCSPResponse may only be signed by a single entity, 
so this kind of Response could only ever be useful in a "local configuration 
of OCSP signing authority" (RFC 2560 section 4.2.2.2 option 1) context.

> associating the response with the URL for retrieving it, we don't add it

First you wanted to try to avoid requiring updates to Servers that already 
support OCSP "stapling".  Are you now suggesting that Clients cannot be 
updated either?

> intermediate, as well as the end entity certificate,

Yes, I do mean that.

> that will not work unless the responder is signing with a certificate issued
> directly from the Root, and which is somehow designated as the signer fore
> each > certificate in the chain.

I say it will work.  You seem to be assuming that each BasicOCSPResponse in 
the SEQUENCE/SET would contain a signature generated by the same 
key/certificate.  I never said that.  Rather, each BasicOCSPResponse in the 
SEQUENCE/SET would contain a signature generated by a key/certificate that is 
authorized to sign it.  If the Responder is not authoritative for one (or 
more) certificates in the chain, then it could either i) "staple" a valid 
BasicOCSPResponse obtained from another Responder, or ii) simply not include a 
BasicOCSPResponse for this certificate (which would cause the Client to try 
looking somewhere else for status info about that certificate).

> Root issuer would have to maintain a revocation service for all subCAs.

This is a different idea.

If we could designate the Root Certificate and/or a designated Responder 
certificate issued by the Root Certificate as "Authorized Responders" for 
signing OCSP Response information for all certificates in the chain, then the 
existing ASN.1 would be sufficient for "Multiple OCSP".
However, Clients, Servers and Responders would all need code updates.  Also, 
there would be nothing technically to prevent Root Certificate A from cross-
certifying Root Certificate B (without Root Certificate B's consent), which 
would give Root Certificate A the power to make up OCSP status information for 
all certificates that chain up to Root Certificate B.

> which might cause other logistical problems.

"Storing the full signed response from the issuer in the response" is what my 
previous post proposed.

My proposal wouldn't "create a larger response", but it would require ASN.1 
changes.

Rob Stradling

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Aug 2010 01:07:22 +0200 (MEST)

> will immediately cause the request to fail.

I'm slightly more concerned about what MSIE will do, because that
is still a pretty common browser supplied to IT departments...

The issue is, that it is so easy to get it wrong, that some implementations
are going to get it wrong.  If commercial CAs issue X.509v3 CA(!) certs
without Basic Constraints and KeyUsage, and none of the browser vendors
complains about this, but instead ship it as pretrusted, then I have
little hope about this one.

> network-category attacks, including that one.

Huh?  How?

The idea to check digital signatures only with trusted keying material
is that an attacker can not entice you to verify digital signatures
with megabit-sized keys that aren't trusted anyway.  While I could
think of effective plausibility checks for key sizes, it is currently
unclear to me how you limit to which hosts AIA could connect.
An attacker could certainly add an IP-address of your internal
network to a DNS zone under his control, and what about HTTP redirects?

>     point trusted by the certificate user.

Well, at least rfc-5280 includes the conscious user firmly within
the loop of "aid certificate users in the seledtion of a certification
path".

The concern that I've been voicing is AIA-retrieval without involving
the conscious decision of a user to access a arbitrary resource from
a completely untrusted potential attacker.

> way of OCSP and CRL URLs, and OCSP is AFAICT actually supported by more  

That is incorrect.  The path validation algorithm checks cryptographic
correctness and certificate (attribute) validity starting at a trust
anchor first, and ONLY when that succeeds, CRLs and OCSP is checked.
So when doing path validation correctly, you never access untrusted
CRL and OCSP resources.

> there are far easier ways to inject such URLs for most purposes.

A user that only ever used HTTPS to access only sites that he trusts
was originally protected from attackers capable of blindly injecting
a ServerHello+ServerCertificate data into the receiving side of 
a new TCP to someone elses Web Server on port 443.
(or any other outgoing protocol involving SSL/TLS for
generic TLS implementations other than browsers with AIA-retrieval).

The use of SSL should make users of that technology _more_ secure,
and avoid "adding value" of the kind of an significant additional
attack surface to the software and environment of the user.

Concerning sensible client behaviour:
3 years ago I received an S/Mime signed EMail confirming the order
of a replacement keycard for my (company car) from the maintenance
contractor.  There were two certs included in the S/Mime signature
(signature cert of contractors employee and cert of an intermediateCA),
but the Root CA (CN=RootCA <Car-Manufacturer>, O=<car-manufacturer>"
was missing and is not publicly available (I still don't have it today).
While MS CryptoAPI might be capable and willing to perform extremely
dangerous things as secretly accessing arbitrary attacker-supplied
AIA-cert-locations, I find myself completely unable (w2k3) to mark that
intermediateCA cert as trusted and get the signature verified.
(the option to select the signer cert as trusted is greyed out, which
 might be a group/domain policy issue either based on dumb defaults
 or deliberate choice of an uninformed admin).

So by leaving it up to implementors to come up with sensible
implementation choices for security-relevant characteristics,
you may easily end up with something that's both insecure and
usability-impaired...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Aug 2010 19:11:38 -0500

> anchor first, and ONLY when that succeeds, CRLs and OCSP is checked.

That's true of path _validation_.  It's not necessarily true of path
_construction_ (see RFC4158).  That is, if you start with an EE cert you
might have to go find the intermediate CA certs.

> So when doing path validation correctly, you never access untrusted

If you're building a path from the target to the anchor then you'll
probably want to prune paths as soon as possible by validating
intermediate CA certs as soon as possible.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Aug 2010 03:03:15 +0200 (MEST)

> might have to go find the intermediate CA certs.

I don't know rfc4158, but I don't see how a standardization level
should marginalize a severe security problem.  The TLS renegotation
problem was not less severe by working-as-specified and being
commonly implemented in the installed base.  :-/

And I see a big difference in a user trying to manually and interatively
construct a certification path and consciously deciding to include
individual, not necessarily pre-trusted sources of information --
as long as it is not possible for an attacker to entice this
construction to perform accesses to arbitrary resources without
limits and entirely without critical consent and interaction of
the entity doing the path construction.

While the relative ordering of 6.1.3 a1, a2, a3 makes a lot of sense
security-wise, I'm confused to see a4 as the last check instead of
the first(!) one.  Comparison of the issuer field should be a memcmp()
on a ASN.1 DER encoded DName, and it looks odd to suggest doing a likely
expensive public key operation before a trivial memcmp() without
a rationale (I can not currently think of a rationale for this).

http://tools.ietf.org/html/rfc5280#section-6.1.3

> intermediate CA certs as soon as possible.

Validating in the form of pruning "expired" or otherwise clearly
inappropriate certs based on "cheap" plausibility checks on certificate
attributes?  Maybe to a limited extent.  Public key crypto operation
with untrusted keying material or even worse, network access based
on URIs from untrusted sources -- certainly not without explicit
user/operator confirmation!

For the case of TLS, however, it has always been a clear requirement
for each communication peer to build and send one own's certificate
in a complete and corretly ordered sequence, optionially omitting
at most the self-signed root certificate at the end of that chain.
So really, a server with a certificate from a fancy briged CA should
definitely, similar to the "server name indication" get a TLS
ClientHello extension defined and have the client provide hints
about the trust anchors if the server is unable to send a certificate
chain acceptable to the client's certificate path validation
algorithm as-is without such information.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Aug 2010 20:54:44 -0500

> commonly implemented in the installed base.  :-/

FYI, RFC4158 is Informational.  But surely you can see that it's easier
to build validation paths from the ee cert to a trust anchor than it is
to do it the opposite way.  If you don't want to use AIA then you need a
directory where you can find the intermediate CA certs.  But for a
sufficiently large/complex PKI that might require keeping a large
databse in sync across many orgs, that is, not trivial.

The point is that using AIA is simpler than not.  In traditional PKIs,
and with your peer sending you their cert chain, (see below) there
should be no need to use AIA.

What can be done to improve the AIA situation is to constraint AIA URLs
such that, for example, they cannot specify arbitrary port numbers, and
to very few URL schemes (HTTP and LDAP should suffice).  Yes, this means
you could cause a relying party to attempt an HTTP GET from or LDAP
search on random servers.  As you say, the best option is to have the
peer send you a cert chain that you can validate from the root to the EE
cert (that way you're never following untrusted URLs).  But will your
peers be able to do that if you have a complex PKI?

> And I see a big difference in a user trying to manually and
> interatively construct a certification path and consciously deciding
> to include individual, not necessarily pre-trusted sources of
> information -- as long as it is not possible for an attacker to entice
> this construction to perform accesses to arbitrary resources without
> limits and entirely without critical consent and interaction of the
> entity doing the path construction.

I would like to agree about interaction, but... what's the user to do
with a prompt about whether to follow a given AIA URL??  They're only
going to answer "yes".

One option might be to implement SCVP (RFC5055) -- SCVP servers can
cache path consturction results effectively enough to minimize the
impact of AIA attacks.

> user/operator confirmation!

The whole point is to establish trust by establishing a path to a
trust anchor.  Eventually you'll know if the EE cert and the
intermediate CA certs are valid, or that the EE cert is not valid, or
that no valid path can be constructed, or that some intermediate CA
cert is invalid (if you're constructing a path then you'll stop when you
find an invalid intermediate CA cert and run out of path construction
options).

> at most the self-signed root certificate at the end of that chain.

If you have a non-traditional PKI then the path sent by the peer may
only be partially helpful.  (Though in that case you probably won't be
using AIA but instead searching a directory or configuration.)

> algorithm as-is without such information.

Yes.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Aug 2010 04:17:57 +0200 (MEST)

> > algorithm as-is without such information.

And if you have a fancy bridged CA, you will likely have the requirement
to add and maintain your own RootCA cert(s) into the trust anchor stores of
an of-the-shelf software/browser anyway, so you should be able to
use the exact same mechanism to push all necessary bridgeCAs
to your clients entirely obviating the need for AIA-cert-downloads.

Well, except maybe if you're just deploying Microsoft Windows 7 and
realize that your existing schemes for client certificate enrollment
and distribution of RootCA certs that worked on previous versions
of Windows fail in unexpected ways...(*)  But that is a regular software
maintenance issue otherwise irrelevant for the issue at hand.

-Martin

(*) like the bug described for the AllowUntrustedRoot value for the
    Restrictions parameter, which was defective in Vista rtm, fixed in SP1
    and seems to have regressioned back into 7rtm:

http://msdn.microsoft.com/en-us/library/aa378051%28VS.85%29.aspx

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Aug 2010 01:02:54 -0500

> to your clients entirely obviating the need for AIA-cert-downloads.

Does a TLS extension exist now by which clients and servers can provide
each other those hints?  What if there are multiple paths to a trust
anchor and the best path is not the one your peer hinted?

I'm not sure that AIA can be avoided entirely.  I'd like to hear more
about that.  But what I can tell that prompting the user about whether
to follow a cert's AIA is not practical nor useful (except in a debug
tool).  Also, if AIA can't be avoided then note that if AIA URLs are
sufficiently constrained then the harm they can cause can be limited,
and that when SCVP is used such harm can be further limited.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 05 Aug 2010 21:53:25 +1200

Martin Rex <[email-masked]> writes:

>Now if the browser performs AIA retrieval for unverified server certs, then
>this scenario is suddenly completely unprotected against active attacks where
>the attacker serves a manufactured server certificate with crafted AIA (but
>matching the server identity of the online banking account in the CN= or
>dNSName SAN.

Even more entertaining is sending in a client cert chain with a sequence of 
AIAs pointing to portions of common RFC 1918 address spaces.  You then time 
the server response time based on whether it gets an immediate ECONNREFUSED or 
similar, or has to time out.  First you check for the presence of a server at 
a given address using some common port like 445 and then you fingerprint it to 
see what's running, e.g. SQL server.  Hey presto, remote internal-network 
scanning via certificates.

(Just for the record, I had permission from the server admin to do this, at
least the second time I tried it :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 05 Aug 2010 22:50:12 +1200

Martin Rex <[email-masked]> writes:

>An implementation compliant to any of the TLS v1.x specifications would have
>to abort the handshake with such a server due to an clear protocol violation.

... lest God smite them, because we all know how seriously God takes RFC
compliance.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 05 Aug 2010 23:01:31 +1200

Martin Rex <[email-masked]> writes:

>I don't know who invented the concept of automatic AIA retrieval, but my
>personal intuition points to the S/Mime camp.  S/Mime is notoriously broken
>as far as the inclusion of certificates is concerned (being a heritage from
>PKCS#7).

I doubt very much it was S/MIME, S/MIME includes every cert needed along with
the message, to the point of specifying what's included as a SET OF rather
than a cert chain and explicitly allowing the inclusion of additional certs
that the sender may think are useful.  Just because they're not on the CC list
doesn't mean you can blame something like this on them...

>S/Mime and CMS are foobar.
>
>[...]
>
>AIA is a pretty dangerous idea designed to work around design flaws of an
>installed base of PKCS#7/CMS/SMime.

Did S/MIME spill its beer on you in a bar or something? :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 05 Aug 2010 23:11:17 +1200

>status information about multiple certificates for the same issuer.

This was being used by Identrus(t) a decade ago.

(I'm not aware of anything else that uses it and from what I heard back then
support for it in implementations was basically nonexistent).

>of OCSP signing authority" (RFC 2560 section 4.2.2.2 option 1) context.

Identrus did this with their transaction coordinators (OCSP gateways), with a
single responder signing for all responders that it crawled to build a
response.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 5 Aug 2010 08:39:33 -0400

You have yet to propose an alternative.  Absent an alternative, I'd support a security note to the effect that path construction modules should be careful to treat retrieved data as potentially unsafe until validated.

-- Tim

>Sent: Wednesday, August 04, 2010 8:03 PM
>To: Nicolas Williams
>Cc: [email-masked]; [email-masked]; [email-masked]; Miller, Timothy J.;
>[email-masked]
>Subject: Re: [TLS] [pkix] New version of Multiple OCSP mode of
>Certificate
>
>Nicolas Williams wrote:
>>

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Aug 2010 15:54:31 +0200 (MEST)

Miller, Timothy J. wrote:
> 
> You have yet to propose an alternative.  Absent an alternative,
> I'd support a security note to the effect that path construction
> modules should be careful to treat retrieved data as potentially
> unsafe until validated.

The TLS architecture requires a server to send the client a complete
certificate chain, omitting at most the self-signed root certificate,
and it permits clients to perform certificate path validation only
on the server-supplied chain.

There currently is a proposal for having the server provide 
OCSP responses for not just his own end entity cert, but also
for all intermediate CA certs so that the client does not
have to go chasing down certificate revocation information.

If you look at the certificate path validation algorithm as it
is described in rfc-5280, it is _NOT_ allowed to parallelize
the OCSP requests for a certificate chain during path validation
(in case you're using the AIA-information to locate the OCSP responder),
but instead, for security, you need to validate the certificate
individually and sequentially from the trust anchor down to the
end entity cert to determine wether a certificate is trusted,
before you use any information from such a peer-supplied cert
to perform public key crypto operations or access network resources
described in the unverified cert (AIA-OCSP or CRL-DPs).

n.    attributes check
      signature verification
      revocation check
n+1.  attributes check
      signature verification
      revocation check
n+2 ...

So in order to make the facility to have the server provide all
OCSP responses necessary for the revocation checking in the client's
certificate path validation work efficiently and reliably, the client
should hint the server about its trust anchors whenever the server
has multiple certificate chains to choose from for the server
Certificate handshake message.

There is also no problem when the network resouces that the
entity performing the certificate path validation queries,
are preconfigured or pre-trusted, instead of being arbitrary
creations of a potential attacker.  And a RootCA that contemplates
bridging with other PKIs should definitely set up a repository
for bridge CA certificate and could list that in its own trust
anchor certificate.  That would allow certificate and trust anchor
managment in a pull / update-on-demand style.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 06 Aug 2010 02:40:36 +1200

Nicolas Williams <[email-masked]> writes:

>What can be done to improve the AIA situation is to constraint AIA URLs such
>that, for example, they cannot specify arbitrary port numbers, and to very
>few URL schemes (HTTP and LDAP should suffice).

The problem with this is that you now get into the URL-obfuscation arms race
that the malware industry has been playing with browser developers for the
last ten years or so.  Would you trust a random PKI implementation (written by
crypto developers not web developers and that's never had to deal with this
kind of attack) to get this right?  After the third attempt?  After the tenth
attempt?

Peter.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Aug 2010 11:47:18 -0500

> kind of attack) to get this right?  After the third attempt?  After the tenth

The constraint can be such that only a hostname can be provided.  For
HTTP a well-known URL local part would then be used (see host-meta for
well-known stuff).  For LDAP we might say that you have to do a
particular search against only the base DNs corresponding to the
namingContexts listed in the root DSE.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 06 Aug 2010 06:28:25 +1200

Nicolas Williams <[email-masked]> writes:

>The constraint can be such that only a hostname can be provided.

And how do you specify appropriate restrictions to make something "only a
hostname"?  Look at the endless battle in browsers with various ways of
representing IP addresses that don't look anything like IP addresses.  Also,
what if the hostname is something inside your network?  In addition if I can
spoof DNS responses (pretty easy because I can get you to query hostnames like
<randomgibberish>.com which your corporate-internal resolver won't have cached
so it has to go to an external server) I can make the hostname reside at any
address I want, including RFC 1918 ones.

Peter.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Aug 2010 13:32:28 -0500

On Fri, Aug 06, 2010 at 06:28:25AM +1200, Peter Gutmann wrote:
> hostname"?

The domain part of the URL must be a DNS domainname to be resolved by
the resolver to an IP (v4, v6) address.  No port number must be
specified -- if HTTP then the port must be 80, if LDAP it must be 389.

The local part will be computed from conventions.  For HTTP that means
using a well-known local part.  For LDAP it means doing a standard
search off the base DNs for the namingContexts supported by the server.

This rules out IP addresses.

Nico
--

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 05 Aug 2010 19:51:00 +0100

> of OCSP signing authority" (RFC 2560 section 4.2.2.2 option 1) context.

I can recall this being mentioned before and the possibility was mentioned that
it might be permitted if you had the same public key in multiple delegated
signer certificates for each issuer.

I'm not sure how many OCSP clients would correctly handle that case, the current
OpenSSL OCSP code can't for one.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Aug 2010 22:38:01 +0200 (MEST)

> modules should be careful to treat retrieved data as potentially

Let's see.  The pain point is the access of a network
resource based on information under full control of a
potential attacker.  We definitely need to get rid of that entirely.

The environment where this happens is complex PKIs with
cross-certificate / bridgeCAs.

I think it would be just fair to burden that CA from one's own
original certificate chain which engages in cross-certification
activities with the burden to provide any missing cross-certs
to *ALL* other trusted PKIs accessible through cross-certification.

When going up your own certificate chain, there is also a much
higher likelyhood for the existence of contractual liabilities
and a much higher likelyhood of accessibility to online resources
from that CA.

Patching up a rough list of requirements:

1. Require the CA in your own original certification path 
   which engages in cross-certification to offer/distribute
   *ALL* cross-certs to other PKIs.

2. Define a download service to be offered by that CA where
   a client can send a list of Issue DNames and/or AuthorityKeyIdentifiers
   from all issuers of an incomplete cert chain that may be completable
   through cross-certs into the callers original chain for the retrieval
   of the missing cross-cert(s) (optionally plus
   intermediate certs from the callers own chain).

3. Define an AIA-style declaration for accessing that service in
   in at least one of the certs between the cross-certification
   engaging CA and the end entity cert that wants to perform
   a secure kind of certification path discovery.
   Multiple alternative URIs is OK.  But the important part is
   being able to send a list of issuer DNames and/or authorityKeyIdentifers
   to which the missing cross-cert(s) are needed for a certificate
   path validation.  Providing an option to request OCSP responses
   for the cross-certificates along with the missing certs might
   be sensible.

4. Support a similar out-of-band configuration for the location of
   that cross-cert provisioning service.

If you only ever have to query pre-known locations for missing
cross-certs, then this is *MUCH* easier to configure (including
firewall traversals / filtering rules), more reliable, easier
to check and maintain, better accessible (performance-wise),
its much easier to define acceptable timeouts, and you know
whom to call if it doesn't work.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 5 Aug 2010 15:17:43 -0500

On Thu, Aug 05, 2010 at 08:39:33AM -0400, Miller, Timothy J. wrote:
> You have yet to propose an alternative.  Absent an alternative, I'd
> support a security note to the effect that path construction modules
> should be careful to treat retrieved data as potentially unsafe until
> validated.

You were responding to Martin, but I'll take a crack at this too, based
on Martin's idea for using "hints":

 - Define hints that peers can tell each other about what PKI / what
   part of a PKI they "live in";

    - this could take the form of a name, domainname, whatever (requires
      naming conventions)
    - or it could take the form of a list of trust anchor names (can be
      quite large, so not ideal)

   I prefer using names to listing TAs.  To prevent namespace collisions
   I'd use domainames to name PKIs.

 - Given a peer's hints send a full cert chain that they should be able
   to verify;

 - Then the peer will validate the cert chain you send them from the
   trust anchor to your EE cert.

This takes the onus of path construction from the rp's shoulders (where
it is dangerous to the rp) and puts it on the rp's peer (where it
belongs).  Validation path construction is not elided completely, just
moved to where it belongs.

Alternatively, and even concurrently, I'd like to constraint AIA as I've
described before and which I'll repeat here:

 - AIA URLs should be limited to HTTP an LDAP schemes only;
 - The server name must be a domainname, to be resolved to an IP
   address;
 - The local part of AIA HTTP URLs should be left empty because it will
   be well-known (see host-meta);
 - The local part of AIA LDAP URLs should be left empty because there
   will be a simple convention for searching the DIT (try a well-defined
   scope sub search from each naming context provided by the server);

This is still not entirely safe because an rp's peer can still cause you
to try to retrieve a CA cert from any hostname they want.

Alternatively, and even concurrently:

 - Replace AIA with a URL construction convention based on the
   certificate's issuer's Name.

This last is still not entirely safe if you're constructing a path from
a peer's EE cert to any of your TAs because the peer's EE cert's issuer
can be anything they want it to be.

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 07 Aug 2010 01:56:11 +1200

Nicolas Williams <[email-masked]> writes:

>The domain part of the URL must be a DNS domainname to be resolved by the
>resolver to an IP (v4, v6) address.

What if it's an embedded device on a network with no DNS?

>No port number must be specified -- if HTTP then the port must be 80, if LDAP
>it must be 389.

What if they're running their OCSP on something other than port 80 because
port 80 is already in use for a web server?

(Not trying to have a perpetual-motion-machine debate here, just trying to
point out that there probably isn't any universally applicable way to restrict
this, so the ultimate choice may well be AIA or no AIA (and CRLDP and various
equivalents)).

Peter.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 6 Aug 2010 09:51:34 -0500

> What if it's an embedded device on a network with no DNS?

Why would you use PKI in such a case, and why AIA??

Let's be reasonable...  :)

Nico
--

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 07 Aug 2010 16:42:40 +1200

Nicolas Williams <[email-masked]> writes:

>Why would you use PKI in such a case

Well just off the top of my head there's tens of millions of DOCSIC certs
(although they're based on MAC addresses not IP addresses, they don't quite go
all the way up to IP), RPKI certs (although they're more likely to use AS
numbers rather than IP addresses), for pure IP there's masses of SCADA stuff
conforming to ISO 62351, DNP 3.0, IEC 61850, and probably a futher list as
long as your arm.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 9 Aug 2010 09:03:29 -0400

>Let's be reasonable...  :)

Off the top of my head:

1) Regulatory requirements.

2) Because a symmetric key distribution infrastructure might be too hard in the specific environment.

3) Because commercial platforms usually don't grok keys without certs.

-- Tim

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 14 Aug 2010 23:31:34 -0700

On Wed, 2010-08-04 at 23:10 +0200, Yngve N. Pettersen (Developer Opera
> network-category attacks, including that one.

Mozilla is also working on preventing attacks on internal networks:

https://bugzilla.mozilla.org/show_bug.cgi?id=354493

But internal networks are not necessarily the only networks to which the
victim may have access that the attacker doesn't.

-- 
Matt