Hi, >> I was there at IMC and spoke with Zakir. He was not aware of the fact >> that the private keys to all the intermediate certificates are held by >> the central DFN Verein, not the RAs themselves. In the case of DFN, the >> intermediate certs only identify the RAs. The RAs do not carry signing >> power. > > What is the function of an RA, then, if not to tell a CA "sign this"?
I'll add the following in addition to what Jeremy said: the term RA is used with different meanings by CAs. E.g. during the Comodo incident in 2011 (the one by Comodohacker), it became clear that the RA had access credentials stored that allowed it to trigger certification by the CA. This was really what others might call a reseller or possibly a subordinate CA. In the case of DFN, it is different. The RAs are 1) identifiers in intermediate certs and 2) carry out paperwork. I request a server cert by creating a CSR in DFN's online interface, but I send a paper form to the local RA who will then contact me to verify that I am indeed a TUM employee with control over the server (and in case of S/MIME, see my passport). There does not seem to be an 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ünchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
