automated trigger from the RA
that causes certification; rather it seems to be a delegation of certain
duties. The whole thing is specified here:
https://www.pki.dfn.de/fileadmin/PKI/Konzept_DFN-PKI.pdf
Ralph
--
Ralph Holz
I8 - Network Architectures and Services
Technische Universität Mün
> Yes. SHA1 is next. There used to be some hesitation to switch to SHA1
Apply s/1/2/ on the last word, please.
Ralph
--
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E
ended with a few more
algorithms to check logged certs for other things -- compliance with BR
or EV comes to mind.
As for auditors, I am wondering if anyone is working on a FF or Chrome
add-on that tests consistency of a log. I appreciate it's not a prime
priority.
Ralph
--
Ralph Holz
I8 - Ne
ect host). I think
active scans are still worthwhile to collect such information.
Ralph
--
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E
rs, etc. Thus the
grace period until 2011.
In the meantime, all you can do is blacklist known-rogue certs.
Alternatively, pull the root cert from which MD5 signatures were issued.
As the MD5 attack still had considerable cost (for the hobby blackhat,
not a 3-letter agency), it was deemed that this mu
ash algorithm means root cert-like compromise as it
means the capacity to imitate a correct signature by a root cert. There
is no fix for this but blacklisting. Not in any model with TTPs, by the way.
Ralph
--
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://w
browsers. Furthermore,
Mozilla does not accept any non-root certs with MD5 signatures since
mid-2011.
Ralph
--
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4 86
not the RAs themselves. In the case of DFN, the
intermediate certs only identify the RAs. The RAs do not carry signing
power.
It is the same at TUM, where I work, BTW.
Ralph
--
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbe
CA, sub-* or not. The important point is where the
private key is kept.
In the case of the DFN, the 'many subCAs' are actually RAs without
signing capacity. I'd be much more worried about some resellers of the
very popular CAs. Anyone remember Comodo's InstantSSL reseller?
Ralph
bout is whether the work can be taken
further at some point to include that mechanism from Sovereign Keys that
allows to give, say, an alternate Tor routing (or hidden service), for a
given domain, in order to avoid censorship. I'd agree that's not a
primary topic for CT, but a worthwhile goal
changes notbefore/notafter but re-issues cert in same
way. With AKID the same, the end-host cert would not need to be
re-issued, but you still want the proof of exactly that one
certification with that one intermediate cert.
Ralph--
Ralph Holz
Network Architectures and Services
Technische Univer
diate CA that has a
different DN (and maybe key identifier), you'd get a different DER/PEM
and a different hash already.
Or maybe I'm confused. :)
Ralph
--
Ralph Holz
Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
PG
and CT are providing.
I thought you were referring to technical issues, like numbers of
trusted TTPs = CAs. I don't think your argument applies there.
Ralph
--
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.
at less TTPs in X.509 is a good idea.
Of course, if you're arguing you actually want to move away from X.509
and towards, say, SK, the story may be different.
Ralph
--
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/d
t;, and
work flows are chains.
Ralph
PS: My problem with the word "architecture" is that today it's mostly
used in publications when the authors just mean "something we thought up
for our little problem". It's used so often it's almost meaningless.
--
Dipl.-Infor
Hi,
The list sounds about right. CA transparency and Sovereign Keys have a
lot in common. One thing that I was wondering is why Sovereign Keys does
not use Merkle hash chains; my guess so far was performance.
And there's some partially-connected things in the works:
- Key Pinning in HTTP
and some of the issues are likely not properly
addressed yet. So let's start it.
Also, I'd like to see how a real implementation fares - and I'd be
willing to set up a first timeline server here at TUM.
Ralph
--
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Techni
17 matches
Mail list logo
