Hi Stephen.
Last month Ben posted this:
"Emilia Kasper and I came up with a mechanism for providing revocation
transparency. We currently have no plans to implement it, but the
mechanism is interesting.
Blog post here: http://www.links.org/?p=1272
Paper here: http://sump2.links.org/files/RevocationTransparency.pdf";
And in his draft charter he wrote:
"Optionally, do the same for certificate revocations."
CT will only be effective if:
1. "browsers will refuse non-CTed certs" (to quote Ben).
2. Effective revocation mechanisms exist, so that dodgy certs brought to
light by CT can be effectively dealt with.
I think RT would definitely be a good project for a Transparency WG to
take on after CT.
I don't have a strong opinion about this, but I think it might make
sense to split up the CT standardization effort into multiple documents,
because different audiences will be interested in different aspects of
CT. i.e.
- One document aimed at the people who will implement and/or operate
CT log servers.
- One document aimed at CAs who will implement pre-certs and/or embed
proofs into OCSP Responses.
- One document aimed at browser authors who will write code to verify
proofs.
- One document aimed at webserver authors who will need to understand
the importance of implementing RFC5878 and/or OCSP Stapling (RFC6066).
- One document aimed at auditors who will need to know how to verify
that a CT log has not been compromised.
- One document aimed at domain owners who will need to know i) how to
discover if any certs have been misissued to their domain names and ii)
what to do about any detected misissuances.
Given the imminent closure of the PKIX WG, I'm tempted to also suggest...
- One document that will define requirements for "Effective
revocation mechanisms".
On 26/10/12 17:16, Stephen Farrell wrote:
Hiya,
I know we're not having a wg-forming BoF but there's a
thing I think I'd like to see discussed at or before
the BoF that'd normally be part of a wg-forming BoF but
is still worth doing now. (Discussing this on the list
since we've all read the draft is even better of
course:-)
Assuming for the moment that we do go ahead and
standardise CT, how many documents (RFCs) ought be
used to document that?
If the answer turns out to be one, then it might be more
efficient to process CT as an AD sponsored draft, so if
your answer to the above is 1, then I'd like input about
doing that or not doing that.
If the answer is more than one, then what might those
be, and are there dependencies on other IETF WGs or
external groups? Clearly, if the answer is more than
one non-wg draft, that means that AD sponsoring is
less likely and a WG is likely needed. If you think
this is the case, it'd be good to see your suggestion
for what RFCs ought be produced.
I guess I'm sort of asking for suggestions as to what
milestones a WG might adopt if we were to form one.
I do realise that this is only part of the discussion
that we need to have, and is contingent on us wanting
to do something with CT, but I've not seen it raised
so far, so thought I'd kick that off.
If you're not sure about the process parts of the
above (e.g. "AD sponsored") please just ask. Paul
or I can answer that.
Thanks,
S.
PS: Its ok to give your answer to this even if you
think that CT should not be standardised in the IETF.
If that's the case maybe say so if you want.
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
