RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

Done: 

 

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

 

It ended up being about 1200 certs total that we are hearing can’t be replaced 
because of blackout periods.

 

From: Ryan Sleevi  
Sent: Wednesday, December 19, 2018 11:05 AM
To: Jeremy Rowley 
Cc: r...@sleevi.com; mozilla-dev-security-policy 

Subject: Re: Underscore characters

 

Look forward to seeing and discussing once the full scope of the request is 
shared.

 

On Wed, Dec 19, 2018 at 12:21 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

We will post the full list of exceptions today. 

 

One of the big factors should be the risk to the industry/community if the 
certificates aren’t revoked. Perhaps we can identify what the risk to the 
community is in revocation delays first? There’s no need to know the exact 
certs to talk about what the risk associated with underscore characters is. 
Could you please explain the risk to the community in a revocation delay as the 
“unreasonable” argument isn’t really supported without that understanding. 

 

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Wednesday, December 19, 2018 7:17 AM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: r...@sleevi.com  ; mozilla-dev-security-policy 
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Underscore characters

 

While I appreciate you sharing what you have, as I tried to capture in my 
previous message, I don't believe there can be any discussion or consideration 
in earnest without the full and final information. I don't think it's 
reasonable to drip in information piece meal, given the impact and affect that 
can have - whether incomplete information for the issue or whether additional 
customers being added.

 

You're making a huge request of the community, arguably one that borderlines 
unreasonable given the set of issues had in the past. I do want to help you 
achieve your goal of understanding what that would look like, but that's only 
possible with full and complete information. You mentioned it's roughly 15 
companies. If you had ten committed, but were waiting on the remaining five to 
give the OK, I think it would be irresponsible to hold up having that 
conversation until you get the OK. Quite simply, if you don't get the OK from 
those five companies, then we shouldn't even be discussing them. Ultimately, 
the ball is in your court as to how you want to address this with your 
customers, but I think that delaying the conversation in order to make sure 
"stragglers" are included is probably not the wisest for your customers that 
have their stuff together.

 

As such, I don't think the conversation can begin without that (hypothetical) 
incident report, and I look forward to you deciding what that scope will be in 
order to share and commit to it.

 

On Tue, Dec 18, 2018 at 9:51 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

Yeah – I’ll be providing an accurate incident report (working on gathering all 
the information). The incident report assumes we don’t revoke of course. 
Revocation is still on the table. However, I wanted to start the conversation 
with everything I know so far:

1) ~2200 certs 

2) Roughly 15 companies
3) Only one has publicly chimed in so far on the Mozilla thread (still hoping 
more will…)

4) Revocation of all certs will occur by May 1, 2019, depending on how the 
discussion here goes.   
5) The common thread is that the Jan 15th deadline falls in the blackout window 
of most orgs. They generally come off it between Jan 15-Feb 15. They can’t 
replace the cert or change the domain so the 30 day cert option doesn’t help.

6) We provided notice as soon as the ballot passed. We blocked issuance prior 
to that date, but we’d hoped that the certs could remain valid until 
expiration. We had trouble with our BI providing the information so some 
notices went out later than I’d hoped. I’ll find the exact date on when all 
notices were complete.

 

Ballot 202 failed. I’m not sure how it’s relevant other than to indicate there 
was definite disagreement about whether underscores were permitted or not. As 
previously mentioned, I didn’t consider underscore characters prohibited until 
the ballot was proposed eliminating them in Oct. I know the general Mozilla 
population disagrees but, right or wrong, that’s the root cause of it all. I 
can explain my reasoning again here, but I doubt it materially alters the 
conversation and outcome. 

 

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Tuesday, December 18, 2018 7:35 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Underscore characters

 

Jeremy,

 

It seems like any answer for what it "might" look like if a CA violated the BRs 
in a particular way is going to be predicated on what the incident report says. 
In the case of a hypothetical like this, it seems 

Re: Underscore characters

[Matt Palmer via dev-security-policy]

On Wed, Dec 19, 2018 at 05:20:59PM +, Jeremy Rowley via dev-security-policy 
wrote:
> One of the big factors should be the risk to the industry/community if the
> certificates aren’t revoked.  Perhaps we can identify what the risk to the
> community is in revocation delays first?  There’s no need to know the
> exact certs to talk about what the risk associated with underscore
> characters is.  Could you please explain the risk to the community in a
> revocation delay as the “unreasonable” argument isn’t really supported
> without that understanding.

I think an important risk to the community of not revoking as per the CA/B
Forum's accepted ballot timeline is sending the message that the rules of
the game are optional, and there is commercial benefit to be gained in not
following the rules.

I'm sure there are some CAs whose systems were always setup in a
standards-compliant fashion, and refused to issue certificates for invalid
names.  I'm equally sure that at least one of those CAs lost a sale over the
years as a result of that, and that sale went to a competitor which was
*not* adhering to the standards.

Now the issue has been raised, clarification made, and a decision has been
made as to how to move forward.  To provide further benefit (in the form of
a waiver from the agreed-upon rules) to CAs which have failed to follow the
rules in the past does not encourage adherence in the future.  Certainly, if
I were the CEO of a for-profit CA which *had* followed the no-underscores
rule, I might be inclined to gently encourage my developers to play a little
faster and looser with their interpretations in the future, if it would
provide my organisation with a revenue benefit, and it was clear that there
was to be no meaningful negative consequence *to me* as a result.  To do
otherwise would actually be contrary to the stated goals of the
organisation.

Please don't misunderstand my words to think that I'm saying that any CA
*deliberately* ignored the standards around underscores in order to sell
some more certs.  I'm well aware that the rules around valid hostnames,
domain names, DNS labels, etc are not the clearest, and most people wouldn't
read them even if they were.

It's undeniable, though, that CAs which allowed underscores in places that
are supposed to be valid LDH domain names made a mistake, and to
deliberately misquote Jurassic Park's John Hammond, "I don't blame people
for their mistakes, but I do expect them to take responsibility for them."
To not expect CAs to take responsibility for their mistakes sends a
*terrible* message to the entire ecosystem, one that would have far greater
long-term repurcussions than any isolated harm from the presence of
underscores themselves.

Whilst it's not quite the textbook definition, part of the Wikipedia page on
"Moral Hazard" says, "when a person takes more risks because someone else
bears the cost of those risks".  That's a pretty reasonable expression of
what's going on here.

- Matt

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

Re: Online exposed keys database

[Adam Shannon via dev-security-policy]

I threw together a quick Go library for using this API to see how it works
in a larger app.

https://github.com/adamdecaf/pwnedkeys

On Wed, Dec 19, 2018 at 3:34 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Dec 19, 2018 at 11:30:47AM +0100, Kurt Roeckx via
> dev-security-policy wrote:
> > I'm not sure how you feel about listing keys where you don't have the
> > private key for, but are known to be compromised anyway. One potential
> > source for such information might be CRLs where the reason for revocation
> > was keyCompromise.
>
> At *this* stage, I'm really only interested in providing proof of key
> exposure, via signatures.  Just listing keys and saying "trust me, these
> are
> compromised" just seems... weak, somehow.  Also, trawling revocation lists
> for keys requires matching up the issuer+serial number to a cert in another
> store (since CRLs only record serial numbers), which is just *annoying*.
>
> > If you don't want to publish the private keys, distributing the public
> keys
> > might be an option.
>
> For a "bulk" export, yes, that is a possibility.
>
> - Matt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

We will post the full list of exceptions today. 

 

One of the big factors should be the risk to the industry/community if the 
certificates aren’t revoked. Perhaps we can identify what the risk to the 
community is in revocation delays first? There’s no need to know the exact 
certs to talk about what the risk associated with underscore characters is. 
Could you please explain the risk to the community in a revocation delay as the 
“unreasonable” argument isn’t really supported without that understanding. 

 

From: Ryan Sleevi  
Sent: Wednesday, December 19, 2018 7:17 AM
To: Jeremy Rowley 
Cc: r...@sleevi.com; mozilla-dev-security-policy 

Subject: Re: Underscore characters

 

While I appreciate you sharing what you have, as I tried to capture in my 
previous message, I don't believe there can be any discussion or consideration 
in earnest without the full and final information. I don't think it's 
reasonable to drip in information piece meal, given the impact and affect that 
can have - whether incomplete information for the issue or whether additional 
customers being added.

 

You're making a huge request of the community, arguably one that borderlines 
unreasonable given the set of issues had in the past. I do want to help you 
achieve your goal of understanding what that would look like, but that's only 
possible with full and complete information. You mentioned it's roughly 15 
companies. If you had ten committed, but were waiting on the remaining five to 
give the OK, I think it would be irresponsible to hold up having that 
conversation until you get the OK. Quite simply, if you don't get the OK from 
those five companies, then we shouldn't even be discussing them. Ultimately, 
the ball is in your court as to how you want to address this with your 
customers, but I think that delaying the conversation in order to make sure 
"stragglers" are included is probably not the wisest for your customers that 
have their stuff together.

 

As such, I don't think the conversation can begin without that (hypothetical) 
incident report, and I look forward to you deciding what that scope will be in 
order to share and commit to it.

 

On Tue, Dec 18, 2018 at 9:51 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

Yeah – I’ll be providing an accurate incident report (working on gathering all 
the information). The incident report assumes we don’t revoke of course. 
Revocation is still on the table. However, I wanted to start the conversation 
with everything I know so far:

1) ~2200 certs 

2) Roughly 15 companies
3) Only one has publicly chimed in so far on the Mozilla thread (still hoping 
more will…)

4) Revocation of all certs will occur by May 1, 2019, depending on how the 
discussion here goes.   
5) The common thread is that the Jan 15th deadline falls in the blackout window 
of most orgs. They generally come off it between Jan 15-Feb 15. They can’t 
replace the cert or change the domain so the 30 day cert option doesn’t help.

6) We provided notice as soon as the ballot passed. We blocked issuance prior 
to that date, but we’d hoped that the certs could remain valid until 
expiration. We had trouble with our BI providing the information so some 
notices went out later than I’d hoped. I’ll find the exact date on when all 
notices were complete.

 

Ballot 202 failed. I’m not sure how it’s relevant other than to indicate there 
was definite disagreement about whether underscores were permitted or not. As 
previously mentioned, I didn’t consider underscore characters prohibited until 
the ballot was proposed eliminating them in Oct. I know the general Mozilla 
population disagrees but, right or wrong, that’s the root cause of it all. I 
can explain my reasoning again here, but I doubt it materially alters the 
conversation and outcome. 

 

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Tuesday, December 18, 2018 7:35 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Underscore characters

 

Jeremy,

 

It seems like any answer for what it "might" look like if a CA violated the BRs 
in a particular way is going to be predicated on what the incident report says. 
In the case of a hypothetical like this, it seems like the hypothetical 
incident report would discuss what is planned or proposed, and should a CA go 
forward with such an intentional violation, the 'actual' incident report would 
equally consider how accurate that was.

 

Recall that the approach to incident reporting is not punitive - it's to make 
sure that we're addressing systemic gaps and issues, that we've understood the 
issues, and have the available data to assess the impact, risk, and any 
patterns of issues. The incident reporting template is one way to provide that 
data in a structured way and to gather feedback.

 

I think a minimum next step is to move from the abstract discussion to the 
concrete: 

Re: Underscore characters

[Ryan Sleevi via dev-security-policy]

While I appreciate you sharing what you have, as I tried to capture in my
previous message, I don't believe there can be any discussion or
consideration in earnest without the full and final information. I don't
think it's reasonable to drip in information piece meal, given the impact
and affect that can have - whether incomplete information for the issue or
whether additional customers being added.

You're making a huge request of the community, arguably one that
borderlines unreasonable given the set of issues had in the past. I do want
to help you achieve your goal of understanding what that would look like,
but that's only possible with full and complete information. You mentioned
it's roughly 15 companies. If you had ten committed, but were waiting on
the remaining five to give the OK, I think it would be irresponsible to
hold up having that conversation until you get the OK. Quite simply, if you
don't get the OK from those five companies, then we shouldn't even be
discussing them. Ultimately, the ball is in your court as to how you want
to address this with your customers, but I think that delaying the
conversation in order to make sure "stragglers" are included is probably
not the wisest for your customers that have their stuff together.

As such, I don't think the conversation can begin without that
(hypothetical) incident report, and I look forward to you deciding what
that scope will be in order to share and commit to it.

On Tue, Dec 18, 2018 at 9:51 PM Jeremy Rowley 
wrote:

> Yeah – I’ll be providing an accurate incident report (working on gathering
> all the information). The incident report assumes we don’t revoke of
> course. Revocation is still on the table. However, I wanted to start the
> conversation with everything I know so far:
>
> 1) ~2200 certs
>
> 2) Roughly 15 companies
> 3) Only one has publicly chimed in so far on the Mozilla thread (still
> hoping more will…)
>
> 4) Revocation of all certs will occur by May 1, 2019, depending on how the
> discussion here goes.
> 5) The common thread is that the Jan 15th deadline falls in the blackout
> window of most orgs. They generally come off it between Jan 15-Feb 15. They
> can’t replace the cert or change the domain so the 30 day cert option
> doesn’t help.
>
> 6) We provided notice as soon as the ballot passed. We blocked issuance
> prior to that date, but we’d hoped that the certs could remain valid until
> expiration. We had trouble with our BI providing the information so some
> notices went out later than I’d hoped. I’ll find the exact date on when all
> notices were complete.
>
>
>
> Ballot 202 failed. I’m not sure how it’s relevant other than to indicate
> there was definite disagreement about whether underscores were permitted or
> not. As previously mentioned, I didn’t consider underscore characters
> prohibited until the ballot was proposed eliminating them in Oct. I know
> the general Mozilla population disagrees but, right or wrong, that’s the
> root cause of it all. I can explain my reasoning again here, but I doubt it
> materially alters the conversation and outcome.
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Tuesday, December 18, 2018 7:35 PM
> *To:* Jeremy Rowley 
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* Re: Underscore characters
>
>
>
> Jeremy,
>
>
>
> It seems like any answer for what it "might" look like if a CA violated
> the BRs in a particular way is going to be predicated on what the incident
> report says. In the case of a hypothetical like this, it seems like the
> hypothetical incident report would discuss what is planned or proposed, and
> should a CA go forward with such an intentional violation, the 'actual'
> incident report would equally consider how accurate that was.
>
>
>
> Recall that the approach to incident reporting is not punitive - it's to
> make sure that we're addressing systemic gaps and issues, that we've
> understood the issues, and have the available data to assess the impact,
> risk, and any patterns of issues. The incident reporting template is one
> way to provide that data in a structured way and to gather feedback.
>
>
>
> I think a minimum next step is to move from the abstract discussion to the
> concrete: imagine you went forward on Jan 15 and had to file an incident
> report. Write the report like that. Include the timeframes, affected
> certificates, impact, root causes, remediation plans, etc. Having a
> complete presentation of what the discussion is about seems critical to
> having that discussion, because it would be unreasonable to expect
> information to trickle in and new customers or use cases added as the
> discussion progresses.
>
>
>
> Thus there's a balance to be struck: Treating each hypothetical as a
> "separate" incident report runs the risk of being considered in isolation,
> ignoring both the systemic gaps and the cumulative risk. At the same time,
> treating it as a "singular" incident report tries to paint 

Re: Online exposed keys database

[Matt Palmer via dev-security-policy]

On Wed, Dec 19, 2018 at 11:30:47AM +0100, Kurt Roeckx via dev-security-policy 
wrote:
> I'm not sure how you feel about listing keys where you don't have the
> private key for, but are known to be compromised anyway. One potential
> source for such information might be CRLs where the reason for revocation
> was keyCompromise.

At *this* stage, I'm really only interested in providing proof of key
exposure, via signatures.  Just listing keys and saying "trust me, these are
compromised" just seems... weak, somehow.  Also, trawling revocation lists
for keys requires matching up the issuer+serial number to a cert in another
store (since CRLs only record serial numbers), which is just *annoying*.

> If you don't want to publish the private keys, distributing the public keys
> might be an option.

For a "bulk" export, yes, that is a possibility.

- Matt

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

Re: Online exposed keys database

[Rob Stradling via dev-security-policy]

Hi Matt.  This is great.  A few comments inline...

On 19/12/2018 09:00, Matt Palmer via dev-security-policy wrote:
> Hi Ryan,
> 
> On Tue, Dec 18, 2018 at 08:24:48PM -0800, Ryan Hurst via dev-security-policy 
> wrote:
>> My first thought is by using SPKI you have limited the service
>> unnecessarily to X.509 related keys, I imagined something like this
>> covering PGP, JWT as well as other formats.  It would be nice to see the
>> scope increased accordingly.
> 
> I had to use *something* to hash to get a fingerprint, and SPKI just
> happened to be the easiest to get out of Ruby's OpenSSL library.  It's also
> been well-defined for a very long time and so, I hope, is fairly widely
> supported.
> 
> Converting keys which happen to be in other formats into SPKI is a Simple
> Matter of Programming (or at least as simple as anything involving ASN.1
> ever is).  They're all the same key parameters underneath, after all (I
> noticed everyone seems to use the EC point encoding format from SEC 1,
> even).
> 
> I've already written code to do SSH public keys
> (https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/lib/openssl/pkey.rb),
> and it wasn't particularly onerous.  Extracting public keys out of PGP or
> JWK wouldn't, I presume, be a Herculean task, either.
> 
> At any rate, if I'd chosen some other format to represent the data to be
> hashed, then I'd have needed to write code to convert from SPKI to *that*
> format to search for keys in certificates, so it's all much of a muchness,
> modulo relative distaste for particular formats.

How do you handle malformed SPKIs?  (e.g., the algorithm parameters 
field for an RSA public key is missing, whereas it should be present and 
should contain an ASN.1 NULL).

Presumably your server/database only deals with correctly encoded SPKIs, 
and it's up to the caller to ensure that they repair an incorrectly 
encoded SPKI before they call your API?

>> It would be ideal if it were possible to download the database also, the
>> latency of the use of a third-party service while issuing certs is
>> potentially too much for a CA to eat at issuance time; something that
>> could optionally be used on-prem wouldn't leak affiliation and address
>> this.
> 
> I don't think the security community would be overly happy if I just dumped
> all the keys in a tarball for world+dog to download, but I *did* consider
> the possibility of providing something like a bloom filter of fingerprints,
> for people who really need to do high-volume, low-latency lookups.  I'd like
> to know that someone actually *wants* to do high-volume, low-latency lookups
> of exposed keys before I go building it (and the infrastructure for updating
> the filter, distributing the updates, etc), though.

I'm wondering how I might add a pwnedkeys check to crt.sh.  I think I'd 
prefer to have a table of SHA-256(SPKI) stored locally on the crt.sh DB.

>> As long as its limited to X.509, or at least as long as it supports it and
>> uses SPKI, it would be interesting to have the website use PKIjs to let
>> you browse to a cert, csr or key and the SPKI calculated for you.  Happy
>> to help with that if your interested.
> 
> My JavaScript skills are even worse than my Golang skills, so yeah, it would
> probably be better for everyone if someone else was willing to build that.
> 
> The command-line querying tool I wrote
> (https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/bin/pwnedkeys-query)
> takes all X.509-key-bearing forms and SSH public keys already, but I never
> expected it to be the primary querying tool for anyone other than the
> hard-core amongst us.  A more user-friendly frontend would, no doubt, be
> appreciated by many.
> 
>> Personally I prefer https://api.pwnedkeys.com/v1/ to
>> https://v1.pwnedkeys.com/.
> 
> I did it that way mostly so I can run future versions of the API on separate
> infrastructure.  The current version is very lightweight and scalable; if a
> future API version required more processing power to run at scale, I'd
> prefer to be able to manage them separately.  Not everyone has Google
> Frontends they can put everything behind...   It's a minor detail,
> though, and one which should impact all of about a dozen people (whoever's
> writing pwnedkeys querying libraries).  If it turns out I was
> being unnecessarily pessimistic, v2 of the API can always move under
> `api.pwnedkeys.com`, because the URL will change anyway for every new
> protocol version, regardless of how it's versioned.
> 
>> I see your using JWS; I had been planning on building mine on top of
>> Trillian (https://github.com/google/trillian) so you could have an
>> auditable low trust mechanism to do this.  Let me know if your interested
>> in that and I would be happy to help there.
> 
> As far as using JWS, I *really* wanted to include a signature in the
> attestation of compromise, so there was iron-clad proof that the key was in
> the control of someone who wanted to say it was pwned (hence why the signed

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On 2018-12-19 10:55, Matt Palmer wrote:

On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy 
wrote:

On 2018-12-18 11:44, Matt Palmer wrote:

It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.


You might for instance also want to look at
https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.


Oh my, that's an interesting trove.  I was a bit worried at first that the
private keys weren't included, but it looks like there's at least some in
there.


I'm not sure how you feel about listing keys where you don't have the 
private key for, but are known to be compromised anyway. One potential 
source for such information might be CRLs where the reason for 
revocation was keyCompromise.


If you don't want to publish the private keys, distributing the public 
keys might be an option.



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

Re: Online exposed keys database

[Matt Palmer via dev-security-policy]

On Wed, Dec 19, 2018 at 10:08:51AM +0100, Kurt Roeckx via dev-security-policy 
wrote:
> On 2018-12-18 11:44, Matt Palmer wrote:
> > It's currently loaded with great piles of Debian weak keys (from multiple
> > architectures, etc), as well as some keys I've picked up at various times.
> > I'm also developing scrapers for various sites where keys routinely get
> > dropped.
> 
> You might for instance also want to look at
> https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.

Oh my, that's an interesting trove.  I was a bit worried at first that the
private keys weren't included, but it looks like there's at least some in
there, although they're pretty much all 512 bit keys, with a few 1024s and
only one 2048.  Not surprising, given the age of the repo, but hey, an
exposed key's still a key!

Thanks for the pointer, I've imported the 2048 bit key.

- Matt

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

Re: Underscore characters

[Jakob Bohm via dev-security-policy]

On 19/12/2018 04:14, Peter Bowen wrote:
> On Tue, Dec 18, 2018 at 6:52 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Ballot 202 failed. I’m not sure how it’s relevant other than to indicate
>> there was definite disagreement about whether underscores were permitted or
>> not. As previously mentioned, I didn’t consider underscore characters
>> prohibited until the ballot was proposed eliminating them in Oct. I know
>> the general Mozilla population disagrees but, right or wrong, that’s the
>> root cause of it all. I can explain my reasoning again here, but I doubt it
>> materially alters the conversation and outcome.
>>
> 
> I agree that Jeremy that the situation with underscores was unclear prior
> to the ballot in October.  Three years ago when I was writing certlint, my
> very first public commit has the comment:
> # Allow RFC defying '*' and '_'
> 
> I honestly haven't been pay a lot of attention to the CA/Browser Forum
> recently.  Given the rationale for getting rid of underscores is RFC
> compliance, did the ballot also disallow asterisks?  They are also not
> allowed by the "preferred name syntax", as specified by Section 3.5 of
> [RFC1034]  and as modified
> by Section 2.1 of 
>   [RFC1123] .
> 

The problematic section of RFC5280 contains this paragraph, wedged between 
encoding descriptions (which happen to include a reference to the "preferred 
syntax" of host names) and the corresponding ASN.1 syntax:

   Finally, the semantics of subject alternative names that include
   wildcard characters (e.g., as a placeholder for a set of names) are
   not addressed by this specification.  Applications with specific
   requirements MAY use such names, but they must define the semantics.

A different RFC defines the modern semantics of wildcard certificates, 
thus providing the required definition.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Online exposed keys database

[Peter Gutmann via dev-security-policy]

Ryan Hurst via dev-security-policy  
writes:

>My first thought is by using SPKI you have limited the service unnecessarily
>to X.509 related keys, I imagined something like this covering PGP, JWT as
>well as other formats. It would be nice to see the scope increased
>accordingly.

You can't do it for PGP, that hashes in a pile of additional stuff unrelated
to the key so there's no way to uniquely identify a specific key, only "the
key and this specific set of metadata".  Using the SPKI for the hash is the
best option, I use that internally as the unique ID for keys, including PGP
ones.

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

Re: Online exposed keys database

[Kurt Roeckx via dev-security-policy]

On 2018-12-18 11:44, Matt Palmer wrote:

It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times.
I'm also developing scrapers for various sites where keys routinely get
dropped.


You might for instance also want to look at 
https://github.com/devttys0/littleblackbox, I'm not sure how useful it is.



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

Re: Online exposed keys database

[Matt Palmer via dev-security-policy]

Hi Ryan,

On Tue, Dec 18, 2018 at 08:24:48PM -0800, Ryan Hurst via dev-security-policy 
wrote:
> My first thought is by using SPKI you have limited the service
> unnecessarily to X.509 related keys, I imagined something like this
> covering PGP, JWT as well as other formats.  It would be nice to see the
> scope increased accordingly.

I had to use *something* to hash to get a fingerprint, and SPKI just
happened to be the easiest to get out of Ruby's OpenSSL library.  It's also
been well-defined for a very long time and so, I hope, is fairly widely
supported.

Converting keys which happen to be in other formats into SPKI is a Simple
Matter of Programming (or at least as simple as anything involving ASN.1
ever is).  They're all the same key parameters underneath, after all (I
noticed everyone seems to use the EC point encoding format from SEC 1,
even).

I've already written code to do SSH public keys
(https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/lib/openssl/pkey.rb),
and it wasn't particularly onerous.  Extracting public keys out of PGP or
JWK wouldn't, I presume, be a Herculean task, either.

At any rate, if I'd chosen some other format to represent the data to be
hashed, then I'd have needed to write code to convert from SPKI to *that*
format to search for keys in certificates, so it's all much of a muchness,
modulo relative distaste for particular formats.

> It would be ideal if it were possible to download the database also, the
> latency of the use of a third-party service while issuing certs is
> potentially too much for a CA to eat at issuance time; something that
> could optionally be used on-prem wouldn't leak affiliation and address
> this.

I don't think the security community would be overly happy if I just dumped
all the keys in a tarball for world+dog to download, but I *did* consider
the possibility of providing something like a bloom filter of fingerprints,
for people who really need to do high-volume, low-latency lookups.  I'd like
to know that someone actually *wants* to do high-volume, low-latency lookups
of exposed keys before I go building it (and the infrastructure for updating
the filter, distributing the updates, etc), though.

> As long as its limited to X.509, or at least as long as it supports it and
> uses SPKI, it would be interesting to have the website use PKIjs to let
> you browse to a cert, csr or key and the SPKI calculated for you.  Happy
> to help with that if your interested.

My JavaScript skills are even worse than my Golang skills, so yeah, it would
probably be better for everyone if someone else was willing to build that. 

The command-line querying tool I wrote
(https://github.com/pwnedkeys/pwnedkeys-tools/blob/master/bin/pwnedkeys-query)
takes all X.509-key-bearing forms and SSH public keys already, but I never
expected it to be the primary querying tool for anyone other than the
hard-core amongst us.  A more user-friendly frontend would, no doubt, be
appreciated by many.

> Personally I prefer https://api.pwnedkeys.com/v1/ to
> https://v1.pwnedkeys.com/.

I did it that way mostly so I can run future versions of the API on separate
infrastructure.  The current version is very lightweight and scalable; if a
future API version required more processing power to run at scale, I'd
prefer to be able to manage them separately.  Not everyone has Google
Frontends they can put everything behind...   It's a minor detail,
though, and one which should impact all of about a dozen people (whoever's
writing pwnedkeys querying libraries).  If it turns out I was 
being unnecessarily pessimistic, v2 of the API can always move under
`api.pwnedkeys.com`, because the URL will change anyway for every new
protocol version, regardless of how it's versioned.

> I see your using JWS; I had been planning on building mine on top of
> Trillian (https://github.com/google/trillian) so you could have an
> auditable low trust mechanism to do this.  Let me know if your interested
> in that and I would be happy to help there.

As far as using JWS, I *really* wanted to include a signature in the
attestation of compromise, so there was iron-clad proof that the key was in
the control of someone who wanted to say it was pwned (hence why the signed
data includes a statement to that effect, rather than a signature over some
arbitrary data that could potentially be spoofed).  As I mentioned in the
FAQ, I first thought of formatting the signatures into X.509 certs or CSRs,
but I didn't want to create any chance of confusion with legitimate X.509
objects.  Also, I really don't *want* this to be an X.509-only thing, and
this way I could annoy people who don't like JOSE as well as the people who
don't like X.509.  

With regards to using Trillian (or verifiable data structures in general),
given my background in working with CT, you can rest assured I spent a *lot*
of time pondering how a transparency approach could provide value. 
Honestly, I wish I could have figured out some way to profitably