Subject: [lamps] Recharter Discussion

From: Russ Housley <[email-masked]>
Date: Sun, 25 Jun 2017 12:25:18 -0400

We have almost finished the last document under the current charter.  We will beed to deal with any concerns raised by the IESG, but we should starts drafting the next version of the charter while that is happening.  In Chicago, we talked about several possible topics for the re-charter:

4c)  OCSP response extension for revocation hint text (Rich)

Rich withdrew his support for this one.  Unless someone else wants to step in, this one will be dropped.

4b)  Updates to CAA for RFC Erratum 4514 (Phill)

HUM: Consensus in the room to suggest this for a future LAMPS WG charter.  Please propose a paragraph for the charter.

4a)  Adding SHA3 to PKIX and S/MIME (Sean)

HUM: Many people in the room to suggest this as a topic for a future
  LAMPS WG charter; however, a significant number thought it should not
  be done.

Many people thought that SHA-256, SHA-384, and SHA-512 filled this need.  If you would like to see it move forward, please propose a paragraph for the charter.

Are there any other topics that someone would like to raise now?  All three of the above topics had at least one document to support them.  So, new topics should come with an Internet-Draft or a promise of one before the I-D cutoff for Prague.

Russ

---

From: William Conner <[email-masked]>
Date: Mon, 26 Jun 2017 11:11:23 -0500

On Sun, Jun 25, 2017 at 11:25 AM, Russ Housley <[email-masked]> wrote:

> Many people thought that SHA-256, SHA-384, and SHA-512 filled this need.
> If you would like to see it move forward, please propose a paragraph for
> the charter.
>
>
> Are there any other topics that someone would like to raise now?  All
> three of the above topics had at least one document to support them.  So,
> new topics should come with an Internet-Draft or a promise of one before
> the I-D cutoff for Prague.
>
> I would like to raise BLAKE2 for PKIX (draft-wconner-blake2sigs-01) as an
alternative to 4a.

William

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Jun 2017 16:17:11 +0000

> I would like to raise BLAKE2 for PKIX (draft-wconner-blake2sigs-01) as an alternative to 4a.

Which one?  Aren't all four(?) versions different?

---

From: William Conner <[email-masked]>
Date: Tue, 27 Jun 2017 08:06:29 -0500

> Which one?  Aren't all four(?) versions different?

Sorry, I seem to be missing something and don't quite understand what
you're asking.  Would you please elaborate?  Thanks.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Jun 2017 13:36:05 +0000

> Sorry, I seem to be missing something and don't quite understand what you're asking.  Would you please elaborate?  Thanks. 

My fault.  The text of your document says it uses 2b-512 quite explicitly.  Perhaps that should be reflected in the title?
My understanding is that blake2b and blake2s are very different.  More so than, say, RSA512 vs RAS2048.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 27 Jun 2017 13:21:38 -0400

X. Specify a discovery mechanism for CAA records to replace the one
described in RFC 6844

On Sun, Jun 25, 2017 at 12:25 PM, Russ Housley <[email-masked]> wrote:

> We have almost finished the last document under the current charter.  We
> will beed to deal with any concerns raised by the IESG, but we should
> starts drafting the next version of the charter while that is happening.
> In Chicago, we talked about several possible topics for the re-charter:
>
>
> HUM: Consensus in the room to suggest this for a future LAMPS WG charter.
> Please propose a paragraph for the charter.
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jun 2017 10:51:28 -0400

I would like to suggest a new PKIX extension, the 'First Issued' attribute.
This has been discussed many times but not actually implemented as far as I
know.

A certificate that was issued a year ago is much less likely to be
fraudulent than one issued five minutes ago. While criminals could in
theory apply for and stockpile large numbers of certificates, the takes
planning and discipline and limits their options when responding to new
security controls.

A certificate issued with an expiry interval of 400 days will be less than
a day old for only 0.25% of its lifetime. But if we move to 3 day certs,
the certificate will be less than a day old for 33% of the time. The value
of the certificate age indication is lost entirely.

Adding a 'first issued' attribute would allow a CA to state when the first
certificate was issued to the subject. Similar to the American Express
'member since' indication.

I don't have a draft or text yet. But I can write them up if people are
interested in doing this.

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Jun 2017 11:05:20 -0400

Phill:

I just want to make sure I understand your proposal.  I can see that a renew does not change the date in the first-issued extension.  Does a rekey change it?

Russ

> On Jun 29, 2017, at 10:51 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> I would like to suggest a new PKIX extension, the 'First Issued' attribute. This has been discussed many times but not actually implemented as far as I know.
> 
> A certificate that was issued a year ago is much less likely to be fraudulent than one issued five minutes ago. While criminals could in theory apply for and stockpile large numbers of certificates, the takes planning and discipline and limits their options when responding to new security controls.
> 
> A certificate issued with an expiry interval of 400 days will be less than a day old for only 0.25% of its lifetime. But if we move to 3 day certs, the certificate will be less than a day old for 33% of the time. The value of the certificate age indication is lost entirely.
> 
> Adding a 'first issued' attribute would allow a CA to state when the first certificate was issued to the subject. Similar to the American Express 'member since' indication.
> 
> I don't have a draft or text yet. But I can write them up if people are interested in doing this.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jun 2017 11:16:29 -0400

On Thu, Jun 29, 2017 at 11:05 AM, Russ Housley <[email-masked]> wrote:

> Phill:
>
> I just want to make sure I understand your proposal.  I can see that a
> renew does not change the date in the first-issued extension.  Does a rekey
> change it?
>
> Russ
>

​Good question!​

​The simplest implementation to audit would have the date be for the key
and thus change on rekey.

But the most useful ​implementation would be to have the date correspond to
the subject and we certainly do not want to discourage rekeying.

That does leave open the question of whether changes in the subject name
cause a break and whether a CA may use the earliest date at which any
certificate was issued.

There is something of a slippery slope here. I see two approaches

1) Be intentionally vague and kick the problem to TRANS and/or CABForum.

2) Limit the time to the time that CA issued a certificate to that subject
name

Part of the complexity here is that certificate issue on the enterprise
side is not typically authenticated by means that are within PKIX or TRANS
scope.

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Jun 2017 11:21:48 -0400

> On Jun 29, 2017, at 11:16 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> On Thu, Jun 29, 2017 at 11:05 AM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Phill:
> 
> ​The simplest implementation to audit would have the date be for the key and thus change on rekey.
> 
> But the most useful ​implementation would be to have the date correspond to the subject and we certainly do not want to discourage rekeying.
> 
> That does leave open the question of whether changes in the subject name cause a break and whether a CA may use the earliest date at which any certificate was issued.
> 
> 
> 2) Limit the time to the time that CA issued a certificate to that subject name
> 
> 
> Part of the complexity here is that certificate issue on the enterprise side is not typically authenticated by means that are within PKIX or TRANS scope.
> 

Do others have an opinion?

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Jun 2017 11:29:58 -0400

On Thu, Jun 29, 2017 at 10:51 AM, Phillip Hallam-Baker <
[email-masked]> wrote:

> I would like to suggest a new PKIX extension, the 'First Issued'
> attribute. This has been discussed many times but not actually implemented
> as far as I know.
>

Could you point to the past discussions, so that I can read up and
hopefully otherwise avoid criticisms or concerns that may have already been
raised or addressed in past discussions, but not covered in your brief
description?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jun 2017 15:31:53 +0000

I think this is an interesting extension and could be useful.

I think it should indicate the first time that the key and subjectName were certified; if either changes, the date gets reset.  That seems the simplest to understand and explain, even if it limits the utility in some corner cases.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: mailto:[email-masked] Twitter: RichSalz

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jun 2017 11:47:23 -0400

> raised or addressed in past discussions, but not covered in your brief

​I will attempt to. I have to work out if it was presented or discussed on
the list and if presented whether I still have the powerpoints or if it was
from my time at VRSN.

There is also the question of where it was made.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jun 2017 19:17:05 +0300

> On 29 Jun 2017, at 18:21, Russ Housley <[email-masked]> wrote:
> 
>> 
>> On Jun 29, 2017, at 11:16 AM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
>> 

It kind of reminds me of this (3rd slide):
https://www.ietf.org/proceedings/69/slides/pkix-5.pdf <https://www.ietf.org/proceedings/69/slides/pkix-5.pdf>

As I understood it at the time, it was meant to be a stand-in for reputation, and that role was taken over by EV.

I agree that it has value for DV certificates, especially short-term ones. But it makes switching certificate issuers hard. Every time your domain switches to a new issuer, you lose the reputation value of this extension.

I see this as a problem unless CABForum intends to make all its members share databases.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jun 2017 12:37:52 -0400

Thanks, I remembered making the proposal but not when.

EV was well underway at that time. This was not intended to be an
alternative, it was more of an enhancement.

The third proposal, suppressing the UI entirely for device certs is
something I think we should return to but for different reasons. The aim
then was to enable free certs with what I now call 'minimal validation'
without diluting the value of DV.

On Thu, Jun 29, 2017 at 12:17 PM, Yoav Nir <[email-masked]> wrote:

> But the most useful ​implementation would be to have the date correspond
> to the subject and we certainly do not want to discourage rekeying.
>
> https://www.ietf.org/proceedings/69/slides/pkix-5.pdf
>
> As I understood it at the time, it was meant to be a stand-in for
> reputation, and that role was taken over by EV.
>
> I agree that it has value for DV certificates, especially short-term ones.
> But it makes switching certificate issuers hard. Every time your domain
> switches to a new issuer, you lose the reputation value of this extension.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Jun 2017 17:47:46 +0100

> Do others have an opinion?

The function sounds useful but perhaps better provided
via an API to a CT log (not sure). The reason I'd wonder
about that is that it's hard to see what code would
read this new value and not want more information than
that. A CT log API could provide more so might be more
useful (e.g. if an RP could ask "show me your history of
meta-data related to certs for example.com").

Probably not that relevant, but similar information would
also exist in passive DNS DBs I guess.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jun 2017 12:54:17 -0400

On Thu, Jun 29, 2017 at 12:47 PM, Stephen Farrell <[email-masked]
> wrote:

> also exist in passive DNS DBs I guess.

​There is always a cut off between the standardized parts and the rest.

When I first proposed this, it was for human consumption. What I am
thinking about now is rather more of a hook for likely proprietary AI
systems reading it.​

​Security is risk mitigation, not risk elimination. Right now we can
eliminate what? 95% of phishing sites with free DV certs by simply
rejecting any certs less than 5 days old. ​

​What we do next with the ​data is going to be important. But not something
we are going to be able to really work on at all, let alone standardize
until after we have data.

All I want to do right now is to instrument so we can start collecting data.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Jun 2017 15:22:07 +0100

Hi Phill,

> thinking about now is rather more of a hook for likely proprietary AI

Right, that's why a CT API seems maybe more useful and (I think,
but I may be wrong), might be easier to get deployed.

> All I want to do right now is to instrument so we can start collecting data.

I'm not opposed to defining such a cert extension (which I
assume would be the end result) if there's likely to be
deployment. But I still think that given that CT logs will
have this info already, (and more, and covering >1 issuer)
a new CT API may be better than putting it in certs.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Jun 2017 12:27:48 -0400

On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell <[email-masked]

> a new CT API may be better than putting it in certs.

​I don't really want to push everything into CT. This is not information
that is going to be immediately available, you would have to do a lot of
log crunching to validate.

Given that some browsers won't do CRLs or OCSP, I can't see them using CT
for pro-active checking before they accept the connection. Where I see the
value of First Issued is to allow browsers to winnow out certs that are
most likely OK and concentrate checking on those that might be a bit dodgy.

At any rate, putting an extension into the cert is pretty simple while
changing the CT API to support short lived certs is likely to be a
performance. I think that this is an easy win to get much of the return and
takes the pressure off the CT end of things.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 01 Jul 2017 04:14:18 +0000

On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker <[email-masked]>
wrote:

> On Fri, Jun 30, 2017 at 10:22 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>> Hi Phill,
>>
Who is we?

Is this a statement of what you believe browsers should do, versus will?
Have you heard of or can provide evidence for any expression of support,
from any browser, for this philosophy?

> most likely OK and concentrate checking on those that might be a bit dodgy.

Are you aware of any browsers interested in this? This feels very much like
LogoType - which was intended for browsers (among others) and rightfully
not widely implemented.

> takes the pressure off the CT end of things.

CT already has to deal with this. It does seem you're conflating two
unrelated things though, but perhaps I'm misunderstanding.

Perhaps it could be useful if you could explain what you believe the
browser security model to be, and how this supports what browsers are doing
or have expressed support for.

I do not see any value to this as an extension - and I can see undesirable
(and unreliable) data being added by CAs - so I'm curious to understand why
using CT is insufficient, especially for the proposed browser-run machine
learning reputation determination.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jul 2017 00:58:11 -0400

​Since Comodo distributes a browser, at least one browser is interested.

Given that you seem entirely unconcerned by 16,000 fake paypal sites a
certain CA has issued certs for, it is not surprising that you see no
reason to make any changes.

On Sat, Jul 1, 2017 at 12:14 AM, Ryan Sleevi <[email-masked]> wrote:

>
> On Fri, Jun 30, 2017 at 9:27 AM Phillip Hallam-Baker <
> Are you aware of any browsers interested in this? This feels very much
> like LogoType - which was intended for browsers (among others) and
> rightfully not widely implemented.
>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 01 Jul 2017 06:20:15 +0000

I do hope we can keep the discussion professional and focused on the
technical matters, and without attributing things that were not said.

It does not sound like you wish to engage in the technical discussion of
the merits, or to explain why this problem should be solved as a
certificate extension, as the previous questions were left unaddressed.

As it stands, I would prefer not to see this adopted in a recharter,
without technical justification. It does seem like, at present, it could
work as an individual draft that Comodo could implement and establish its
technical virtue and value, and perhaps then bring compelling justification
forward, perhaps with greater implementer interest.

On Fri, Jun 30, 2017 at 10:58 PM Phillip Hallam-Baker <[email-masked]>
wrote:

>>> Given that some browsers won't do CRLs or OCSP, I can't see them using
>>> CT for pro-active checking before they accept the connection. Where I see
>>> the value of First Issued is to allow browsers to winnow out certs that are
>> I do not see any value to this as an extension - and I can see
>> undesirable (and unreliable) data being added by CAs - so I'm curious to
>> understand why using CT is insufficient, especially for the proposed
>> browser-run machine learning reputation determination.
>>
>
>