On 07/10/2017 20:37, Dmitry Belyavsky wrote:
Dear Nicos,
Sorry for the delay with my response.
On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <[email protected]>
wrote:
On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <[email protected]>
wrote:
Dear Nikos
On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <
[email protected]>
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.
The SKI provides no strong cryptographic binding to the public key or
any other part of the certificate, only an administrative binding which
can be faked.
Providing either the full trusted certificate or a very strong hash of
it's DER form (a so-called "fingerprint") would be needed to make a
trust list meaningful for security purposes. For practical usability
and maximum security, include the full certificate.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
