Subject: [therightkey] Proposal for working on PKIX revocation open issues

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Fri, 14 Nov 2014 15:42:31 -1000

Dear PKIX Enthusiasts,

Although great work has been done in the past... 20 years.. (?) on 
providing very good protocols in the PKIX work, I think that we all 
agree that we still have some unresolved issues. In particular, the 
revocation is still a hot topic (especially for online environments) 
could use improvement over the current status of things. In particular, 
by looking at current specifications, some work is needed to address 
concerns especially in non-web environments.

For example, current specifications about OCSP stapling do not address 
the case of client authentication (which is a widespread use case 
outside the web environment) or, again, defining some new transport 
protocols for delivering OCSP responses which might reduce operational 
costs for revocation service providers.

After proposing the idea to Stephen Farrell and Kathleen Moriarty, we 
would like to know if there might be interests in participating in 
updating the status of the current revocation mechanisms for PKIX. This 
said, the scope of the work I am proposing is very limited. Specifically:

(a) Defining new transport protocols for revocation information 
availability (e.g., OCSP over DNS or OCSP over LDAP)
(b) (Possibly) defining a more lightweight revocation mechanisms (e.g. 
Lightweight Revocation Tokens)
(c) (Possibly) helping other working groups to revise and update how 
revocation information are provided (e.g., the client authentication case)
(d) (Possibly) introducing privacy consideration when it comes to 
revocation checking

Because of these considerations, I am proposing to start a conversation 
- for now, Stephen and Kathleen suggested we use (or "abuse") the "The 
Right Key" mailing list to see if there might be enough interest in the 
work from implementers to address these issues. I know that we (OpenCA) 
are interested in implementing these features, and we would like that 
the work would be standardized.

At minimal, I would like (a) to happen. This could be achieved in 6 
months (and we might not even need to meet). (b) and (c) are also 
desirable in order to provide better support for non-browsers and small 
devices (AFAIK, some work might be relevant for DICE). (d) is something 
that we should, I think, all be mindful and at least some considerations 
should be provided. The scope of the work, however, will be limited to 
revocation.

Please, if you are interested and would like to start the discussion, 
post your opinion on [email-masked] - also, please, circulate this 
proposal to anybody who might be interested in collaborating on this issue.

Please also note that we did decide not to use the [email-masked] mailing 
list because we thought [email-masked] might provide a more active 
pool of implementors.

Looking forward to receive all your inputs and start working on the topics.

Cheers,
Max

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Nov 2014 01:47:42 +0000

Thanks Max,

> the work would be standardized.

Just to re-iterate: if some good approaches for revocation of X.509
certificates emerge from this discussion that appear likely to get
implemented usefully then Kathleen and I will be happy to try help
form a wg or whatever is needed to develop the work.

Cheers,
S.

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 14 Nov 2014 23:55:44 -0800

Hi Anders,

thanks for the reply. The scope of this proposal was restricted on purpose to see if we gather consensus on a specific area:  revocation, therefore I am limiting my reply to that area to allow the conversation to be focused. Maybe your proposal could be future work for some other pkix-related wg, but it is not in scope with this proposal.

For the HTTP comment, I respectfully disagree. There are many areas where applications use authentication and confidentiality but do not talk HTTP. However, even if they do, they are not browsers and requirements and their capabilities might be different. However, as I see it, this work will be orthogonal to the application protocol.

For the question about client authentication, the only thing that I see missing today is the possibility, for clients, to present their own revocation information (i.e. being able to staple OCSPD responses for the presented certificate) [RFC 6961 only defines client requests for certificate status]. This would provide the server side with the possibility to request/require the client to provide information about their certificate chains.

I think this might have the positive effects for client-side certificate authentication and, ultimately, deployment.

Cheers,
Max

> On Nov 14, 2014, at 8:31 PM, Anders Rundgren <[email-masked]> wrote:
> 
>> On 2014-11-15 02:42, Dr. Massimiliano Pala wrote:
>> Dear PKIX Enthusiasts,
> 
> Thanx :-)
> 
> Just for my curiosity, have the OpenCA team implemented EST?
> 
> If not, I think this highlights the core problem which is adoption of standards.
> Microsoft, Intel, et. al. spent *hundreds of millions of dollars* on standardization
> of TPMs only to find that the bulk of the mobile device market (their competitors...)
> had taken another, more agile path.
> 
> Since HTTP seems to the lowest common denominator for all networked
> devices, it looks like that you will run into serious adoption issues.
> 
> I must admit that I don't understand what problem you want to solve
> in the context of *client authentication*.  The client's ability
> to gather revocation information abouts its own keys?  That's hardly
> a problem worth solving.  It sounds like a W3C proposal that I once saw
> which was about introducing an API at the client-side for revoking your
> own certificate(s).
> 
> As you can see the remains of the PKIX WG still don't want to discuss
> requirements like imposed by "Derived Credentials" which actually is
> a core PKI application that eventually will be used by everybody.
> 
> Anders
> 
>> 
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 15 Nov 2014 00:42:05 -0800

Thanks Anders!

Do you have any contacts for people working at that project? We might want to reach out to them as possible implementors and maybe start a conversation with them about possible requirements ? And eventually let them know about the progresses we might accomplish in the area.

Cheers,
Max

P.S.: Since Stephen and Kathleen asked me to have the conversation on The Right Key mailing list ([email-masked]), please could you send the replies only there? We should not use both therightkey and the pkix MLs :-)

> On Nov 14, 2014, at 9:11 PM, Anders Rundgren <[email-masked]> wrote:
> 
> Since you want to do something in revocation I would like to
> describe an existing potentially global PKI-using system that
> maybe could be improved.
> 
> The EU e-passport system needs for crossborder-checking of biometrics
> a pretty elaborate PKI scheme which among many things require
> the parties to expose two public ports on the Internet; one for
> the actual communication using HTTPS[1] and another for publishing
> CRLs using HTTP.  This isn't rocket-science but it still requires
> multiple FW settings and proxies.  If OCSP responses could be
> stapled (TLS client cert auth is used), relying parties would only
> have to open a single inbound port.  Cross-border reliability would
> probably also be improved since the client (sender) wouldn't be able
> to submit any data unless its OCSP is running (the PKIs are unique
> per country).
> 
> TLS 1.3 and 2.0 are in the workings so the timing is right...
> 
> 
> Anders
> 
> 1] I might add that I believe HTTPS with client certificate auth
> is a very poor choice for cross-border communication when each party
> run their own PKI. Signed messages permit a multi-tier architecture
> and quarantining of not yet trusted messages, greatly simplifying
> operation.  BSI are experts on crypto, but n00bs on IT :-)
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Nov 2014 10:12:47 -0800

On Nov 14, 2014, at 5:42 PM, Dr. Massimiliano Pala <[email-masked]> wrote:
> (a) Defining new transport protocols for revocation information availability (e.g., OCSP over DNS or OCSP over LDAP)

If you mean "pre-recorded (sometimes called 'stapled') OCSP responses", yes, this is useful. Maybe even over HTTP!

> (b) (Possibly) defining a more lightweight revocation mechanisms (e.g. Lightweight Revocation Tokens)

Not interested.

> (c) (Possibly) helping other working groups to revise and update how revocation information are provided (e.g., the client authentication case)

Not interested.

> (d) (Possibly) introducing privacy consideration when it comes to revocation checking

Slightly interested.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Nov 2014 16:56:53 -0500

> For example, current specifications about OCSP stapling do not address the
> case of client authentication (which is a widespread use case outside the
> web environment) or, again, defining some new transport protocols for
> delivering OCSP responses which might reduce operational costs for
> revocation service providers.

> After proposing the idea to Stephen Farrell and Kathleen Moriarty, we would
> like to know if there might be interests in participating in updating the
> status of the current revocation mechanisms for PKIX. This said, the scope
> of the work I am proposing is very limited. Specifically:
>

There is already a mechanism for transporting certs over LDAP. I am
pretty sure the folk who do that sort of thing have done the OCSP in
LDAP thing already.

I don't see a future for LDAP as an Internet protocol though. LDAP
introduces a completely gratuitous name infrastructure (X.500) that
adds no value other than to the consultants who can spin a 3 week
consulting gig bikeshedding the DIT with the customer. Nobody has ever
explained an advantage to me of LDAP over HTTP and a well-known
service convention.

OCSP over DNS has the attraction that DNS transport is fast. But
remember that DNS transport is fast because it is absolutely minimal.
Putting more stuff into DNS risks making it slow.

The construction of PRIVATE-DNS attempts to square this circle by
providing a mechanism that allows other protocols to make use of the
DNS channel (if that makes sense) without incorporating them into the
DNS protocol.

> Lightweight Revocation Tokens)

The patents on these techniques begin to expire in May 2016. Come back
then. They have not been available on RAND basis let alone RANDZ.

I'm not too interested in them however. S/Key does provide a rapid
means of updating status. Torben Pederssen proposed it as the phone
tick modus, Micali and Kocher proposed schemes that add in Merkle tree
mechanisms. Fast ECC signatures make these moot.

> revocation information are provided (e.g., the client authentication case)

CRLs probably work just fine for servers validating private label client certs.

> (d) (Possibly) introducing privacy consideration when it comes to revocation

Well that is the reason to get away from using straight OCSP. It leaks
information. But stapled OCSP solves that problem.

> At minimal, I would like (a) to happen. This could be achieved in 6 months
> (and we might not even need to meet). (b) and (c) are also desirable in
> order to provide better support for non-browsers and small devices (AFAIK,
> some work might be relevant for DICE). (d) is something that we should, I
> think, all be mindful and at least some considerations should be provided.
> The scope of the work, however, will be limited to revocation.

I have a different set of proposals:

1) Stapled OCSP with MUST-STAPLE OID
2) Short lived Certificates
  2a) With the same key
  2b) With different keys
3) CRLs with HBS compression.

Right now we are in the middle of deployment of (1) and doing 2a is
not too hard. But 2b is a LOT better since rotating the keys every 24
hours makes all sorts of attacks a lot harder.

Making 2b work requires quite a bit of prep though. We would have to
completely automate the cert issue process. And we would have to make
it work with pinning etc..

3 is new but we can probably get to convergence on a spec faster than
2b because we haven't tried that problem 4 times already. Much less
room for bikeshedding.

I see 1/2a as stop gap measures and 2b + 3 as the long term approach.

Rather than talk about 'the' revocation problem, I think we should
identify 2 separate revocation problems

Coarse grain: Narrow the vulnerability window from 1-3 years to 48 hours.
Fine grain: Narrow the vulnerability window to 60 mins.

Short lived certs (2b) are the best solution to coarse grain
revocation but it is really hard to get them working well for a window
of less than 48 hours. We would have to define a trusted time protocol
for a start and establish a distribution infrastructure for it.

HBS(3) can be used for both coarse grain as well as 2b at current
certificate issue rates. But it is a compression technique and it only
reduces the size of the problem by several orders of magnitude. If
cert use grows by an order of magnitude we are back in trouble. That
said, combining HBS with short lived certs gives us a path to
achieving fine grain revocation. And that is critical in the longer
term. The criminals do most of their fraud in the first 24 hours after
putting a server live.

Short lived certs have the enormous advantage that the vast majority
of revocations are for administration reasons, at the request of the
cert subject. Revocations for end-entity breach are much rarer. But
the problem is that we don't have an accurate means of distinguishing
between the cases. Our customers don't want to tell us when they have
done something doofus like selling the hard drives with private keys
for a live cert.

Short lived certs have the nice property that many doofus behaviors
time out automatically even if the customer does not catch them. Since
it takes more than 24 hours to sell old hard drives on EBay, the keys
corresponding to short lived certs will have expired by the time the
drives ship.

So to sumarize, here is my roadmap

Now: OCSP Stapling with MUST STAPLE
12 months: CAs begin issuing HBS compressed CRLs in a form that
permits browsers to use them as a basis for constructing 'BigCRL' type
solutions
24 months: Begin issue of 2a short lived certs
36 months: Begin issue of 2b short lived certs

5 years: Begin deprecating long lived certs
10 years: Begin phase out of long lived certs
20 years: Stop issue of long lived certs

Short lived certs with new keys per cert are definitely the way to go
long term. But it will take a long time to eliminate long lived certs
- if that is possible at all. That is fine though, provided we can
make sure that the majority of the growth in certs is of short lived
certs, we will be fine.

I think that is going to happen naturally since short lived certs are
a much better fit for the cloud than long lived ones. If I use a
server for 3 hours, I don't want to rely on the hosting provider
scrubbing the memory before the next customer gets hold of it to
protect my private keys. I want to limit the scope for service
provider defection as well.

The barrier to deployment on 2b is writing a good spec for
provisioning certs. I have a rough sketch of a JSON prototype that
basically just wraps a CSR.

---

From: Trevor Freeman <[email-masked]>
Date: Sun, 16 Nov 2014 10:53:01 -0800

Hi Max,

I think we first need a consensus of the unmitigated threats this work would
look to address. That would help assess the technical options. Top of my
list of unmitigated threats would be compromised CA issuing  user
certificates outside of the normal process e.g. attackers use some tool to
sign the certificate direly using the CA key so no log exists of the
issuance.   

For example, if there is consensus on that as a threat to be addressed, OCSP
does not help much in that you want a "known to be good" assertion, not a
"know to be bad" assertion that revocation checking provides. Certificate
reissuance has been long been cited as an alternative to revocation in that
you get a restatement of the goodness which is what you need, but it does
tax the CAs. If you are targeting server validation scenarios, then a Valid
Certificate List which was similar to CRLs but a list of good certificates
could scale much better as Phil points out. Given we know all too well what
does not work well with CRLs, we should be able to avoid the mistakes i.e.
use hashs to identify certificates not issue\serial number, mandate support
for partitions etc., etc.

So what unmitigated threats do you have in mind?

Trevor

-----Original Message-----
From: therightkey [mailto:[email-masked]] On Behalf Of Phillip
Hallam-Baker
Sent: Saturday, November 15, 2014 1:57 PM
To: [email-masked]
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation
open issues

> updating the status of the current revocation mechanisms for PKIX. 
> This said, the scope of the work I am proposing is very limited.
> availability (e.g., OCSP over DNS or OCSP over LDAP)

There is already a mechanism for transporting certs over LDAP. I am pretty
sure the folk who do that sort of thing have done the OCSP in LDAP thing
already.

I don't see a future for LDAP as an Internet protocol though. LDAP
introduces a completely gratuitous name infrastructure (X.500) that adds no
value other than to the consultants who can spin a 3 week consulting gig
bikeshedding the DIT with the customer. Nobody has ever explained an
advantage to me of LDAP over HTTP and a well-known service convention.

OCSP over DNS has the attraction that DNS transport is fast. But remember
that DNS transport is fast because it is absolutely minimal.
Putting more stuff into DNS risks making it slow.

The construction of PRIVATE-DNS attempts to square this circle by providing
a mechanism that allows other protocols to make use of the DNS channel (if
that makes sense) without incorporating them into the DNS protocol.

> Lightweight Revocation Tokens)

The patents on these techniques begin to expire in May 2016. Come back then.
They have not been available on RAND basis let alone RANDZ.

I'm not too interested in them however. S/Key does provide a rapid means of
updating status. Torben Pederssen proposed it as the phone tick modus,
Micali and Kocher proposed schemes that add in Merkle tree mechanisms. Fast
ECC signatures make these moot.

> revocation information are provided (e.g., the client authentication 

CRLs probably work just fine for servers validating private label client
certs.

> desirable in order to provide better support for non-browsers and 
> small devices (AFAIK, some work might be relevant for DICE). (d) is 
> something that we should, I think, all be mindful and at least some
considerations should be provided.

Right now we are in the middle of deployment of (1) and doing 2a is not too
hard. But 2b is a LOT better since rotating the keys every 24 hours makes
all sorts of attacks a lot harder.

Making 2b work requires quite a bit of prep though. We would have to
completely automate the cert issue process. And we would have to make it
work with pinning etc..

3 is new but we can probably get to convergence on a spec faster than 2b
because we haven't tried that problem 4 times already. Much less room for
bikeshedding.

Rather than talk about 'the' revocation problem, I think we should identify
2 separate revocation problems

Short lived certs (2b) are the best solution to coarse grain revocation but
it is really hard to get them working well for a window of less than 48
hours. We would have to define a trusted time protocol for a start and
establish a distribution infrastructure for it.

HBS(3) can be used for both coarse grain as well as 2b at current
certificate issue rates. But it is a compression technique and it only
reduces the size of the problem by several orders of magnitude. If cert use
grows by an order of magnitude we are back in trouble. That said, combining
HBS with short lived certs gives us a path to achieving fine grain
revocation. And that is critical in the longer term. The criminals do most
of their fraud in the first 24 hours after putting a server live.

Short lived certs have the enormous advantage that the vast majority of
revocations are for administration reasons, at the request of the cert
subject. Revocations for end-entity breach are much rarer. But the problem
is that we don't have an accurate means of distinguishing between the cases.
Our customers don't want to tell us when they have done something doofus
like selling the hard drives with private keys for a live cert.

Short lived certs have the nice property that many doofus behaviors time out
automatically even if the customer does not catch them. Since it takes more
than 24 hours to sell old hard drives on EBay, the keys corresponding to
short lived certs will have expired by the time the drives ship.

Now: OCSP Stapling with MUST STAPLE
12 months: CAs begin issuing HBS compressed CRLs in a form that permits
browsers to use them as a basis for constructing 'BigCRL' type solutions
24 months: Begin issue of 2a short lived certs
36 months: Begin issue of 2b short lived certs

Short lived certs with new keys per cert are definitely the way to go long
term. But it will take a long time to eliminate long lived certs
- if that is possible at all. That is fine though, provided we can make sure
that the majority of the growth in certs is of short lived certs, we will be
fine.

I think that is going to happen naturally since short lived certs are a much
better fit for the cloud than long lived ones. If I use a server for 3
hours, I don't want to rely on the hosting provider scrubbing the memory
before the next customer gets hold of it to protect my private keys. I want
to limit the scope for service provider defection as well.

The barrier to deployment on 2b is writing a good spec for provisioning
certs. I have a rough sketch of a JSON prototype that basically just wraps a
CSR.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Nov 2014 15:29:58 -0500

> sign the certificate direly using the CA key so no log exists of the

Seriously?

How often does this happen?

How often does an administrator sell a machine without zeroing the
hard drive where a live key is stored? How often does a corrupt admin
sell a private key? How often does a machine without a TPM with a cert
get rooted?

End entity breach is a daily occurrence.

> for partitions etc., etc.

I much prefer using hash based mechanisms to issuer/serial. But in a
pinch, I will use hash of the issuer/serial :)

---

From: Ben Laurie <[email-masked]>
Date: Mon, 17 Nov 2014 15:52:48 +0000

> (d) (Possibly) introducing privacy consideration when it comes to

FWIW, we (Google) are interested in doing the same thing for revocation
that CT does for certs - i.e. providing a verifiable log/map of revocation
status.

Not sure if that fits into your remit above (on the face of it, it does
not).

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Nov 2014 10:31:06 -0600

> (e.g., OCSP over DNS or OCSP over LDAP)

OCSP lacks for various bindings to various transports.  I think
defining more such bindings would be nice.

> Lightweight Revocation Tokens)

What would that look like?  I think stapled DANE is about as
light-weight as it's going to get.

> revocation information are provided (e.g., the client authentication case)

They can do this themselves.  Assuming TLS 1.3 retains user
authentication with certificates, let the TLS WG add stapled OCSP.

> (d) (Possibly) introducing privacy consideration when it comes to revocation

If you staple OCSP then the main privacy considerations are:

a) how the end entities' certs and OCSP responses are transported
(e.g., we'd need TLS to have a mode that provides confidentiality to
the client cert, which IIUC is not in the cards for 1.3),

b) how to provide privacy protection for DNS (the elephant in the room).

Anything to be done in TLS belongs squarely in the TLS WG.  I'd love
to see DNS confidentiality, but I think we should get our priorities
straight: opportunistic security, TLS 1.3, CT, DNSSEC/DANE deployment,
...  I confess that my list of priorities is something one could argue
about, and that if we have the energy to do more of these things
concurrently, then we should.

Nico
--

---

From: Jeremy.Rowley <[email-masked]>
Date: Mon, 17 Nov 2014 10:02:44 -0700

+1 to using a CT-like structure to also provide revocation information.

On 11/17/2014 8:52 AM, Ben Laurie wrote:
>
>
> On Sat Nov 15 2014 at 1:42:31 AM Dr. Massimiliano Pala 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear PKIX Enthusiasts,
>
>     This
> FWIW, we (Google) are interested in doing the same thing for 
> revocation that CT does for certs - i.e. providing a verifiable 
> log/map of revocation status.
>
> Not sure if that fits into your remit above (on the face of it, it 
> does not).
>
>
>     small
>     post your opinion on [email-masked]
>     <mailto:[email-masked]> - also, please, circulate this
>     Please also note that we did decide not to use the [email-masked]
>     <mailto:[email-masked]> mailing
>     list because we thought [email-masked]
>     <mailto:[email-masked]> might provide a more active
>     pool of implementors.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 17 Nov 2014 09:07:33 -0800

Obviously more that you think otherwise folks would not be working on CTJ

-----Original Message-----
From: therightkey [mailto:[email-masked]] On Behalf Of Phillip
Hallam-Baker
Sent: Sunday, November 16, 2014 12:30 PM
To: Trevor Freeman
Cc: Massimiliano Pala; [email-masked]
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation
open issues

> I think we first need a consensus of the unmitigated threats this work 

> would look to address. That would help assess the technical options. 

> Top of my list of unmitigated threats would be compromised CA issuing  

> user certificates outside of the normal process e.g. attackers use 

> some tool to sign the certificate direly using the CA key so no log 

> exists of the issuance.

Seriously?

How often does an administrator sell a machine without zeroing the hard
drive where a live key is stored? How often does a corrupt admin sell a
private key? How often does a machine without a TPM with a cert get rooted?

> For example, if there is consensus on that as a threat to be 

> addressed, OCSP does not help much in that you want a "known to be 

> good" assertion, not a "know to be bad" assertion that revocation 

> checking provides. Certificate reissuance has been long been cited as 

> an alternative to revocation in that you get a restatement of the 

> goodness which is what you need, but it does tax the CAs. If you are 

> targeting server validation scenarios, then a Valid Certificate List 

> which was similar to CRLs but a list of good certificates could scale 

> much better as Phil points out. Given we know all too well what does not
work well with CRLs, we should be able to avoid the mistakes i.e.

> use hashs to identify certificates not issue\serial number, mandate 

> support for partitions etc., etc.

I much prefer using hash based mechanisms to issuer/serial. But in a pinch,
I will use hash of the issuer/serial :)

therightkey mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/therightkey>
https://www.ietf.org/mailman/listinfo/therightkey

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Nov 2014 12:41:52 -0500

It is always a mistake to imagine that political outcomes are the
product of rational analysis rather than the respective power
relationships and constraints.

For Google, the risk of consequences due to CA breach are arguably
higher than the consequences of end-entity breach which they have
controlled through shifting liability onto the CAs. But for the
typical Internet user, the risk due to end-entity breach is higher.

I didn't say we shouldn't do CT, what I said is that we have to make
revocation an equal priority.

Checkpointing revocation information in CT makes great sense for all concerned.

Had Harber-Stornetta catenate certificates been available on equitable
terms prior to the expiry of the patent we would probably have done
something like CT years ago. The reason we didn't do revocation before
was that we did not develop a technology that the browser providers
considered acceptable. And then we spend ten years trying to persuade
them that up was down rather than fixing the problem.

Not trying to assign blame here, I should have arrived at this
analysis ten years ago.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Nov 2014 11:47:42 -0600

> I don't see a future for LDAP as an Internet protocol though. LDAP

Indeed, but it is an Internet protocol that is widely used in the enterprise.

> introduces a completely gratuitous name infrastructure (X.500) that

Eh?!  It's the same [busted, obnoxious, unworkable, <fill-in-curses>]
naming model as PKIX.  RFC4514 is a great demonstration of what a
disaster X.500 naming is, but don't be fooled by the "LDAP" in the
title: it's as good a demo of X.509's disastrous naming.

> explained an advantage to me of LDAP over HTTP and a well-known

LDAP is hardly my favorite protocol.  Its biggest sin is really not
its fault, but the implementors, who have by and large adopted the
LDAP representation of "objects" as their native representation of the
same, losing a lot of relational power in the process.  The other
problem is that LDAP's is a poor query language.

As for HTTP...  HTTP doesn't do what LDAP does.  One could define a
DAP over HTTP (an "API"), and that'd be a fine thing.

> CRLs probably work just fine for servers validating private label client certs.

Yes.

> 3) CRLs with HBS compression.

+1

Nico
--

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 17 Nov 2014 12:43:43 -0800

> DAP over HTTP (an "API"), and that'd be a fine thing.

Is anyone actually working on that? It's definitely something I'd be
interested in

-- 
Tony Arcieri

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Nov 2014 16:08:10 -0500

What do you want?

An API that interfaces to the X.500 names or the SubjectAltNames?
Can't see a lot of point in the first but the second makes a lot of
sense. In fact I think we must have several.

Incidentally, the reason I discount LDAP in the Internet is precisely
the fact it is now an enterprise resource. And enterprises are no more
willing to share that with the Internet than their conversations with
their lawyers.

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 17 Nov 2014 13:25:07 -0800

On Mon, Nov 17, 2014 at 1:08 PM, Phillip Hallam-Baker <[email-masked]

> What do you want?

An HTTP-powered alternative to LDAP. Preferably ASN.1-free.

-- 
Tony Arcieri

---

From: Rob Stradling <[email-masked]>
Date: Mon, 17 Nov 2014 21:51:57 +0000

On 17/11/14 17:47, Nico Williams wrote:
> On Sat, Nov 15, 2014 at 3:56 PM, Phillip Hallam-Baker wrote:
<snip>
>> 3) CRLs with HBS compression.

On 17/11/14 15:52, Ben Laurie wrote:
<snip>
> that CT does for certs - i.e. providing a verifiable log/map of
> revocation status.

I'm interested in making revocation checking for the WebPKI actually 
work when it needs to work!  And that means finding a way for browsers 
to be able to hard-fail when revocation status is unobtainable.

TBH, I'm growing weary of OCSP Stapling.  It's still going to be years 
before there's any chance of it being deployed ubiquitously.  And I've 
seen some resistance to having OCSP Stapling enabled by default on the 
server-side.
Must-Staple is selective hard-fail.  It doesn't stop a compromised CA 
from misissuing a cert without Must-Staple for www.domain.com. 
Ultimately, we need browsers to always hard-fail, at which point 
Must-Staple would become redundant.

Short-lived certs are awkward until servers can somehow automate the 
process of requesting and installing new certificates.  And it's a 
problem that browsers don't treat certificate expiration as harshly as 
they treat certificate revocation.

The direction the browsers have been heading in (first Chrome with 
CRLSets, and now Firefox with OneCRL) is for the browser provider to 
construct a curated "global CRL" and push this to users via the 
browser's regular update mechanism.  The biggest problem I've seen with 
these "global CRL" solutions is that they don't cover the majority of 
certs...
...which is why I'm excited about CRLs with HBS compression.  :-)

I'm also excited about Ben's Revocation Transparency proposal.  This 
would be perfect as a trusted source for generating _truly_ "global 
CRLs" with HBS compression.  :-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Nov 2014 18:17:06 -0600

On Mon, Nov 17, 2014 at 09:51:57PM +0000, Rob Stradling wrote:
> work when it needs to work!  And that means finding a way for
> browsers to be able to hard-fail when revocation status is
> unobtainable.
>
> [...]

What you say is true, but what we need here is a time machine.  One that
can travel backwards in time cheaply.  That one is stuck in AUTH48, I
hear, and we might not get it for a while yet.

Deadly embrace problems simply take time to fix.

DANE stands a pretty good chance of helping simplify a lot of things,
which is one reason that I'm a fan.  Right out of the gate DANE is way
ahead of PKIX w.r.t. naming constraints, and that's a huge part of the
battle -- nigh the most important, since the number of CAs that can
impersonate a service becomes: the number of labels in the TLSA RRset
domainname.

DANE can be stapled, and it's rather straightforward to do so too.  Yes,
there are issues, like the DNSSEC RSA 1024 root key, and the lack of
logging of delegations, but we know what they are and they are
tractable.

Nico
--