On 01/11/16 02:18, Ryan Sleevi wrote: > On Monday, October 31, 2016, Stephen Farrell <[email protected]> > wrote: > >> >> Hiya, >> >> "Are" or "could be"? >> >> Serious question. The (non)existence of those in 6962 logs >> seems to me to be a) highly pertinent and b) demonstrable. > > > Isn't that an element of log policies
No, that's an empirical question, to rephrase it: Show me the
certs:-)
Really, it is a serious question when considering the difference
between corporate secrecy and privacy. I totally accept that there
are issues with the former (e.g. with <newproduct>.example.com)
but I'd like to see evidence if someone claims that the latter
is an issue. ("The latter" being the privacy of humans, not the
secrecy of organisations.)
> - and what clients are logging? These
> certs definitely exist - but the combination of client behavior and log
> policies have, so far, prevented them from being logged, and only
> incidentally so.
I don't follow that, can you elaborate?
>
>
>>
>>> certificates that have personal information (e.g. given
>>> name, surname, and physical location) in the subject distinguished
>>> name or the subject alternative names.
>>
>> I can well imagine certs for web servers with some PII
>> embedded for no good reason. "Don't do that by accident"
>> would be as good a bit of advice as we could offer in
>> CT I think as it's really much more an issue for acme
>> in terms of current IETF work. (Or at least arguably.)
>>
>>
> I fail to see how ACME relates. This is a question of PKI: does TRANS exist
> solely for elements of browser-mediated Web PKI, or is it for more?
The WG charter calls out web site cert misissuance as thing#1
and http/tls as the same (in the deliverable bit).
Acme relates as follows: if there are certs containing PII,
instead of trying to handle those via redaction during the
act of CT logging, one could recommend not including the PII
in the certs. (It is arguable that that is a sufficient
answer, but nonetheless it could be argued to be one, in the
context of the IETF.)
> In
> either case, they extend beyond issuance via ACME, and speak to policy, so
> I don't feel we can be so easily dismissive.
>
I was not dismissive. I asked for evidence. I did not
use the word policy at all.
>
>>> It is very possible that there
>>> may be a desire to redact this information (in fact it could even be
>>> required in some jurisdictions as CT could be considered a database).
>>
>> The above has "possible," "may be a desire," "could even
>> be" and "could be considered" all in one sentence. That
>> is not a template for a winning argument is it? :-)
>
>
> Are you suggesting these cases are not valid?
No. I'm claiming that his argument is unconvincing. I'm
very very happy to continue to pick at that one sentence
if it helps the overall argument, but I doubt that it
will;-)
I said more than once in my mail that corporate secrecy
can be a valid requirement to posit. Feel free to ignore
that as often as you wish.
> Because Peter is far from the
> only one to bring them forward, as we've heard it in the past in relation
> to ETSI profiles and the EU Trust List from a number of CAs. Are you
> suggesting this isn't the venue to discuss technical solutions, as it
> relates to CT, to those problems?
That last is not great rhetoric. Do you really expect me
to say "yes, this is not the place to talk technical
solutions"? Hrmpf;-)
ETSI profiles and EU trust lists are all fine and good
things (in theory at least). I do regard a lot of argument
about those are purely theoretic having seen 20+ years of
such theory not resolving into reality.
And again I did more than once ack that corporate secrecy
is a valid requirement to posit in some forms.
>
>
>
>>> We already see this with domains in many countries where the full
>>> registrant details are not publicly available.
>>
>> DNS registration policies are not in scope here though.
>
>
> Are you suggesting that CT does not need to be aware of what is possible,
> either through other WGs actions (such as NSEC/NSEC3) or through other
> bodies, such as IANA/ICANN?
I've no clue what the above means, sorry.
Guessing though, as to what might constitute an answer: I do
not think that CT needs to try to address problematic things
like ICANN registrar policies that call for PII to be generally
visible. To the extent one has a problem with that, (and I do
as it happens) the trans WG is the wrong venue, was my point.
>
> It so, can you articulate what you view as the appropriate scope of
> function and discussion here? I mean that as an honest question.
As with the above, I'm too confused to answer. (And figure
there's some underlying miscommunication going on here.)
>
>
>>> For example a certificate that is used with email
>>> and contains both the email address and given/surname. It might be
>>> that the owner of the certificate only wishes to disclose this binding
>>> to people receiving email from them rather than publicly disclosing
>>> it. We have also seen requests for certificates that cover phone
>>> numbers. A similar situation would apply -- having an "unlisted"
>>> number should be possible, where the subject details (other than phone
>>> number) are only known to a group of people who communicate with the
>>> number.
>>
>> Again, please show us evidence from the public logs.
>
>
> I am sorry, but I find this argument going against the seeming IETF
> principles of not favoring a particular vendors policies.
Huh? Asking for evidence of the existence of a claimed problem
goes against what? I'm very confused tbh.
>
> What is a public log, in your view? What policies do you believe logs must
> have for acceptance? How do you respond, given that some CAs and log
> operators have explicitly stated they want to log email and code signing
> certificates? Concretely, WoSign is such an example of a CA doing that.
>
> It seems the core of your objections are simply "Chromium policies have
> prevented this" -
Eh, no. That's entirely and utterly incorrect to the point
where I wonder if you got mixed up by the indenting in the
mail thread or something. (Or perhaps you are reading between
the lines and finding things that are not really there, at
least between the lines as I write 'em;-)
> but as the person responsible for those policies, I don't
> find that argument particularly compelling or convincing, and certainly not
> in line with the feedback we've received at Google, nor necessarily how I
> think Chrome would like to see CT grow.
>
> Perhaps it's easier to just ask - do you view CT as only valid for a
> limited subset of Internet-facing, "publicly trusted," id-kp-serverAuth EKU
> bearing certificates? If so, could we see if there's consensus with that
> view? Because at present, the tech neither requires nor states that, and
> perhaps that's core to determining whether your dichotomy of privacy and
> confidentiality is accurate and reflected in both the tech and the running
> code.
I remain as confused as I was a minute ago;-)
S.
>
>
>
> _______________________________________________
> Trans mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/trans
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
