My understanding is that the QuickInvite system doesn't distinguish the
reseller from their customer in terms of access to the order.
It's not very clear from Symantec's documentation, and Tarah never got back to
me in the thread about it, but I think a reseller absolutely can wait for their
On Mon, Apr 10, 2017 at 02:57:41PM +, Steve Medin via dev-security-policy
wrote:
> In April 2015, security consultant Chris Byrne responsibly disclosed two
> potential vulnerabilities related to our Quick Invite feature, which
> enables a reseller to invite pre-selected customers to enroll
On Monday, 10 April 2017 20:28:53 UTC+1, michael...@gmail.com wrote:
> A couple points of clarification please:
>
> 1) Mr. Byrne clarified his post to note that the flaws in the Symantec API
> would allow: retrieval of certificates that included private keys, not the
> private keys alone. Was
A couple points of clarification please:
1) Mr. Byrne clarified his post to note that the flaws in the Symantec API
would allow: retrieval of certificates that included private keys, not the
private keys alone. Was this possible?
2) You say, "it's not technically feasible", which implies
Hi Steve,
Tiny nit-picky follow up question. You said: "it's technically not
feasible. This is because Symantec does not have access to our customers'
TLS server private keys.".
X.509 certificates can of course be used for things besides TLS, when you
say "TLS server private keys", is that
Issue R: Insecure Issuance API (2013 or earlier - November 2016)
In April 2015, security consultant Chris Byrne responsibly disclosed two
potential vulnerabilities related to our Quick Invite feature, which enables a
reseller to invite pre-selected customers to enroll for certificates, via
6 matches
Mail list logo
