Re: Intermediate certificate disclosure deadline in 2 weeks

[Rick Andrews]

On Friday, July 8, 2016 at 4:21:27 PM UTC-7, Rick Andrews wrote:
> GSA which governs FPKI recently approved Symantec’s proposal for one-way 
> cross-certification with the FBCA and to remove the cross-certificate from 
> the Symantec CA to the FBCA. The cross certificate is expiring on June 31, 
> 2016 and Symantec does not intend to renew the certificate going forward.

Correction - it's expiring on July 31, 2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediate certificate disclosure deadline in 2 weeks

[Rick Andrews]

GSA which governs FPKI recently approved Symantec’s proposal for one-way 
cross-certification with the FBCA and to remove the cross-certificate from the 
Symantec CA to the FBCA. The cross certificate is expiring on June 31, 2016 and 
Symantec does not intend to renew the certificate going forward.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

[Nick Lamb]

On Friday, 8 July 2016 07:04:49 UTC+1, Peter Gutmann  wrote:
> Various SCEP drafts have contained all sorts of stuff that was dropped when
> no-one cared about it.  The "out of band"/"beyond the scope of this document"
> is standard boilerplate that's used when no-one cares enough to include it in
> the document.  In fact it pretty much explicitly says that it's not covered in
> the doc because no-one cared how it was done.

But alas, even if you didn't care, it does matter.

Which is why there's VU#971035

SCEP (and all the real SCEP implementations that I could find) take the 
optimistic view that this is somebody else's problem, and so the practical 
result is security theatre. Certificates are issued, public key mathematics is 
done, there is superficial appearance of a secure system but no useful 
assurance of identity is achieved and so no real threat is neutralised.

> What does that have to do with no-one bothering to add whatever magic
> ingredient ACME is claiming to have to any other protocol that does the same
> thing?

This idea that you should just be able to "add whatever magic ingredient" is 
the exact sort of naivety that Bruce is talking about.

> OK, I think I can parse that convoluted sentence... in response: Each week who
> knows how many certificates are issued using HTTP POST, Xenroll.dll, SCEP,
> CMP, and who knows what else.  What's your point?

This is still mozilla.dev.security.policy. ACME automatically issues 
certificates that are trustworthy in the web PKI. That's the point of the 
protocol and the point of my statistic.

Counting up certificates that aren't ever going to be trusted by Mozilla's 
software may make you feel better about the time you invested, but it's not 
relevant to this group.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: About the ACME Protocol

[Patrick Figel]

Before getting into specifics, I should say that you're likely to get a
better answer to most of these question on the IETF ACME WG mailing list[1].

On 08/07/16 16:36, Peter Kurrasch wrote:
> I see on the gitub site for the draft that updates are frequently
> and continuously being made to the protocol spec (at least one a
> week, it appears). Is there any formalized process to review the
> updates? Is there any expectation for when a "stable" version might
> be achieved (by which I mean that further updates are unlikely)?‎

The IETF has a working group for ACME that's developing this protocol.
The IETF process is hard to describe in a couple of words (you can read
up on it on ietf.org if you're interested). Other related protocols such
as TLS are developed in a similar fashion.

> How are compatibility issues being addressed?

Boulder (the only ACME server implementation right now, AFAIK) plans to
tackle this by providing new endpoints (i.e. server URLs) whenever
backwards-incompatible changes are introduced in a new ACME draft, while
keeping the old endpoints available and backwards-compatible until the
client ecosystem catches up. I imagine once ACME becomes an internet
standard, future changes will be kept backwards-compatible (i.e.
"extensions" of some sort), but that's just me guessing.

> Has any consideration been given to possible saboteurs who might like
> to introduce backdoors?

The IETF process is public, which makes this harder (though not
impossible) to pull off. A number of people have reviewed and audited
the protocol (including a formal model[2]).

> I personally don't see the wisdom in having the server
> implementation details‎ in what is ostensibly a protocol
> specification.

Which part of the specification mentions implementation details?

> Will there be any sort of audit to establish compliance between a 
> particular sever implementation and this Internet-Draft?

Someone could definitely build tools to check compliance, but who would
enforce this, and what happens to a server/client that's not compliant?

> Will the client software be able to determine the version of the 
> specification under which the server is operating? (I apologize if it
> is in the spec; I didn't do a detailed reading of it.) On the client
> side, is there a document describing the details of an ideal 
> implementation? Does the client inform the server to which version of
> the protocol it is adhering--for example, in a user-agent string 
> (again, I didn't notice one). Is there any test to validate the 
> compliance of a client with a particular version of the 
> Internet-Draft?

See the previous paragraph on compatibility: Server URLs can be
considered backwards-compatible; there's currently no protocol version
negotiation or something like that.

> One thought for consideration is the idea of a saboteur who seeks to 
> compromise the client software.‎ This is of particular concern if the
> client software can also generate the key pair since there are the
> obvious benefits to bad actors if certain sites are using a weaker
> key. Just as Firefox is a target for malware, the developers of
> client-side software should be cognizant of bad actors who might seek
> to compromise their software.

That's certainly something to keep in mind, but not something that can
be solved by the protocol. It's also not specific to ACME clients, the
same concern applies to any software that touches keys in the course of
normal operation. FWIW, functional ACME client implementations can be
written in < 200 LOC, which would be relatively easy to review, and a
client would not necessarily need access to the private key of your
certificate - a CSR would be sufficient.

[1]: https://www.ietf.org/mailman/listinfo/acme
[2]: https://mailarchive.ietf.org/arch/msg/acme/9HX2i0oGyIPuE-nZYAkTTYXhqnk
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: StartEncrypt considered harmful today

[Peter Gutmann]

Patrick Figel  writes:

>On 08/07/16 08:04, Peter Gutmann wrote:
>> Or is it that ACME is just a desperate attempt to derail StartCom's
>> StartEncrypt at any cost?
>
>That doesn't make any sense - ACME has been in production for close to a
>year, while StartAPI was launched this April (and StartEncrypt just a couple
>of weeks ago).

Fair enough.  Just trying to figure out why someone would invent an entire new
protocol rather than tweak any one of the existing ones.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartEncrypt considered harmful today

[Patrick Figel]

On 08/07/16 08:04, Peter Gutmann wrote:
> Or is it that ACME is just a desperate attempt to derail StartCom's
> StartEncrypt at any cost?

That doesn't make any sense - ACME has been in production for close to a
year, while StartAPI was launched this April (and StartEncrypt just a
couple of weeks ago).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: StartEncrypt considered harmful today

[Peter Gutmann]

Nick Lamb  writes:

>Early drafts of SCEP, before it confined itself to "closed networks" even
>spell out what the problem is before they basically say they're not going to
>make any real attempt to tackle it. CMP, CMC and SCEP all resort to saying
>that some "out of band" mechanism should be used to verify that the applicant
>is or controls the subject DN and treat this problem as completely out of
>scope. 

Various SCEP drafts have contained all sorts of stuff that was dropped when
no-one cared about it.  The "out of band"/"beyond the scope of this document"
is standard boilerplate that's used when no-one cares enough to include it in
the document.  In fact it pretty much explicitly says that it's not covered in
the doc because no-one cared how it was done.

So I'll repeat this again: It wasn't added to any existing protocol because
no-one's ever cared about it before.  If people do care about it, why not add
it to any one of the many existing protocols rather than inventing yet another
incompatible way of doing what numerous other protocols already do?

Or is it that ACME is just a desperate attempt to derail StartCom's
StartEncrypt at any cost?

>"Schneier's Law" very much applies.

What does that have to do with no-one bothering to add whatever magic
ingredient ACME is claiming to have to any other protocol that does the same
thing?  Or are you claiming that ACME is flawed because it's a reinvention of
the wheel by amateurs (which is what Schneier's Law would be saying)?  That
seems a bit unlikely...

>Each week several hundred thousand certificates are issued using (an earlier
>draft of) ACME by what is now as a result one of the Web PKI's top five
>Certificate Authorities in terms of how many sites use its certificates.

OK, I think I can parse that convoluted sentence... in response: Each week who
knows how many certificates are issued using HTTP POST, Xenroll.dll, SCEP,
CMP, and who knows what else.  What's your point?

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy