Re: [cabfpub] Update about S/MIME Charter
Thanks for checking, Tim. The changes y'all approved are integrated, and so I think https://github.com/cabforum/documents/pull/167 reflects all feedback to date. On Fri, Apr 24, 2020 at 4:43 PM Tim Hollebeek wrote: > Ryan: Any other issues, or shall we get a ballot out for discussion? > > > > (of course, discussion can continue during the ballot discussion period as > well) > > > > -Tim > > > > *From:* Public *On Behalf Of *Tim Hollebeek > via Public > *Sent:* Wednesday, April 22, 2020 4:24 PM > *To:* Ryan Sleevi > *Cc:* CABforum1 > *Subject:* Re: [cabfpub] Update about S/MIME Charter > > > > I’m fine with this. Looks like Clint and Wayne are too (just repeating > this here for those who don’t follow the link). > > > > -Tim > > > > *From:* Ryan Sleevi > *Sent:* Wednesday, April 22, 2020 3:42 PM > *To:* Tim Hollebeek > *Cc:* CABforum1 > *Subject:* Re: [cabfpub] Update about S/MIME Charter > > > > https://github.com/sleevi/cabforum-docs/pull/17 so that you can comment > and make additional modifications/edits. > > > > In prepping this, I also spotted an issue with the CABF Bylaws that I'll > feed back to Dimitris' ballot > > > > On Wed, Apr 22, 2020 at 3:27 PM Tim Hollebeek > wrote: > > I think some people might have objections to “includes, but not limited > to…” language, but I don’t. I think it’s sometimes helpful when drafting > intentionally broad criteria like this to make it explicitly clear that > common cases like “WebTrust for CAs” or “ETSI …” is indeed “relevant to the > issuance of S/MIME certificates”. That could really cut down on the amount > of confusion about who does or does not qualify for membership, and give > members clarity when voting for the charter about who is and isn’t allowed > to participate, while also potentially allowing participation by others > with less common audit schemes. > > > > That’s just a more verbose than usual way of me saying that yes, I would > appreciate draft text along the lines you suggest. > > > > -Tim > > > > *From:* Ryan Sleevi > *Sent:* Wednesday, April 22, 2020 3:15 PM > *To:* Tim Hollebeek > *Cc:* CABforum1 > *Subject:* Re: [cabfpub] Update about S/MIME Charter > > > > See my earliest comments on the first draft about this - > https://cabforum.org/pipermail/public/2019-January/014517.html shows the > suggested edit and points to > https://cabforum.org/pipermail/public/2019-January/014521.html > > > > Finally, regarding membership criteria, I'm curious whether it's necessary > to consider WebTrust for CAs / ETSI at all. For work like this, would it > make sense to merely specify the requirements for a CA as one that is > trusted for and actively issues S/MIME certificates that are accepted by a > Certificate Consumer. This seems to be widely inclusive and can be iterated > upon if/when improved criteria are developed, if appropriate. > There's also a bootstrapping issue for membership, in that until we know > who the accepted Certificate Consumers are, no CA can join as a Certificate > Issuer. I'm curious whether it makes sense to explicitly bootstrap this in > the charter or how we'd like to tackle this. > > > > In the current incarnation, it's to simply remove the scheme requirement, > as follows: > > > > A Certificate Issuer eligible for voting membership in the SMCWG MUST have > a publicly-available audit report or attestation statement in accordance > with a publicly-available audit or assessment scheme relevant to the > issuance of S/MIME certificates. This includes, but is not limited to, ...: > > > > Happy to propose draft text to this effect, if this is something that > you're open to addressing. > > > > On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek > wrote: > > Unintentional, and thanks for calling it out. I don’t have strong > feelings on the issue and agree broader participation is a useful goal, > especially before requirements exist. Certificate Consumers can, and I > expect will, have their own opinions on what audits are appropriate and > necessary once they adopt the requirements. Do you have a proposed fix? > > > > -Tim > > > > *From:* Ryan Sleevi > *Sent:* Sunday, April 19, 2020 4:41 PM > *To:* Tim Hollebeek ; CABforum1 < > public@cabforum.org> > *Subject:* Re: [cabfpub] Update about S/MIME Charter > > > > Looking through the resolved and unresolved aspects, the lack of feedback > from you meant we still have one unaddressed matter in the draft: > > > > https://github.com/cabforum/documents/pull/167/files#r392389077 > > - The proposed draft charter forbi
Re: [cabfpub] Update about S/MIME Charter
Ryan: Any other issues, or shall we get a ballot out for discussion? (of course, discussion can continue during the ballot discussion period as well) -Tim From: Public On Behalf Of Tim Hollebeek via Public Sent: Wednesday, April 22, 2020 4:24 PM To: Ryan Sleevi Cc: CABforum1 Subject: Re: [cabfpub] Update about S/MIME Charter I’m fine with this. Looks like Clint and Wayne are too (just repeating this here for those who don’t follow the link). -Tim From: Ryan Sleevi mailto:sle...@google.com> > Sent: Wednesday, April 22, 2020 3:42 PM To: Tim Hollebeek mailto:tim.holleb...@digicert.com> > Cc: CABforum1 mailto:public@cabforum.org> > Subject: Re: [cabfpub] Update about S/MIME Charter https://github.com/sleevi/cabforum-docs/pull/17 so that you can comment and make additional modifications/edits. In prepping this, I also spotted an issue with the CABF Bylaws that I'll feed back to Dimitris' ballot On Wed, Apr 22, 2020 at 3:27 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: I think some people might have objections to “includes, but not limited to…” language, but I don’t. I think it’s sometimes helpful when drafting intentionally broad criteria like this to make it explicitly clear that common cases like “WebTrust for CAs” or “ETSI …” is indeed “relevant to the issuance of S/MIME certificates”. That could really cut down on the amount of confusion about who does or does not qualify for membership, and give members clarity when voting for the charter about who is and isn’t allowed to participate, while also potentially allowing participation by others with less common audit schemes. That’s just a more verbose than usual way of me saying that yes, I would appreciate draft text along the lines you suggest. -Tim From: Ryan Sleevi mailto:sle...@google.com> > Sent: Wednesday, April 22, 2020 3:15 PM To: Tim Hollebeek mailto:tim.holleb...@digicert.com> > Cc: CABforum1 mailto:public@cabforum.org> > Subject: Re: [cabfpub] Update about S/MIME Charter See my earliest comments on the first draft about this - https://cabforum.org/pipermail/public/2019-January/014517.html shows the suggested edit and points to https://cabforum.org/pipermail/public/2019-January/014521.html Finally, regarding membership criteria, I'm curious whether it's necessary to consider WebTrust for CAs / ETSI at all. For work like this, would it make sense to merely specify the requirements for a CA as one that is trusted for and actively issues S/MIME certificates that are accepted by a Certificate Consumer. This seems to be widely inclusive and can be iterated upon if/when improved criteria are developed, if appropriate. There's also a bootstrapping issue for membership, in that until we know who the accepted Certificate Consumers are, no CA can join as a Certificate Issuer. I'm curious whether it makes sense to explicitly bootstrap this in the charter or how we'd like to tackle this. In the current incarnation, it's to simply remove the scheme requirement, as follows: A Certificate Issuer eligible for voting membership in the SMCWG MUST have a publicly-available audit report or attestation statement in accordance with a publicly-available audit or assessment scheme relevant to the issuance of S/MIME certificates. This includes, but is not limited to, ...: Happy to propose draft text to this effect, if this is something that you're open to addressing. On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: Unintentional, and thanks for calling it out. I don’t have strong feelings on the issue and agree broader participation is a useful goal, especially before requirements exist. Certificate Consumers can, and I expect will, have their own opinions on what audits are appropriate and necessary once they adopt the requirements. Do you have a proposed fix? -Tim From: Ryan Sleevi mailto:sle...@google.com> > Sent: Sunday, April 19, 2020 4:41 PM To: Tim Hollebeek mailto:tim.holleb...@digicert.com> >; CABforum1 mailto:public@cabforum.org> > Subject: Re: [cabfpub] Update about S/MIME Charter Looking through the resolved and unresolved aspects, the lack of feedback from you meant we still have one unaddressed matter in the draft: https://github.com/cabforum/documents/pull/167/files#r392389077 - The proposed draft charter forbids any CA from participating unless they already have particular audit schemes, despite this document not yet existing nor being incorporated into audit frameworks. This has been repeatedly raised as an issue for the past year, and it would be useful to know whether or not this is intentionally not being addressed. It does seem that there doesn't need to be restrictions on CA membership until such a document is produced (see also https://cabforum.org/pipermail/public/2020-March/014917.htm
Re: [cabfpub] Update about S/MIME Charter
I’m fine with this. Looks like Clint and Wayne are too (just repeating this here for those who don’t follow the link). -Tim From: Ryan Sleevi Sent: Wednesday, April 22, 2020 3:42 PM To: Tim Hollebeek Cc: CABforum1 Subject: Re: [cabfpub] Update about S/MIME Charter https://github.com/sleevi/cabforum-docs/pull/17 so that you can comment and make additional modifications/edits. In prepping this, I also spotted an issue with the CABF Bylaws that I'll feed back to Dimitris' ballot On Wed, Apr 22, 2020 at 3:27 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: I think some people might have objections to “includes, but not limited to…” language, but I don’t. I think it’s sometimes helpful when drafting intentionally broad criteria like this to make it explicitly clear that common cases like “WebTrust for CAs” or “ETSI …” is indeed “relevant to the issuance of S/MIME certificates”. That could really cut down on the amount of confusion about who does or does not qualify for membership, and give members clarity when voting for the charter about who is and isn’t allowed to participate, while also potentially allowing participation by others with less common audit schemes. That’s just a more verbose than usual way of me saying that yes, I would appreciate draft text along the lines you suggest. -Tim From: Ryan Sleevi mailto:sle...@google.com> > Sent: Wednesday, April 22, 2020 3:15 PM To: Tim Hollebeek mailto:tim.holleb...@digicert.com> > Cc: CABforum1 mailto:public@cabforum.org> > Subject: Re: [cabfpub] Update about S/MIME Charter See my earliest comments on the first draft about this - https://cabforum.org/pipermail/public/2019-January/014517.html shows the suggested edit and points to https://cabforum.org/pipermail/public/2019-January/014521.html Finally, regarding membership criteria, I'm curious whether it's necessary to consider WebTrust for CAs / ETSI at all. For work like this, would it make sense to merely specify the requirements for a CA as one that is trusted for and actively issues S/MIME certificates that are accepted by a Certificate Consumer. This seems to be widely inclusive and can be iterated upon if/when improved criteria are developed, if appropriate. There's also a bootstrapping issue for membership, in that until we know who the accepted Certificate Consumers are, no CA can join as a Certificate Issuer. I'm curious whether it makes sense to explicitly bootstrap this in the charter or how we'd like to tackle this. In the current incarnation, it's to simply remove the scheme requirement, as follows: A Certificate Issuer eligible for voting membership in the SMCWG MUST have a publicly-available audit report or attestation statement in accordance with a publicly-available audit or assessment scheme relevant to the issuance of S/MIME certificates. This includes, but is not limited to, ...: Happy to propose draft text to this effect, if this is something that you're open to addressing. On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: Unintentional, and thanks for calling it out. I don’t have strong feelings on the issue and agree broader participation is a useful goal, especially before requirements exist. Certificate Consumers can, and I expect will, have their own opinions on what audits are appropriate and necessary once they adopt the requirements. Do you have a proposed fix? -Tim From: Ryan Sleevi mailto:sle...@google.com> > Sent: Sunday, April 19, 2020 4:41 PM To: Tim Hollebeek mailto:tim.holleb...@digicert.com> >; CABforum1 mailto:public@cabforum.org> > Subject: Re: [cabfpub] Update about S/MIME Charter Looking through the resolved and unresolved aspects, the lack of feedback from you meant we still have one unaddressed matter in the draft: https://github.com/cabforum/documents/pull/167/files#r392389077 - The proposed draft charter forbids any CA from participating unless they already have particular audit schemes, despite this document not yet existing nor being incorporated into audit frameworks. This has been repeatedly raised as an issue for the past year, and it would be useful to know whether or not this is intentionally not being addressed. It does seem that there doesn't need to be restrictions on CA membership until such a document is produced (see also https://cabforum.org/pipermail/public/2020-March/014917.html ) smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Update about S/MIME Charter
https://github.com/sleevi/cabforum-docs/pull/17 so that you can comment and make additional modifications/edits. In prepping this, I also spotted an issue with the CABF Bylaws that I'll feed back to Dimitris' ballot On Wed, Apr 22, 2020 at 3:27 PM Tim Hollebeek wrote: > I think some people might have objections to “includes, but not limited > to…” language, but I don’t. I think it’s sometimes helpful when drafting > intentionally broad criteria like this to make it explicitly clear that > common cases like “WebTrust for CAs” or “ETSI …” is indeed “relevant to the > issuance of S/MIME certificates”. That could really cut down on the amount > of confusion about who does or does not qualify for membership, and give > members clarity when voting for the charter about who is and isn’t allowed > to participate, while also potentially allowing participation by others > with less common audit schemes. > > > > That’s just a more verbose than usual way of me saying that yes, I would > appreciate draft text along the lines you suggest. > > > > -Tim > > > > *From:* Ryan Sleevi > *Sent:* Wednesday, April 22, 2020 3:15 PM > *To:* Tim Hollebeek > *Cc:* CABforum1 > *Subject:* Re: [cabfpub] Update about S/MIME Charter > > > > See my earliest comments on the first draft about this - > https://cabforum.org/pipermail/public/2019-January/014517.html shows the > suggested edit and points to > https://cabforum.org/pipermail/public/2019-January/014521.html > > > > Finally, regarding membership criteria, I'm curious whether it's necessary > to consider WebTrust for CAs / ETSI at all. For work like this, would it > make sense to merely specify the requirements for a CA as one that is > trusted for and actively issues S/MIME certificates that are accepted by a > Certificate Consumer. This seems to be widely inclusive and can be iterated > upon if/when improved criteria are developed, if appropriate. > There's also a bootstrapping issue for membership, in that until we know > who the accepted Certificate Consumers are, no CA can join as a Certificate > Issuer. I'm curious whether it makes sense to explicitly bootstrap this in > the charter or how we'd like to tackle this. > > > > In the current incarnation, it's to simply remove the scheme requirement, > as follows: > > > > A Certificate Issuer eligible for voting membership in the SMCWG MUST have > a publicly-available audit report or attestation statement in accordance > with a publicly-available audit or assessment scheme relevant to the > issuance of S/MIME certificates. This includes, but is not limited to, ...: > > > > Happy to propose draft text to this effect, if this is something that > you're open to addressing. > > > > On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek > wrote: > > Unintentional, and thanks for calling it out. I don’t have strong > feelings on the issue and agree broader participation is a useful goal, > especially before requirements exist. Certificate Consumers can, and I > expect will, have their own opinions on what audits are appropriate and > necessary once they adopt the requirements. Do you have a proposed fix? > > > > -Tim > > > > *From:* Ryan Sleevi > *Sent:* Sunday, April 19, 2020 4:41 PM > *To:* Tim Hollebeek ; CABforum1 < > public@cabforum.org> > *Subject:* Re: [cabfpub] Update about S/MIME Charter > > > > Looking through the resolved and unresolved aspects, the lack of feedback > from you meant we still have one unaddressed matter in the draft: > > > > https://github.com/cabforum/documents/pull/167/files#r392389077 > > - The proposed draft charter forbids any CA from participating unless they > already have particular audit schemes, despite this document not yet > existing nor being incorporated into audit frameworks. This has been > repeatedly raised as an issue for the past year, and it would be useful to > know whether or not this is intentionally not being addressed. It does seem > that there doesn't need to be restrictions on CA membership until such a > document is produced (see also > https://cabforum.org/pipermail/public/2020-March/014917.html ) > > > > > > ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Update about S/MIME Charter
I think some people might have objections to “includes, but not limited to…” language, but I don’t. I think it’s sometimes helpful when drafting intentionally broad criteria like this to make it explicitly clear that common cases like “WebTrust for CAs” or “ETSI …” is indeed “relevant to the issuance of S/MIME certificates”. That could really cut down on the amount of confusion about who does or does not qualify for membership, and give members clarity when voting for the charter about who is and isn’t allowed to participate, while also potentially allowing participation by others with less common audit schemes. That’s just a more verbose than usual way of me saying that yes, I would appreciate draft text along the lines you suggest. -Tim From: Ryan Sleevi Sent: Wednesday, April 22, 2020 3:15 PM To: Tim Hollebeek Cc: CABforum1 Subject: Re: [cabfpub] Update about S/MIME Charter See my earliest comments on the first draft about this - https://cabforum.org/pipermail/public/2019-January/014517.html shows the suggested edit and points to https://cabforum.org/pipermail/public/2019-January/014521.html Finally, regarding membership criteria, I'm curious whether it's necessary to consider WebTrust for CAs / ETSI at all. For work like this, would it make sense to merely specify the requirements for a CA as one that is trusted for and actively issues S/MIME certificates that are accepted by a Certificate Consumer. This seems to be widely inclusive and can be iterated upon if/when improved criteria are developed, if appropriate. There's also a bootstrapping issue for membership, in that until we know who the accepted Certificate Consumers are, no CA can join as a Certificate Issuer. I'm curious whether it makes sense to explicitly bootstrap this in the charter or how we'd like to tackle this. In the current incarnation, it's to simply remove the scheme requirement, as follows: A Certificate Issuer eligible for voting membership in the SMCWG MUST have a publicly-available audit report or attestation statement in accordance with a publicly-available audit or assessment scheme relevant to the issuance of S/MIME certificates. This includes, but is not limited to, ...: Happy to propose draft text to this effect, if this is something that you're open to addressing. On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote: Unintentional, and thanks for calling it out. I don’t have strong feelings on the issue and agree broader participation is a useful goal, especially before requirements exist. Certificate Consumers can, and I expect will, have their own opinions on what audits are appropriate and necessary once they adopt the requirements. Do you have a proposed fix? -Tim From: Ryan Sleevi mailto:sle...@google.com> > Sent: Sunday, April 19, 2020 4:41 PM To: Tim Hollebeek mailto:tim.holleb...@digicert.com> >; CABforum1 mailto:public@cabforum.org> > Subject: Re: [cabfpub] Update about S/MIME Charter Looking through the resolved and unresolved aspects, the lack of feedback from you meant we still have one unaddressed matter in the draft: https://github.com/cabforum/documents/pull/167/files#r392389077 - The proposed draft charter forbids any CA from participating unless they already have particular audit schemes, despite this document not yet existing nor being incorporated into audit frameworks. This has been repeatedly raised as an issue for the past year, and it would be useful to know whether or not this is intentionally not being addressed. It does seem that there doesn't need to be restrictions on CA membership until such a document is produced (see also https://cabforum.org/pipermail/public/2020-March/014917.html ) smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Update about S/MIME Charter
See my earliest comments on the first draft about this - https://cabforum.org/pipermail/public/2019-January/014517.html shows the suggested edit and points to https://cabforum.org/pipermail/public/2019-January/014521.html Finally, regarding membership criteria, I'm curious whether it's necessary > to consider WebTrust for CAs / ETSI at all. For work like this, would it > make sense to merely specify the requirements for a CA as one that is > trusted for and actively issues S/MIME certificates that are accepted by a > Certificate Consumer. This seems to be widely inclusive and can be iterated > upon if/when improved criteria are developed, if appropriate. > There's also a bootstrapping issue for membership, in that until we know > who the accepted Certificate Consumers are, no CA can join as a Certificate > Issuer. I'm curious whether it makes sense to explicitly bootstrap this in > the charter or how we'd like to tackle this. In the current incarnation, it's to simply remove the scheme requirement, as follows: A Certificate Issuer eligible for voting membership in the SMCWG MUST have a publicly-available audit report or attestation statement in accordance with a publicly-available audit or assessment scheme relevant to the issuance of S/MIME certificates. This includes, but is not limited to, ...: Happy to propose draft text to this effect, if this is something that you're open to addressing. On Wed, Apr 22, 2020 at 3:03 PM Tim Hollebeek wrote: > Unintentional, and thanks for calling it out. I don’t have strong > feelings on the issue and agree broader participation is a useful goal, > especially before requirements exist. Certificate Consumers can, and I > expect will, have their own opinions on what audits are appropriate and > necessary once they adopt the requirements. Do you have a proposed fix? > > > > -Tim > > > > *From:* Ryan Sleevi > *Sent:* Sunday, April 19, 2020 4:41 PM > *To:* Tim Hollebeek ; CABforum1 < > public@cabforum.org> > *Subject:* Re: [cabfpub] Update about S/MIME Charter > > > > Looking through the resolved and unresolved aspects, the lack of feedback > from you meant we still have one unaddressed matter in the draft: > > > > https://github.com/cabforum/documents/pull/167/files#r392389077 > > - The proposed draft charter forbids any CA from participating unless they > already have particular audit schemes, despite this document not yet > existing nor being incorporated into audit frameworks. This has been > repeatedly raised as an issue for the past year, and it would be useful to > know whether or not this is intentionally not being addressed. It does seem > that there doesn't need to be restrictions on CA membership until such a > document is produced (see also > https://cabforum.org/pipermail/public/2020-March/014917.html ) > > > > > ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Update about S/MIME Charter
Unintentional, and thanks for calling it out. I don’t have strong feelings on the issue and agree broader participation is a useful goal, especially before requirements exist. Certificate Consumers can, and I expect will, have their own opinions on what audits are appropriate and necessary once they adopt the requirements. Do you have a proposed fix? -Tim From: Ryan Sleevi Sent: Sunday, April 19, 2020 4:41 PM To: Tim Hollebeek ; CABforum1 Subject: Re: [cabfpub] Update about S/MIME Charter Looking through the resolved and unresolved aspects, the lack of feedback from you meant we still have one unaddressed matter in the draft: https://github.com/cabforum/documents/pull/167/files#r392389077 - The proposed draft charter forbids any CA from participating unless they already have particular audit schemes, despite this document not yet existing nor being incorporated into audit frameworks. This has been repeatedly raised as an issue for the past year, and it would be useful to know whether or not this is intentionally not being addressed. It does seem that there doesn't need to be restrictions on CA membership until such a document is produced (see also https://cabforum.org/pipermail/public/2020-March/014917.html ) smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Update about S/MIME Charter
Looking through the resolved and unresolved aspects, the lack of feedback from you meant we still have one unaddressed matter in the draft: https://github.com/cabforum/documents/pull/167/files#r392389077 - The proposed draft charter forbids any CA from participating unless they already have particular audit schemes, despite this document not yet existing nor being incorporated into audit frameworks. This has been repeatedly raised as an issue for the past year, and it would be useful to know whether or not this is intentionally not being addressed. It does seem that there doesn't need to be restrictions on CA membership until such a document is produced (see also https://cabforum.org/pipermail/public/2020-March/014917.html ) ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Update about S/MIME Charter
On Fri, Apr 17, 2020 at 7:57 PM Tim Hollebeek via Public < public@cabforum.org> wrote: > > > As I mentioned on the last call, I promised to give an update on the > S/MIME Charter today. There was a previous draft incorporating Apple’s > comments, but as that draft was being finalized, a number of useful > improvements were contributed by Google. After some discussion, most of > those improvements were adopted, resulting in a proposal from Apple which > can be found here: > Hi Tim, The correct link is https://github.com/cabforum/documents/pull/167 . The e-mails I sent (as well as the GitHub notifications) were trying to address this by avoiding a bunch of fragmented URLs. Hopefully that makes it easier to see the edits, as well as make sure that the comments are actually addressed by allowing them to be resolved :) ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Update about S/MIME Charter
And, I forgot one other important point that I wanted to call out. Microsoft commented on earlier drafts of the charter in the previous ballot, and one of their concerns was that S/MIME emails sent from automated systems and mailing lists that contain identity information could potentially be construed as out of scope. That led to language in the previous ballot explicitly including such emails in the scope. That language was discussed, and the consensus was that those emails remain in scope, even without the additional language, and therefore the additional language is unnecessary (and potentially harmful). So it was removed. It would be useful to know if Microsoft agrees with that interpretation, otherwise we are going to have to find another solution to that issue. -Tim From: Public On Behalf Of Tim Hollebeek via Public Sent: Friday, April 17, 2020 7:57 PM To: CABforum1 Subject: [cabfpub] Update about S/MIME Charter As I mentioned on the last call, I promised to give an update on the S/MIME Charter today. There was a previous draft incorporating Apple's comments, but as that draft was being finalized, a number of useful improvements were contributed by Google. After some discussion, most of those improvements were adopted, resulting in a proposal from Apple which can be found here: https://github.com/clintwilson/cab-docs/blob/SMCWG-draft-feedback/docs/SMCWG -charter.md Apple, DigiCert, and Mozilla support this proposal. If we're reading Ryan's github comments correctly, it seems he also supports this version of the charter, though I will let him speak for himself on that topic. It would be useful if people began reviewing this charter proposal, and if there are additional comments, hopefully we can get them resolved soon. We should also discuss ballot language and a potential path forward towards getting this adopted, and I agree with Ryan that it would be more useful if that discussion happened on the public list (or github). DigiCert would vote for the current charter as proposed by Apple, but there is one point that I did notice while reviewing it one last time, and it relates to the following provision: "Certificates issued under a root certificate that is not publicly trusted SHALL be out of scope." I have two comments: 1. The concept of "root certificate" is clear in most circumstances, but in messy PKIs that involve cross signing and other complicated trust relationships, it can get a bit fuzzy. And the S/MIME ecosystem is certainly very messy right now. One potential fix is to change it to "Root Certificate", so it refers to the defined term in the Baseline Requirements. But then everyone has to agree that that's what we mean, and not something else. 2. Second, related to the first point, "publicly trusted" can be a bit ambiguous, especially with respect to a new working group like S/MIME, where we do not know in advance who the Certificate Consumers will be. Language along the lines of "that is not trusted by any participating Certificate Consumer" would probably be more clear. And what does trusted mean? What if it chains to a trusted ICA, but that ICA has been blacklisted by all Certificate Consumers via their revocation mechanisms? It would be useful to definitively say what we mean up front, to avoid differences of interpretation later. Additional clarity and precision in expressing this requirement would probably be helpful, and I'd welcome discussion and suggestions. Or we could just go with the current language, acknowledging its potential limitations. -Tim smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
[cabfpub] Update about S/MIME Charter
As I mentioned on the last call, I promised to give an update on the S/MIME Charter today. There was a previous draft incorporating Apple's comments, but as that draft was being finalized, a number of useful improvements were contributed by Google. After some discussion, most of those improvements were adopted, resulting in a proposal from Apple which can be found here: https://github.com/clintwilson/cab-docs/blob/SMCWG-draft-feedback/docs/SMCWG -charter.md Apple, DigiCert, and Mozilla support this proposal. If we're reading Ryan's github comments correctly, it seems he also supports this version of the charter, though I will let him speak for himself on that topic. It would be useful if people began reviewing this charter proposal, and if there are additional comments, hopefully we can get them resolved soon. We should also discuss ballot language and a potential path forward towards getting this adopted, and I agree with Ryan that it would be more useful if that discussion happened on the public list (or github). DigiCert would vote for the current charter as proposed by Apple, but there is one point that I did notice while reviewing it one last time, and it relates to the following provision: "Certificates issued under a root certificate that is not publicly trusted SHALL be out of scope." I have two comments: 1. The concept of "root certificate" is clear in most circumstances, but in messy PKIs that involve cross signing and other complicated trust relationships, it can get a bit fuzzy. And the S/MIME ecosystem is certainly very messy right now. One potential fix is to change it to "Root Certificate", so it refers to the defined term in the Baseline Requirements. But then everyone has to agree that that's what we mean, and not something else. 2. Second, related to the first point, "publicly trusted" can be a bit ambiguous, especially with respect to a new working group like S/MIME, where we do not know in advance who the Certificate Consumers will be. Language along the lines of "that is not trusted by any participating Certificate Consumer" would probably be more clear. And what does trusted mean? What if it chains to a trusted ICA, but that ICA has been blacklisted by all Certificate Consumers via their revocation mechanisms? It would be useful to definitively say what we mean up front, to avoid differences of interpretation later. Additional clarity and precision in expressing this requirement would probably be helpful, and I'd welcome discussion and suggestions. Or we could just go with the current language, acknowledging its potential limitations. -Tim smime.p7s Description: S/MIME cryptographic signature ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
