Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

> On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
>  If there are proponents of a 'fail open' model,
> especially amongst CAs, then does it behove them to specify as quickly as
> possible a 'fail closed' model, so that we don't have to try and divine
> intent and second guess site operators as to whether they meant to restrict
> HTTPS or everything?

While this is in no way comprehensive or scientific, could we not just poll 
those (larger) domain owners who also operate publicly available mail services 
(like Yahoo) what they consider the scope of their CAA assertions? There can’t 
be a super abundance of them, surely?

I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of 
ninja-changing semantics either. If domain owners intended to only express a 
company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS or 
whatever); then might they not be amenable to altering their expression to an 
‘issue(wild)?-tls’ tag instead, but only if they were aware of the scope of 
their (in-)actions?

That would then enable a future move for CAs to respect ‘issue’ and ‘issuewild’ 
to cover all cert types, while still allowing domain owners finer grained 
expression of their policies. It’s pretty much an entire reversal of my earlier 
suggestion(!), but perhaps a modification which would preserve the expressions 
of (handwave, handwave) 95% of CAA records owners who don’t operate public mail 
services, and yet still can cover those mail providers?

But without the courtesy of at least asking those few domain owners what they 
meant, it just seems a bit rude to assume their intentions.

Regards,

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

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

I'm not sure how that's advancing the discussion forward or adding new
information. The discussion of CAA and wanting to get feedback predates
even the IETF finalization, as multiple browsers kept encouraging CAs to
experiment with and attempt to deploy CAA so that we could make sure the
kinks were ironed out.

Regardless of posturing and grandstanding for past statements, can we at
least agree that a model that argues "fail open" as a solution is a
fundamentally insecure one? If there are proponents of a 'fail open' model,
especially amongst CAs, then does it behove them to specify as quickly as
possible a 'fail closed' model, so that we don't have to try and divine
intent and second guess site operators as to whether they meant to restrict
HTTPS or everything?

Put differently, if you want to argue that CAA is HTTPS only, then you need
to define a way to ensure it's not HTTPS-only, and ASAP. Otherwise, the
solution is that when S/MIME BRs come around, we simply cannot and should
not second guess site operators and try to argue CAA was only 'those' type
of certs - and instead require anyone with a CAA record to explicitly
opt-in to allowing (potentially unbounded) S/MIME. I don't see any other
realistic or practical solution - you can't say "This protects you" and
then propose 2 years down the road, with S/MIME BRs, that it didn't
actually 'protect' the site operator - the same way you can't say "Restrict
access to these five email addresses" and then introduce a dozen more 2
years down the road.

On Mon, May 14, 2018 at 11:07 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Normally I’d agree that IETF cannot and should not be a blocker for action
> at Mozilla and/or CABF, but based on our experience with CAA for web
> certificates, I would encourage people to get in their time machines and go
> back two to three years, and listen to Tim standing up and saying “I like
> CAA for the Web PKI, but what have we not thought of?”
>
>
>
> -Tim
>
>
>
> From: Ryan Sleevi [mailto:r...@sleevi.com]
> Sent: Monday, May 14, 2018 8:24 PM
> To: Tim Hollebeek 
> Cc: r...@sleevi.com; Pedro Fuentes ;
> mozilla-dev-security-policy  >
> Subject: Re: question about DNS CAA and S/MIME certificates
>
>
>
> I don't actually think there is any IETF component to this. There can be,
> but it's not required to be.
>
>
>
> On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org  lists.mozilla.org> > wrote:
>
> There’s an IETF component, but minimum necessary standards for email
> certificate issuance is a policy issue, not a technical one.
>
>
>
> Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA
> in accordance with CAA-bis.”
>
>
>
> -Tim
>
>
>
>
> With CABF governance reform coming into effect on July 3rd, I'm cautiously
> optimistic
> we can start writing requirements for e-mail certificates and phasing out
> bad practices
> and phasing in good practices soon.  CAA for e-mail certificates is
> definitely worth
> considering as part of that process.
>
>
>
> Isn't this an IETF issue? Shouldn't those who issue e-mail certificates
> begin looking at the level of authentication provided for domains today?
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org  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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

Normally I’d agree that IETF cannot and should not be a blocker for action at 
Mozilla and/or CABF, but based on our experience with CAA for web certificates, 
I would encourage people to get in their time machines and go back two to three 
years, and listen to Tim standing up and saying “I like CAA for the Web PKI, 
but what have we not thought of?”

 

-Tim

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, May 14, 2018 8:24 PM
To: Tim Hollebeek 
Cc: r...@sleevi.com; Pedro Fuentes ; 
mozilla-dev-security-policy 
Subject: Re: question about DNS CAA and S/MIME certificates

 

I don't actually think there is any IETF component to this. There can be, but 
it's not required to be.

 

On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy 
 > wrote:

There’s an IETF component, but minimum necessary standards for email 
certificate issuance is a policy issue, not a technical one.



Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in 
accordance with CAA-bis.”



-Tim




With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.



Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?


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

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

I don't actually think there is any IETF component to this. There can be,
but it's not required to be.

On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> There’s an IETF component, but minimum necessary standards for email
> certificate issuance is a policy issue, not a technical one.
>
>
>
> Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA
> in accordance with CAA-bis.”
>
>
>
> -Tim
>
>
>
> With CABF governance reform coming into effect on July 3rd, I'm cautiously
> optimistic
> we can start writing requirements for e-mail certificates and phasing out
> bad practices
> and phasing in good practices soon.  CAA for e-mail certificates is
> definitely worth
> considering as part of that process.
>
>
>
> Isn't this an IETF issue? Shouldn't those who issue e-mail certificates
> begin looking at the level of authentication provided for domains today?
>
>
> ___
> 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: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

There’s an IETF component, but minimum necessary standards for email 
certificate issuance is a policy issue, not a technical one.

 

Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in 
accordance with CAA-bis.”

 

-Tim

 

With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.

 

Isn't this an IETF issue? Shouldn't those who issue e-mail certificates begin 
looking at the level of authentication provided for domains today?



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Pedro Fuentes via dev-security-policy]

El lunes, 14 de mayo de 2018, 23:59:07 (UTC+2), Tim Hollebeek  escribió:

> As Neil correctly notes, it would be foolish to try to impose semantics and 
> apply
> policy from the web CAA records onto email certificate issuance without first
> figuring out what the semantics, requirements and policies should be for email
> certificate issuance.
> 
> -Tim

Maybe I'd add to the equation too that sometimes end-users can't easily choose 
which CA can use in a certain jurisdiction or user community.

I will subscribe the statement above from Neil: "Please note: I’m not opposed 
to CAA stipulations applying to S/MIME. I would just want all participants in 
the PKI world to know what their statements mean and how far they reach. "
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

> Today this is a "non-issue" because nothing is obligating CAs to respect 
> CAA,
> and thus they can (and are) doing the thing that helps them issue more
> certificates (and, presumably, make more money) - but that doesn't 
> necessarily
> mean its the right thing.

I can think of at least one CA that values "# of right things done" more
highly than "# of certificates issued".  Actually, I can think of two or 
three.
There are probably more.

> Yes, it means that introducing CAA restrictions for
> S/MIME necessarily means there will need to be a way to distinguish these
> cases, so that an organization could restrict e-mail vs HTTPS - so CAs that 
> wish
> to issue S/MIME should start working on these.

Right.  CAA-bis is a pre-requisite here.

As Neil correctly notes, it would be foolish to try to impose semantics and 
apply
policy from the web CAA records onto email certificate issuance without first
figuring out what the semantics, requirements and policies should be for email
certificate issuance.

-Tim


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Jakob Bohm via dev-security-policy]

On 14/05/2018 20:55, Ryan Sleevi wrote:

The Public Suffix List is a model for failure, not success - and I say that
as one of the two PSL maintainers. As to the remaining points, I think each
and every one of them doesn't actually hold up to scrutiny, and in fact,
the opposite conclusion is more in line with reality.

For example, if anti-spam systems applied per-account algorithms, then
there's an incentive for spammers to add themselves to the list. This is
demonstrable by some CAs using rate limiting at the PSL boundary, causing a
surge in additions to bypass those rate limits - similarly for various
browser security mechanisms.



I was not aware that the domain PSL allowed random self-addition without
checks, and thus related abuses.  The hypothetical mail PDL would be
based on external observation and confirmation, not self-declaration, as
true PDL entries (3rd party e-mail hosts) are in a partially adversarial
role to their (paying) users.


Regarding the domain holder acting as behalf as the user - it's absolutely
true they can. The position advocated is like suggesting that 3.2.2.4.6 is
more secure than 3.2.2.4.2/.3 - the domain holder has primacy over the
website operator, and the postmaster has primacy over individual mailboxes.



That's arguing the conclusion.  The question is what the hierarchy of
supremacy should be for e-mail, given that e-mail is a different
landscape than website hosting.  And I am arguing that the correct
answer depends heavily on the nature of the e-mail system involved.

A company postmaster has obvious supremacy over company e-mail accounts.

But a common carrier ISP postmaster should not have supremacy over their
users.


On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Another approach could be to have something akin to the (non-ICANN)
public suffix list, but for e-mail.  This would list e-mail domains
where the e-mail address holders are not the subordinates (employees,
students, etc.) of the domain holder.

Such a list would have multiple uses (just like the public suffix list for
domain delegations):

1. E-mails from these domains are not presumed to represent the opinion
   of the domain holder in various contexts (including validation of TLS
   certs against non-reserved e-mail addresses).

2. Anti-spam systems could apply a more per-account algorithm for
   computing reputation scores.

3. S/MIME certificate issuance does not assume the domain holder can
   act on behalf of the e-mail users.  Thus validation with
   postmas...@example.net would not be valid for joesh...@example.net,
   but on the other hand CAA records for example.net would not apply
   to S/MIME (both if example.net was on the public e-mail domain list).


On 14/05/2018 17:48, Neil Dunbar wrote:


But it also seems reasonable for organisations making CAA assertions to
know the scope of their stipulations before they make them, no?

So, if in the case of Yahoo, they make the assertion “All of our web
certificates should come from DigiCert”, are they aware that they are also
making the statement “And all of our user mail accounts should only be
granted S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number
of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift
to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s
customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I
would just want all participants in the PKI world to know what their
statements mean and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be
restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean
‘covering all possible forms of certificates’?

Just a thought,

Neil

On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy <

dev-security-policy@lists.mozilla.org> wrote:

It seems perfectly reasonable and desirable to require that CAs,
regardless
of the type of certificate they are issuing, respect CAA.

If an email provider wishes to restrict some types of certificates (e.g.
HTTPS) while allow others (e.g. S/MIME), this could be accomplished
through
additional expressions within the CAA syntax.

However, it would be a long-lasting, and tragic mistake if CAA was
presumed
to 'only' apply to HTTPS - because it would make the same mistake of
nameConstraints - namely, everything that is not expressly listed as
permitted/restricted is implicitly permitted - rather than doing what
security practitioners have long known is the safe and secure base -
forbid
unless expressly permitted (default-deny).

In terms of order of concerns and constituents, the domain holders needs
and security goals outweigh those of the notion of users 'owning' an
email
address.

On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

Just 

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Jakob Bohm via dev-security-policy]

On 14/05/2018 22:53, Wayne Thayer wrote:

On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:



I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
Dean???
- We can’t permit user generated passwords (at least that is Tim's
proposal, Wayne may not agree yet but he will when he reads this email)
- We can’t distribute both the password and PKCS#12 over the same channel,
even if it's a secure channel like HTTPS

We have 2 choices for where the password is generated: CA or User




Or the user could generate the key :-)





1) If we require CAs to generate the passwords and they can’t distribute
the necessary information to the end user via the portal over TLS (because
of the dual channel requirement), then that is a relatively large impact on
us, and probably anyone else that supports PKCS#12 file formats.  If the
channel is secure, do you need to use different channels?


2) Trying to compute the entropy of a user generated password is  nearly
impossible.  According to NIST Special Publication 800-63, a good 20
character password will have just 48 bits of entropy, and characters after
that only add 1 bite of entropy each.  User stink at generating Entropy
(right Tim?)

NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
following scheme to roughly estimate the entropy of human-generated
passwords (Subsequent updates of this publication gave up trying to compute
entropy for user generated passwords, and when they talk about entropy they
talk about 20 bits max):
•   The entropy of the first character is four bits;
•   The entropy of the next seven characters are two bits per
character;
•   The ninth through the twentieth character has 1.5 bits of entropy
per character;
•   Characters 21 and above have one bit of entropy per character.
•   A "bonus" of six bits is added if both upper case letters and
non-alphabetic characters are used.
•   A "bonus" of six bits is added for passwords of length 1 through
19 characters following an extensive dictionary check to ensure the
password is not contained within a large dictionary. Passwords of 20
characters or more do not receive this bonus because it is assumed they are
pass-phrases consisting of multiple dictionary words.

https://pages.nist.gov/800-63-3/

Some CAs are probably asking the user for a password during the request
thus there is no need to distribute it later.  But, if the Applicant
provides the password over HTTPS and then later the CA provides the PKCS#12
via download link and they obtain it via HTTPS, is that a single channel
that they were both distributed over?

I still object to not being able to use HTTPS for collection and/or
distribution of the Password and the PKCS#12.  I also believe 112 bits of
entropy is way too much for user generated password (assuming we want to
continue supporting that option).

Perhaps the following language is a workable solution to the first

objection?

PKCS#12 files must employ an encryption key and algorithm that is
sufficiently strong to protect the key pair for its useful life based on
current guidelines published by a recognized standards body. PKCS#12 files
MUST be encrypted and signed; or, MUST have a password that exhibits at
least 112 bits of entropy, and the password MUST be transmitted via a
secure channel.

I really don't seem a benefit to user generation of these passwords -
either they are weak and memorable, or sufficiently complicated that
there's little value in being able to choose it.



Maybe reconsider the idea of extending the PKCS#12 key length rules from 
insecure to secure channels.


In other words, if the channel itself is sufficiently secure to allow
distribution of the key in a format with no encryption of its own, then
there maybe shouldn't be additional requirements for the PKCS#12 file.

Also consider the issue of key generation for individual users by
a constrained SubCAs belonging to an organization.  Here the private key
generation and protection may be handled by the organization internal
security and encryption channels, that bear little resemblance to the
3rd party CA scenario.


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: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
> Dean???
> - We can’t permit user generated passwords (at least that is Tim's
> proposal, Wayne may not agree yet but he will when he reads this email)
> - We can’t distribute both the password and PKCS#12 over the same channel,
> even if it's a secure channel like HTTPS
>
> We have 2 choices for where the password is generated: CA or User
>
> >
Or the user could generate the key :-)
>

> 1) If we require CAs to generate the passwords and they can’t distribute
> the necessary information to the end user via the portal over TLS (because
> of the dual channel requirement), then that is a relatively large impact on
> us, and probably anyone else that supports PKCS#12 file formats.  If the
> channel is secure, do you need to use different channels?
>
>
> 2) Trying to compute the entropy of a user generated password is  nearly
> impossible.  According to NIST Special Publication 800-63, a good 20
> character password will have just 48 bits of entropy, and characters after
> that only add 1 bite of entropy each.  User stink at generating Entropy
> (right Tim?)
>
> NIST Special Publication 800-63 of June 2004 (revision 2) suggested the
> following scheme to roughly estimate the entropy of human-generated
> passwords (Subsequent updates of this publication gave up trying to compute
> entropy for user generated passwords, and when they talk about entropy they
> talk about 20 bits max):
> •   The entropy of the first character is four bits;
> •   The entropy of the next seven characters are two bits per
> character;
> •   The ninth through the twentieth character has 1.5 bits of entropy
> per character;
> •   Characters 21 and above have one bit of entropy per character.
> •   A "bonus" of six bits is added if both upper case letters and
> non-alphabetic characters are used.
> •   A "bonus" of six bits is added for passwords of length 1 through
> 19 characters following an extensive dictionary check to ensure the
> password is not contained within a large dictionary. Passwords of 20
> characters or more do not receive this bonus because it is assumed they are
> pass-phrases consisting of multiple dictionary words.
>
> https://pages.nist.gov/800-63-3/
>
> Some CAs are probably asking the user for a password during the request
> thus there is no need to distribute it later.  But, if the Applicant
> provides the password over HTTPS and then later the CA provides the PKCS#12
> via download link and they obtain it via HTTPS, is that a single channel
> that they were both distributed over?
>
> I still object to not being able to use HTTPS for collection and/or
> distribution of the Password and the PKCS#12.  I also believe 112 bits of
> entropy is way too much for user generated password (assuming we want to
> continue supporting that option).
>
> Perhaps the following language is a workable solution to the first
objection?

PKCS#12 files must employ an encryption key and algorithm that is
sufficiently strong to protect the key pair for its useful life based on
current guidelines published by a recognized standards body. PKCS#12 files
MUST be encrypted and signed; or, MUST have a password that exhibits at
least 112 bits of entropy, and the password MUST be transmitted via a
secure channel.

I really don't seem a benefit to user generation of these passwords -
either they are weak and memorable, or sufficiently complicated that
there's little value in being able to choose it.

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

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Wayne Thayer via dev-security-policy]

On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> > I think we have settled on the following resolution to this issue:
> >
> > Add the following to section 5.2 (Forbidden and Required Practices):
> >
> > CAs MUST NOT generate the key pairs for end-entity certificates that have
> > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> > > anyExtendedKeyUsage.
> > >
> > > PKCS#12 files must employ an encryption key and algorithm that is
> > > sufficiently strong to protect the key pair for its useful life based
> on
> > > current guidelines published by a recognized standards body. PKCS#12
> files
> > > MUST be encrypted and signed; or, MUST have a password that exhibits at
> > > least 112 bits of entropy, and the password MUST be transferred using a
> > > different channel than the PKCS#12 file.
> > >
> >
> > Unless there is further discussion, I will include this language in the
> > final version of the policy.
> >
> > - Wayne
>
> In one use case, the Subscriber can create their own password to start the
> enrollment process for the S/MIME certificate. The P12 is created,
> encrypted and sent to the Subscriber to be decrypted using the password. I
> think that asking the Subscriber to create a password with 112-bits entropy
> may create a very long password (over 20 characters). I think that this
> will take much longer than the life of the certificate (or its user) to
> crack. This password may also be recorded improperly or recorded on the
> same device as the key will reside. Could we consider reducing the size of
> the password?
>
> Remember that this only applies when the CA generates the key pair. If the
CA must for some reason do that, then it's reasonable to expect the CA to
secure it with a strong password.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

On Mon, May 14, 2018 at 1:10 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Yes, but as you correctly point out, this should be taken care of as part
> of the CAA-bis
> effort.  The original RFC had enough errors with respect to web
> certificates; I think
> it would be irresponsible to apply it to e-mail certificates right now
> without carefully
> considering the consequences.
>
> With CABF governance reform coming into effect on July 3rd, I'm cautiously
> optimistic
> we can start writing requirements for e-mail certificates and phasing out
> bad practices
> and phasing in good practices soon.  CAA for e-mail certificates is
> definitely worth
> considering as part of that process.
>

Isn't this an IETF issue? Shouldn't those who issue e-mail certificates
begin looking at the level of authentication provided for domains today?


>
> Slightly higher priority is making sure authenticated encryption modes are
> used with
> S/MIME, so people can't play silly games with CBC and harvested
> ciphertexts.
> Everything really needs to start transitioning away from CBC ... but I
> digress.
>

Indeed, it would be extremely unfortunate if the CABF tried to prioritize
the encryption modes over reliable certificate authentication, considering
that the encryption modes are not related to the certificates themselves.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

The Public Suffix List is a model for failure, not success - and I say that
as one of the two PSL maintainers. As to the remaining points, I think each
and every one of them doesn't actually hold up to scrutiny, and in fact,
the opposite conclusion is more in line with reality.

For example, if anti-spam systems applied per-account algorithms, then
there's an incentive for spammers to add themselves to the list. This is
demonstrable by some CAs using rate limiting at the PSL boundary, causing a
surge in additions to bypass those rate limits - similarly for various
browser security mechanisms.

Regarding the domain holder acting as behalf as the user - it's absolutely
true they can. The position advocated is like suggesting that 3.2.2.4.6 is
more secure than 3.2.2.4.2/.3 - the domain holder has primacy over the
website operator, and the postmaster has primacy over individual mailboxes.

On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Another approach could be to have something akin to the (non-ICANN)
> public suffix list, but for e-mail.  This would list e-mail domains
> where the e-mail address holders are not the subordinates (employees,
> students, etc.) of the domain holder.
>
> Such a list would have multiple uses (just like the public suffix list for
> domain delegations):
>
> 1. E-mails from these domains are not presumed to represent the opinion
>   of the domain holder in various contexts (including validation of TLS
>   certs against non-reserved e-mail addresses).
>
> 2. Anti-spam systems could apply a more per-account algorithm for
>   computing reputation scores.
>
> 3. S/MIME certificate issuance does not assume the domain holder can
>   act on behalf of the e-mail users.  Thus validation with
>   postmas...@example.net would not be valid for joesh...@example.net,
>   but on the other hand CAA records for example.net would not apply
>   to S/MIME (both if example.net was on the public e-mail domain list).
>
>
> On 14/05/2018 17:48, Neil Dunbar wrote:
>
>> But it also seems reasonable for organisations making CAA assertions to
>> know the scope of their stipulations before they make them, no?
>>
>> So, if in the case of Yahoo, they make the assertion “All of our web
>> certificates should come from DigiCert”, are they aware that they are also
>> making the statement “And all of our user mail accounts should only be
>> granted S/MIME certificates from DigiCert too”.
>>
>> Perhaps they are, perhaps not, but I’m willing to bet that a fair number
>> of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift
>> to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s
>> customers.
>>
>> Please note: I’m not opposed to CAA stipulations applying to S/MIME. I
>> would just want all participants in the PKI world to know what their
>> statements mean and how far they reach.
>>
>> Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be
>> restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean
>> ‘covering all possible forms of certificates’?
>>
>> Just a thought,
>>
>> Neil
>>
>> On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> It seems perfectly reasonable and desirable to require that CAs,
>>> regardless
>>> of the type of certificate they are issuing, respect CAA.
>>>
>>> If an email provider wishes to restrict some types of certificates (e.g.
>>> HTTPS) while allow others (e.g. S/MIME), this could be accomplished
>>> through
>>> additional expressions within the CAA syntax.
>>>
>>> However, it would be a long-lasting, and tragic mistake if CAA was
>>> presumed
>>> to 'only' apply to HTTPS - because it would make the same mistake of
>>> nameConstraints - namely, everything that is not expressly listed as
>>> permitted/restricted is implicitly permitted - rather than doing what
>>> security practitioners have long known is the safe and secure base -
>>> forbid
>>> unless expressly permitted (default-deny).
>>>
>>> In terms of order of concerns and constituents, the domain holders needs
>>> and security goals outweigh those of the notion of users 'owning' an
>>> email
>>> address.
>>>
>>> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> Just to say that looking at this from Europe, I don't see this feasible.

 Citizens getting their personal eIDAS-compliant certificate go through
 face-to-face validation and will give virtually any valid e-mail
 address to
 appear in their certificate.

 El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:

> I created a new issue suggesting that we add this requirement to
> Mozilla
> policy: https://github.com/mozilla/pkipolicy/issues/135
>
> On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via 

Re: question about DNS CAA and S/MIME certificates

[Ryan Sleevi via dev-security-policy]

On Mon, May 14, 2018 at 11:48 AM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> But it also seems reasonable for organisations making CAA assertions to
> know the scope of their stipulations before they make them, no?
>
> So, if in the case of Yahoo, they make the assertion “All of our web
> certificates should come from DigiCert”, are they aware that they are also
> making the statement “And all of our user mail accounts should only be
> granted S/MIME certificates from DigiCert too”.
>
> Perhaps they are, perhaps not, but I’m willing to bet that a fair number
> of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift
> to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s
> customers.
>

Sure, but Yahoo still remains the authority as to what the localpart of the
mailbox means - and thus absolutely should have that control over issuance,
and should be treated as such.


> Please note: I’m not opposed to CAA stipulations applying to S/MIME. I
> would just want all participants in the PKI world to know what their
> statements mean and how far they reach.
>
> Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be
> restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean
> ‘covering all possible forms of certificates’?
>

And that still moves to an 'insecure-by-default', by making every site
operator that has taken steps to actually restrict issuance not have those
wishes respected. This is the same problem as introducing new forms of
certificate validation methods - if it leaves insecure someone who has
taken steps to secure things, then it's making things worse.

That's why a solution to opt-out, rather than opt-in, is the right approach.

Today this is a "non-issue" because nothing is obligating CAs to respect
CAA, and thus they can (and are) doing the thing that helps them issue more
certificates (and, presumably, make more money) - but that doesn't
necessarily mean its the right thing. Yes, it means that introducing CAA
restrictions for S/MIME necessarily means there will need to be a way to
distinguish these cases, so that an organization could restrict e-mail vs
HTTPS - so CAs that wish to issue S/MIME should start working on these.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Doug Beattie via dev-security-policy]

I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean???
- We can’t permit user generated passwords (at least that is Tim's proposal, 
Wayne may not agree yet but he will when he reads this email)
- We can’t distribute both the password and PKCS#12 over the same channel, even 
if it's a secure channel like HTTPS

We have 2 choices for where the password is generated: CA or User

1) If we require CAs to generate the passwords and they can’t distribute the 
necessary information to the end user via the portal over TLS (because of the 
dual channel requirement), then that is a relatively large impact on us, and 
probably anyone else that supports PKCS#12 file formats.  If the channel is 
secure, do you need to use different channels? 


2) Trying to compute the entropy of a user generated password is  nearly 
impossible.  According to NIST Special Publication 800-63, a good 20 character 
password will have just 48 bits of entropy, and characters after that only add 
1 bite of entropy each.  User stink at generating Entropy (right Tim?) 

NIST Special Publication 800-63 of June 2004 (revision 2) suggested the 
following scheme to roughly estimate the entropy of human-generated passwords 
(Subsequent updates of this publication gave up trying to compute entropy for 
user generated passwords, and when they talk about entropy they talk about 20 
bits max):
•   The entropy of the first character is four bits;
•   The entropy of the next seven characters are two bits per character;
•   The ninth through the twentieth character has 1.5 bits of entropy per 
character;
•   Characters 21 and above have one bit of entropy per character.
•   A "bonus" of six bits is added if both upper case letters and 
non-alphabetic characters are used.
•   A "bonus" of six bits is added for passwords of length 1 through 19 
characters following an extensive dictionary check to ensure the password is 
not contained within a large dictionary. Passwords of 20 characters or more do 
not receive this bonus because it is assumed they are pass-phrases consisting 
of multiple dictionary words.

https://pages.nist.gov/800-63-3/ 

Some CAs are probably asking the user for a password during the request thus 
there is no need to distribute it later.  But, if the Applicant provides the 
password over HTTPS and then later the CA provides the PKCS#12 via download 
link and they obtain it via HTTPS, is that a single channel that they were both 
distributed over? 

I still object to not being able to use HTTPS for collection and/or 
distribution of the Password and the PKCS#12.  I also believe 112 bits of 
entropy is way too much for user generated password (assuming we want to 
continue supporting that option).

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Tim
> Hollebeek via dev-security-policy
> Sent: Monday, May 14, 2018 12:52 PM
> To: Ryan Hurst ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> For the record, I posted someone else's strength testing algorithm, and
> pointed out that it was bad   I personally don't think building strength 
> testing
> algorithms is hopeless, and I think good ones are very useful.  I tend to 
> agree
> with the current NIST recommendation, which is to primarily only consider
> length, along with things like history, dictionary words, and reuse.
> 
> But in this case, the public is at risk if the key is compromised, so I don't 
> trust a
> password chosen by an end user, no matter what strength function it may or
> may not pass.
> 
> Some form of random password of sufficient length, with the randomness
> coming from a CSPRNG, encoded into a more user friendly form, is the right
> answer here.
> 
> -Tim
> 
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of
> > bounces+Ryan
> > Hurst via dev-security-policy
> > Sent: Friday, May 4, 2018 5:19 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on
> > CA key generation to policy)
> >
> >
> > > True, but CAs can put technical constraints on that to limit the
> > > acceptable
> > passwords to a certain strength. (hopefully with a better
> > strength-testing algorithm than the example Tim gave earlier)
> >
> > Tim is the best of us -- this is hard to do well :)
> >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://clicktime.symantec.com/a/1/B4EQCI-
> >
> M91W3VFdrYnu8NKa6AWUA0Oca9gCvph6YNAo=?d=1AFyDzj7qs0LPt1qH7YZK
> > X7VDlKTG3u4_pF-smh1LdxQUjK6Fx2ySSFy5RdxazxX-
> >
> 

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Bruce via dev-security-policy]

On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> I think we have settled on the following resolution to this issue:
> 
> Add the following to section 5.2 (Forbidden and Required Practices):
> 
> CAs MUST NOT generate the key pairs for end-entity certificates that have
> > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or
> > anyExtendedKeyUsage.
> >
> > PKCS#12 files must employ an encryption key and algorithm that is
> > sufficiently strong to protect the key pair for its useful life based on
> > current guidelines published by a recognized standards body. PKCS#12 files
> > MUST be encrypted and signed; or, MUST have a password that exhibits at
> > least 112 bits of entropy, and the password MUST be transferred using a
> > different channel than the PKCS#12 file.
> >
> 
> Unless there is further discussion, I will include this language in the
> final version of the policy.
> 
> - Wayne

In one use case, the Subscriber can create their own password to start the 
enrollment process for the S/MIME certificate. The P12 is created, encrypted 
and sent to the Subscriber to be decrypted using the password. I think that 
asking the Subscriber to create a password with 112-bits entropy may create a 
very long password (over 20 characters). I think that this will take much 
longer than the life of the certificate (or its user) to crack. This password 
may also be recorded improperly or recorded on the same device as the key will 
reside. Could we consider reducing the size of the password?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: question about DNS CAA and S/MIME certificates

[Tim Hollebeek via dev-security-policy]

Yes, but as you correctly point out, this should be taken care of as part of 
the CAA-bis
effort.  The original RFC had enough errors with respect to web certificates; I 
think
it would be irresponsible to apply it to e-mail certificates right now without 
carefully
considering the consequences.

With CABF governance reform coming into effect on July 3rd, I'm cautiously 
optimistic
we can start writing requirements for e-mail certificates and phasing out bad 
practices
and phasing in good practices soon.  CAA for e-mail certificates is definitely 
worth
considering as part of that process.

Slightly higher priority is making sure authenticated encryption modes are used 
with
S/MIME, so people can't play silly games with CBC and harvested ciphertexts.
Everything really needs to start transitioning away from CBC ... but I digress.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Monday, May 14, 2018 11:39 AM
> To: Pedro Fuentes 
> Cc: mozilla-dev-security-policy 
> 
> Subject: Re: question about DNS CAA and S/MIME certificates
> 
> It seems perfectly reasonable and desirable to require that CAs, regardless of
> the type of certificate they are issuing, respect CAA.
> 
> If an email provider wishes to restrict some types of certificates (e.g.
> HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
> additional expressions within the CAA syntax.
> 
> However, it would be a long-lasting, and tragic mistake if CAA was presumed to
> 'only' apply to HTTPS - because it would make the same mistake of
> nameConstraints - namely, everything that is not expressly listed as
> permitted/restricted is implicitly permitted - rather than doing what security
> practitioners have long known is the safe and secure base - forbid unless
> expressly permitted (default-deny).
> 
> In terms of order of concerns and constituents, the domain holders needs and
> security goals outweigh those of the notion of users 'owning' an email 
> address.
> 
> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy < dev-
> security-pol...@lists.mozilla.org> wrote:
> 
> > Just to say that looking at this from Europe, I don't see this feasible.
> >
> > Citizens getting their personal eIDAS-compliant certificate go through
> > face-to-face validation and will give virtually any valid e-mail
> > address to appear in their certificate.
> >
> > El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:
> > > I created a new issue suggesting that we add this requirement to
> > > Mozilla
> > > policy: https://github.com/mozilla/pkipolicy/issues/135
> > >
> > > On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy
> > > > < dev-security-policy@lists.mozilla.org> wrote:
> > > >
> > > > > Hello,
> > > > > this question is somewhat outside the current Baseline
> > > > > Requirements,
> > > > but...
> > > > >
> > > > > wouldn't it be normal for the same CAA rules for server
> > > > > certificates
> > to
> > > > > also apply to client certificates when the email address is for
> > > > > a
> > domain
> > > > > that already has a valid CAA policy published in DNS?
> > > > >
> > > > >
> > > > > RFC 6844 doesn't seem to make any distinction between server and
> > S/MIME
> > > > > client certificates, it combines them together by referring to
> > > > certificates
> > > > > "for that domain" as a whole.
> > > > >
> > > > >
> > > > > i tested this last night - i obtained an email certificate from
> > > > > one
> > of
> > > > the
> > > > > CAs participating here (not for this exact address though) and
> > > > > it was happily issued even if CAA records authenticated by
> > > > > DNSSEC do not
> > allow
> > > > > their CA to issue for this domain.
> > > > >
> > > > > Now, this is technically not a mis-issuance because it was a
> > > > > proper email-validated address and their CPS says that CAA is
> > > > > only checked
> > for
> > > > > server-type certificates. It doesn't say anything about CAA
> > validation
> > > > for
> > > > > such client certificates.
> > > > >
> > > > > I got in touch with them and they seemed equally surprised by
> > > > > such intended use case for CAA, so my second question is: is
> > > > > anyone
> > actually
> > > > > checking CAA records for client certificates where an email
> > > > > address
> > is
> > > > > included in the certificate subject info and the EKU includes
> > > > > Secure
> > > > Email?
> > > > >
> > > > >
> > > > > Or is CAA usually checked only for server-type certificates,
> > > > > even if
> > RFC
> > > > > 6844 refers to certificates "for that domain" as a whole?
> > > > >
> > > >
> > > > CAs are 

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

[Tim Hollebeek via dev-security-policy]

For the record, I posted someone else's strength testing algorithm, and pointed
out that it was bad   I personally don't think building strength testing 
algorithms 
is hopeless, and I think good ones are very useful.  I tend to agree with the 
current 
NIST recommendation, which is to primarily only consider length, along with 
things 
like history, dictionary words, and reuse.

But in this case, the public is at risk if the key is compromised, so I don't 
trust a 
password chosen by an end user, no matter what strength function it may or may 
not pass.

Some form of random password of sufficient length, with the randomness coming
from a CSPRNG, encoded into a more user friendly form, is the right answer here.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Ryan
> Hurst via dev-security-policy
> Sent: Friday, May 4, 2018 5:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key
> generation to policy)
> 
> 
> > True, but CAs can put technical constraints on that to limit the acceptable
> passwords to a certain strength. (hopefully with a better strength-testing
> algorithm than the example Tim gave earlier)
> 
> Tim is the best of us -- this is hard to do well :)
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/B4EQCI-
> M91W3VFdrYnu8NKa6AWUA0Oca9gCvph6YNAo=?d=1AFyDzj7qs0LPt1qH7YZK
> X7VDlKTG3u4_pF-smh1LdxQUjK6Fx2ySSFy5RdxazxX-
> o23v3NFfmxRdpLUwPqiW6yozAgZPzuSbInOcX3x3V3ANyskgECX5k4aeBDO0z1u
> RHJpH-
> Wb5WOBjb0n16kco9wf4jRlCIO7HgEH4pMHjx4H_POUivn493OPB7U9RX8BArU
> 5U87OFuHYndlG0UK-XvQOKqKu6t_3fatFfevp7IT8Jzm4Ze-
> xwk8jgsytRsxvWQ561mB9wFaxsYkiFLZMBHmsNDACgJKZxHouitR-aXhUbxF-
> fKeFXogKbfDCYiYLqHOe5i8KyS8AzFNsUaZTDGJisXeUJbui5n9H3tF5berZe0DuntP
> V7a9yad9-
> haeyu7NspHh92Niu71JNcWZks3gkKolxwuU9vUfZCdfiIIhMHniPOMkCkMl0ooM
> gbRFl0gnAgmiNcKuIizRC9Z35_snt4pKSXAU12MQLeTdYFZMGmKYEDTvkB2L_So
> 3AZHYfUXATSUeQQlo1zSRKZ5Mapw%3D%3D=https%3A%2F%2Flists.mozilla
> .org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Jakob Bohm via dev-security-policy]

Another approach could be to have something akin to the (non-ICANN)
public suffix list, but for e-mail.  This would list e-mail domains
where the e-mail address holders are not the subordinates (employees,
students, etc.) of the domain holder.

Such a list would have multiple uses (just like the public suffix list 
for domain delegations):


1. E-mails from these domains are not presumed to represent the opinion
  of the domain holder in various contexts (including validation of TLS
  certs against non-reserved e-mail addresses).

2. Anti-spam systems could apply a more per-account algorithm for
  computing reputation scores.

3. S/MIME certificate issuance does not assume the domain holder can
  act on behalf of the e-mail users.  Thus validation with
  postmas...@example.net would not be valid for joesh...@example.net,
  but on the other hand CAA records for example.net would not apply
  to S/MIME (both if example.net was on the public e-mail domain list).


On 14/05/2018 17:48, Neil Dunbar wrote:

But it also seems reasonable for organisations making CAA assertions to know 
the scope of their stipulations before they make them, no?

So, if in the case of Yahoo, they make the assertion “All of our web 
certificates should come from DigiCert”, are they aware that they are also 
making the statement “And all of our user mail accounts should only be granted 
S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number of 
Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift to 
CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s 
customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would 
just want all participants in the PKI world to know what their statements mean 
and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be 
restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean 
‘covering all possible forms of certificates’?

Just a thought,

Neil


On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy 
 wrote:

It seems perfectly reasonable and desirable to require that CAs, regardless
of the type of certificate they are issuing, respect CAA.

If an email provider wishes to restrict some types of certificates (e.g.
HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
additional expressions within the CAA syntax.

However, it would be a long-lasting, and tragic mistake if CAA was presumed
to 'only' apply to HTTPS - because it would make the same mistake of
nameConstraints - namely, everything that is not expressly listed as
permitted/restricted is implicitly permitted - rather than doing what
security practitioners have long known is the safe and secure base - forbid
unless expressly permitted (default-deny).

In terms of order of concerns and constituents, the domain holders needs
and security goals outweigh those of the notion of users 'owning' an email
address.

On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Just to say that looking at this from Europe, I don't see this feasible.

Citizens getting their personal eIDAS-compliant certificate go through
face-to-face validation and will give virtually any valid e-mail address to
appear in their certificate.

El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:

I created a new issue suggesting that we add this requirement to Mozilla
policy: https://github.com/mozilla/pkipolicy/issues/135

On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Hello,
this question is somewhat outside the current Baseline Requirements,

but...


wouldn't it be normal for the same CAA rules for server certificates

to

also apply to client certificates when the email address is for a

domain

that already has a valid CAA policy published in DNS?


RFC 6844 doesn't seem to make any distinction between server and

S/MIME

client certificates, it combines them together by referring to

certificates

"for that domain" as a whole.


i tested this last night - i obtained an email certificate from one

of

the

CAs participating here (not for this exact address though) and it was
happily issued even if CAA records authenticated by DNSSEC do not

allow

their CA to issue for this domain.

Now, this is technically not a mis-issuance because it was a proper
email-validated address and their CPS says that CAA is only checked

for

server-type certificates. It doesn't say anything about CAA

validation

for

such client certificates.

I got in touch with them and they seemed equally surprised by such
intended use case for CAA, so my second question is: is anyone

actually

Re: question about DNS CAA and S/MIME certificates

[Neil Dunbar via dev-security-policy]

But it also seems reasonable for organisations making CAA assertions to know 
the scope of their stipulations before they make them, no?

So, if in the case of Yahoo, they make the assertion “All of our web 
certificates should come from DigiCert”, are they aware that they are also 
making the statement “And all of our user mail accounts should only be granted 
S/MIME certificates from DigiCert too”.

Perhaps they are, perhaps not, but I’m willing to bet that a fair number of 
Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift to 
CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s 
customers.

Please note: I’m not opposed to CAA stipulations applying to S/MIME. I would 
just want all participants in the PKI world to know what their statements mean 
and how far they reach.

Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be 
restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean 
‘covering all possible forms of certificates’?

Just a thought,

Neil

> On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> It seems perfectly reasonable and desirable to require that CAs, regardless
> of the type of certificate they are issuing, respect CAA.
> 
> If an email provider wishes to restrict some types of certificates (e.g.
> HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
> additional expressions within the CAA syntax.
> 
> However, it would be a long-lasting, and tragic mistake if CAA was presumed
> to 'only' apply to HTTPS - because it would make the same mistake of
> nameConstraints - namely, everything that is not expressly listed as
> permitted/restricted is implicitly permitted - rather than doing what
> security practitioners have long known is the safe and secure base - forbid
> unless expressly permitted (default-deny).
> 
> In terms of order of concerns and constituents, the domain holders needs
> and security goals outweigh those of the notion of users 'owning' an email
> address.
> 
> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Just to say that looking at this from Europe, I don't see this feasible.
>> 
>> Citizens getting their personal eIDAS-compliant certificate go through
>> face-to-face validation and will give virtually any valid e-mail address to
>> appear in their certificate.
>> 
>> El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:
>>> I created a new issue suggesting that we add this requirement to Mozilla
>>> policy: https://github.com/mozilla/pkipolicy/issues/135
>>> 
>>> On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
 On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy <
 dev-security-policy@lists.mozilla.org> wrote:
 
> Hello,
> this question is somewhat outside the current Baseline Requirements,
 but...
> 
> wouldn't it be normal for the same CAA rules for server certificates
>> to
> also apply to client certificates when the email address is for a
>> domain
> that already has a valid CAA policy published in DNS?
> 
> 
> RFC 6844 doesn't seem to make any distinction between server and
>> S/MIME
> client certificates, it combines them together by referring to
 certificates
> "for that domain" as a whole.
> 
> 
> i tested this last night - i obtained an email certificate from one
>> of
 the
> CAs participating here (not for this exact address though) and it was
> happily issued even if CAA records authenticated by DNSSEC do not
>> allow
> their CA to issue for this domain.
> 
> Now, this is technically not a mis-issuance because it was a proper
> email-validated address and their CPS says that CAA is only checked
>> for
> server-type certificates. It doesn't say anything about CAA
>> validation
 for
> such client certificates.
> 
> I got in touch with them and they seemed equally surprised by such
> intended use case for CAA, so my second question is: is anyone
>> actually
> checking CAA records for client certificates where an email address
>> is
> included in the certificate subject info and the EKU includes Secure
 Email?
> 
> 
> Or is CAA usually checked only for server-type certificates, even if
>> RFC
> 6844 refers to certificates "for that domain" as a whole?
> 
 
 CAs are generally only checking CAA when they're required to in order
>> to be
 trusted.
 
 Right now, CAs are only required to check CAA for server-type
>> certificates
 (by virtue of the Baseline Requirements Section 3.2.2.8).
 CAs are not presently being required to check CAA for e-mail. They
>> can, but
 they are required to do it, so they are unlikely to do it.

Re: question about DNS CAA and S/MIME certificates

[Adrian R. via dev-security-policy]

Pedro Fuentes wrote:
> Just to say that looking at this from Europe, I don't see this feasible.
>  
> Citizens getting their personal eIDAS-compliant certificate go through 
> face-to-face validation and will give virtually any valid e-mail address to 
> appear in their certificate. 
> 

Then that is a problem with eIDAS certificates not with CAA - eIDAS 
certificates identify the person, and (assuming that email validation is even 
performed) that they have temporary control of an email address, but if the 
email is on a corporate domain this does nothing to address the issuance 
against policies of that company.


>From this point of view, an email address should not even be part of an eIDAS 
>certificate (and thus CAA would not apply), but an email is usually included 
>for convenience. (why?)

This is because the eIDAS regulation 910/2014 does not contain the words 
"e-mail", "email" or "message" at all. (!!!)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014R0910

As it is now, it is even possible to use and 'verify control' of anonymous 
disposable email services (e.g. mailinator) for an eIDAS certificate because 
the CA TSP doesn't care about the email or domain policies.


As is noted on the GitHub issue, many providers of free email services have 
been careful to avoid deploying CAA for the domain names used by their email 
users, but some have deployed restrictive CAA policies that might affect their 
users if CAA checking is done (e.g. Yahoo, Yandex).



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

Re: Unrevoked/unexpired certificate with Debian Weak Key

[Rob Stradling via dev-security-policy]

On 14/05/18 11:39, Jakob Bohm via dev-security-policy wrote:

On 14/05/2018 10:42, Hanno Böck wrote:

Hi,

Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.

A few days ago I did a re-check of the CT logs for vulnerable keys.

I found one unexpired, unrevoked certificate issued by a CA called
"QuoVadis". I reported it and it's been revoked, they told me they'll
check their systems why this certificate issuance wasn't blocked.

https://crt.sh/?id=308235142

I also found an unrevoked Wosign cert that I had already reported last
year. The abuse contact of wosign bounces mails.

(My check was semi-thorough, I didn't have access to all the possible
key combinations that could be generated with the Debian bug. There may
be more certs in the logs.)



You could try the openssl-blacklist package distributed by Debian in
both source and prepackaged form.  If you use the packaged form, be sure
to include the openssl-blacklist-extra package which contains the lists
of RSA-4096 and RSA-512 keys.

Their included checking program (in the .diff file) is in Python.

URL: http://ftp.de.debian.org/debian/pool/main/o/openssl-blacklist/


Today I've added a Debian weak key check feature to crt.sh.  I augmented 
Debian's original blacklists with some other blacklists I generated 
~10yrs ago for a few less common key sizes [1].


I'm currently running the check against all of the certs on the crt.sh 
DB.  I'll report back once this has completed.



[1] https://secure.comodo.com/debian_weak_keys/


--
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

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

Re: Unrevoked/unexpired certificate with Debian Weak Key

[Jakob Bohm via dev-security-policy]

On 14/05/2018 10:42, Hanno Böck wrote:

Hi,

Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.

A few days ago I did a re-check of the CT logs for vulnerable keys.

I found one unexpired, unrevoked certificate issued by a CA called
"QuoVadis". I reported it and it's been revoked, they told me they'll
check their systems why this certificate issuance wasn't blocked.

https://crt.sh/?id=308235142

I also found an unrevoked Wosign cert that I had already reported last
year. The abuse contact of wosign bounces mails.

(My check was semi-thorough, I didn't have access to all the possible
key combinations that could be generated with the Debian bug. There may
be more certs in the logs.)



You could try the openssl-blacklist package distributed by Debian in
both source and prepackaged form.  If you use the packaged form, be sure
to include the openssl-blacklist-extra package which contains the lists
of RSA-4096 and RSA-512 keys.

Their included checking program (in the .diff file) is in Python.

URL: http://ftp.de.debian.org/debian/pool/main/o/openssl-blacklist/


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

Unrevoked/unexpired certificate with Debian Weak Key

[Hanno Böck via dev-security-policy]

Hi,

Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.

A few days ago I did a re-check of the CT logs for vulnerable keys.

I found one unexpired, unrevoked certificate issued by a CA called
"QuoVadis". I reported it and it's been revoked, they told me they'll
check their systems why this certificate issuance wasn't blocked.

https://crt.sh/?id=308235142

I also found an unrevoked Wosign cert that I had already reported last
year. The abuse contact of wosign bounces mails.

(My check was semi-thorough, I didn't have access to all the possible
key combinations that could be generated with the Debian bug. There may
be more certs in the logs.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: question about DNS CAA and S/MIME certificates

[Pedro Fuentes via dev-security-policy]

Just to say that looking at this from Europe, I don't see this feasible.
 
Citizens getting their personal eIDAS-compliant certificate go through 
face-to-face validation and will give virtually any valid e-mail address to 
appear in their certificate. 

El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer  escribió:
> I created a new issue suggesting that we add this requirement to Mozilla
> policy: https://github.com/mozilla/pkipolicy/issues/135
> 
> On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Hello,
> > > this question is somewhat outside the current Baseline Requirements,
> > but...
> > >
> > > wouldn't it be normal for the same CAA rules for server certificates to
> > > also apply to client certificates when the email address is for a domain
> > > that already has a valid CAA policy published in DNS?
> > >
> > >
> > > RFC 6844 doesn't seem to make any distinction between server and S/MIME
> > > client certificates, it combines them together by referring to
> > certificates
> > > "for that domain" as a whole.
> > >
> > >
> > > i tested this last night - i obtained an email certificate from one of
> > the
> > > CAs participating here (not for this exact address though) and it was
> > > happily issued even if CAA records authenticated by DNSSEC do not allow
> > > their CA to issue for this domain.
> > >
> > > Now, this is technically not a mis-issuance because it was a proper
> > > email-validated address and their CPS says that CAA is only checked for
> > > server-type certificates. It doesn't say anything about CAA validation
> > for
> > > such client certificates.
> > >
> > > I got in touch with them and they seemed equally surprised by such
> > > intended use case for CAA, so my second question is: is anyone actually
> > > checking CAA records for client certificates where an email address is
> > > included in the certificate subject info and the EKU includes Secure
> > Email?
> > >
> > >
> > > Or is CAA usually checked only for server-type certificates, even if RFC
> > > 6844 refers to certificates "for that domain" as a whole?
> > >
> >
> > CAs are generally only checking CAA when they're required to in order to be
> > trusted.
> >
> > Right now, CAs are only required to check CAA for server-type certificates
> > (by virtue of the Baseline Requirements Section 3.2.2.8).
> > CAs are not presently being required to check CAA for e-mail. They can, but
> > they are required to do it, so they are unlikely to do it.
> > ___
> > 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