Re: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

2017-10-07 Thread Peter Bowen via dev-security-policy 
On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via
dev-security-policy  wrote:
> Here is the new version of the draft updated according to the discussion on
> mozilla-dev-security list.

Given that RFC 5914 already defines a TrustAnchorList and
TrustAnchorInfo object and that the Trust Anchor List object is
explicitly contemplated as being included in a signed CMS message,
would it not make more sense to start from 5914 and define new
extensions encode constraints not currently defined?

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

Re: SecureTrust

2017-10-07 Thread David E. Ross via dev-security-policy 
On 10/7/2017 1:57 PM, Peter Bowen wrote:
> On Sat, Oct 7, 2017 at 12:23 PM, David E. Ross via dev-security-policy
>  wrote:
>> Somehow, I recall there had been a problem with the SecureTrust
>> Corporation certification authority.  It was either a problem with one
>> or more of the root certificates or with the way the certification
>> authority was operating.  Can anyone refresh my memory?
> 
> David,
> 
> I can't refresh your memory directly, but I suspect this was a long time ago.
> 
> According to the CCADB, the SecureTrust roots are owned by TrustWave
> and are currently ultimately controlled by the Singapore Minister for
> Finance.
> 
>>From what I can find online, SecureTrust was acquired by
> AmbironTrustWave in 2007.[1]   AmbironTrustWave later became
> TrustWave.[2] In 2015, SingTel acquired TrustWave.[3] . The SingTel
> annual report states that Temasek Holdings has an interest of
> approximately 52% in Singtel and that the Singapore Minister for
> Finance is the owner of Temasek.[4]
> 
> Assuming it was SecureTrust that had issues, that would have been at
> least 10 years ago.
> 
> Thanks,
> Peter
> 
> [1] 
> https://news.thomasnet.com/companystory/ambirontrustwave-acquires-securetrust-corporation-524708
> [2] 
> https://www.scmagazine.com/company-news-mazu-networks-names-conklin-vp-of-marketing/article/554054/
> [3] 
> http://www.eweek.com/security/singtel-completes-trustwave-acquisition-for-770-million
> [4] 
> https://www.singtel.com/content/dam/singtel/investorRelations/annualReports/2017/singtelar17-full-AR.pdf
> 

I did a search in bugzilla.mozilla.org On "SecureTrust".  The issue
about which I was thinking is covered in bugs #724942 and #724929 and
affected root certificate Trustwave SecureTrust CA.  Apparently, that
root no longer exists in the NSS database and does not appear on the
"Mozilla Included CA Certificate List" Web page.

See:



-- 
David E. Ross


By allowing employers to eliminate coverage for birth control
from their insurance plans, President Trump has guaranteed there
will be an increase in the demand for abortions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SecureTrust

2017-10-07 Thread Peter Bowen via dev-security-policy 
On Sat, Oct 7, 2017 at 12:23 PM, David E. Ross via dev-security-policy
 wrote:
> Somehow, I recall there had been a problem with the SecureTrust
> Corporation certification authority.  It was either a problem with one
> or more of the root certificates or with the way the certification
> authority was operating.  Can anyone refresh my memory?

David,

I can't refresh your memory directly, but I suspect this was a long time ago.

According to the CCADB, the SecureTrust roots are owned by TrustWave
and are currently ultimately controlled by the Singapore Minister for
Finance.

>From what I can find online, SecureTrust was acquired by
AmbironTrustWave in 2007.[1]   AmbironTrustWave later became
TrustWave.[2] In 2015, SingTel acquired TrustWave.[3] . The SingTel
annual report states that Temasek Holdings has an interest of
approximately 52% in Singtel and that the Singapore Minister for
Finance is the owner of Temasek.[4]

Assuming it was SecureTrust that had issues, that would have been at
least 10 years ago.

Thanks,
Peter

[1] 
https://news.thomasnet.com/companystory/ambirontrustwave-acquires-securetrust-corporation-524708
[2] 
https://www.scmagazine.com/company-news-mazu-networks-names-conklin-vp-of-marketing/article/554054/
[3] 
http://www.eweek.com/security/singtel-completes-trustwave-acquisition-for-770-million
[4] 
https://www.singtel.com/content/dam/singtel/investorRelations/annualReports/2017/singtelar17-full-AR.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SecureTrust

2017-10-07 Thread David E. Ross via dev-security-policy 
Somehow, I recall there had been a problem with the SecureTrust
Corporation certification authority.  It was either a problem with one
or more of the root certificates or with the way the certification
authority was operating.  Can anyone refresh my memory?

-- 
David E. Ross


By allowing employers to eliminate coverage for birth control
from their insurance plans, President Trump has guaranteed there
will be an increase in the demand for abortions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

2017-10-07 Thread Dmitry Belyavsky via dev-security-policy 
Dear Nicos,

Sorry for the delay with my response.

On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos 
wrote:

> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky 
> wrote:
> > Dear Nikos
> >
> > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <
> n...@gnutls.org>
> > wrote:
> >>
> >>
> >> 4. How do you handle extensions to this format?
> >>
> >> Overall, why not use X.509 extensions to store such additional
> >> constraints? We already (in the p11-kit trust store in Fedora/RHEL
> >> systems) use the notion of stapled extensions to limit certificates
> >> [0, 1] and seems quite a flexible approach. Have you considered that
> >> path?
> >>
> >> regards,
> >> Nikos
> >>
> >> [0].
> >> https://p11-glue.freedesktop.org/doc/storing-trust-policy/
> storing-trust-model.html
> >> [1].
> >> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-
> certificates.html
> > I've looked through the specification. It's OK for me, but I do not get
> > whether the attached extensions are crypto-protected.
>
> No, as these values are inserted by the administrator of the system,
> or us (the distributor of the software), we didn't feel we needed the
> introduction of additional PKI.
>

Well, the specification I suggest should allow applying CLPs issued by
major vendors (Mozilla etc).
For this purposes the CLPs should be validable => signed.



> How do you see the infrastructure on the
> draft-belyavskiy-certificate-limitation-policy? Who do you envision
> signing these structures? (I assume that distribution of data will be
> done by software distributors?)
>

I anticipate some ways to distribute CLPs.

1. Major vendor-issued CLPs are distributed either by vendors or by OS
vendors
(similar to, e.g., ca-certificates package in Debian). In this case we
should have
certificates to sign these CLPs distributed together with these bundles.

2. App-specific CLPs may include the key as a part of the application
bundle.
So CLP is distributed via normal app-distributing channel.

3. Locally created CLPs. This is the case more or less similar to the
p11-glue solution,
if I understand it correctly.

Various protocols, such as TAMP (RFC 5934) can be used for transport the
CLPs too.


>
> >> 4. How do you handle extensions to this format?
> >>
> > Simillary to CRL. Do you have ideas of the extensions?
>
> One problem with that is the fact that the existing CRL extensions are
> about extending attributes of the CRL, rather than adding/removing
> attributes to the certificate in question.
>

For this purposes I implied that the limitations are provided not by
extensions,
but as SEQUENCE of limitations related to the certificates.

Was I wrong in the ASN1 scheme in the current version of my draft?



> To bring the stapled extensions to your proposal, you'd need the
> Extensions and Extension fields from RFC5280, and
> add into limitedCertificates structure (I'll split it on the example
> below for clarity) the following field.
>
> LimitedCertificates  ::=   SEQUENCE OF LimitedCertificate
>
> LimitedCertificate ::= SEQUENCE {
> userCertificate CertificateSerialNumber,
> certificateIssuer   Name,
> limitationDate  Time,
> limitationPropagation   Enum,
> fingerprint SEQUENCE {
> fingerprintAlgorithm AlgorithmIdentifier,
> fingerprintValue OCTET STRING
>  } OPTIONAL,
> limitations  SEQUENCE,
>} OPTIONAL,
>  };
>
>
> stapledExtensions Extensions; <- NEW
> }
>

Sorry, I do not get the difference between the purposes of the field
'limitations'
and 'stapledExtensions'.


> Another difference between this profile and the p11-kit one, is that
> the extensions/revocation here is done on the certificate, while in
> p11-kit is done on the public key. Both approaches have pros and cons.
>

Sure.


>
> Another question. I also noticed the fingerprint field above. Is that
> to distinguish between same CAs with different keys? In that case
> using the SubjectPublicKeyIdentifier may be sufficient, and more
> natural as this is how certificates with matching DNs/serials are
> distinguished.
>

Do you mean Subject Key Identifier (RFC 5280, 4.2.1.2)?
Yes, I agree and I'll update the draft.

I introduced the fingerprint field to distinguish bogus certs from the
valid ones,
but I think the SKI will be OK for this purpose.

Thank you!

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

Re: Incident Report format

2017-10-07 Thread Gervase Markham via dev-security-policy 
On 29/09/17 20:08, Jakob Bohm wrote:
> 1. Title should also reflect that this is now about various kinds of
>   incidents.

The page is now called:
https://wiki.mozilla.org/CA/Responding_To_An_Incident

I've also made the other changes. Thank you for your feedback.

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

Re: Issuing and using SHA-1 OCSP signing certificates

2017-10-07 Thread Gervase Markham via dev-security-policy 
On 06/10/17 19:41, Doug Beattie wrote:
> We could provide you with the non-SSL SHA-1 CAs and have them added to OneCRL 
> as long as we're sure that would not impact their use for client 
> authentication and secure email.  Would that suffice?

Yes. File a Bugzilla bug.

While we don't have a mandated timescale for this, please migrate new
issuance to appropriately-constrained intermediates if you have not done
so already.

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

Re: Issuing and using SHA-1 OCSP signing certificates

2017-10-07 Thread Gervase Markham via dev-security-policy 
On 04/10/17 23:38, Nick Lamb wrote:
> However if I understand the situation correctly, this situation is
> already very low risk anyway with no reasonable expectation that it
> could be exploited against a competent SSL/TLS client which for some
> reason still accepts SHA1 and of course no risk for e.g. modern
> Firefox which doesn't accepts SHA1 anyway. If I haven't understood
> (please anyone jump in) then my assessment may be utterly wrong.

Of course, this is an argument for ceasing to regulate SHA-1 issuance at
all, because no modern browser accepts it, so why bother? But I don't
think we are quite ready to go there; it does have the useful secondary
effect of going some way to force obsolete software (like old XP) off
the Internet.

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