测验：好好的证书被拒绝了

방금 발급된 인증서에 대해 「아직 유효하지 않음」 오류를 내는 기계의 시계는 어떤 상태인가?

• 다른 기계들보다 뒤처져 있어 notBefore 가 아직 미래로 보인다
• 다른 기계들보다 앞서 있어 notAfter 를 이미 지난 것으로 본다
• 시계와 무관하며 인증서 체인이 완성되지 않은 것이다
• 시간대 설정이 UTC 가 아니어서 오프셋만큼 어긋나 보이는 것이다

수명 300초짜리 토큰을 시계가 277초 앞선 기계가 검증할 때, 그 토큰을 실제로 쓸 수 있는 시간은?

• 발급 직후부터 300초 동안 그대로 쓸 수 있다
• 발급 직후부터 23초 동안만 쓸 수 있다
• 발급 후 277초가 지나야 비로소 쓸 수 있게 된다
• 오차가 수명보다 작으므로 영향이 없다

RFC 7519 가 exp 와 nbf 처리에 대해 함께 적어 둔 것은?

• 두 클레임 중 하나는 반드시 있어야 하며 없으면 토큰을 거절해야 한다
• 두 클레임의 값은 반드시 UTC 기준 문자열로 적어야 한다
• 구현자는 시계 오차를 감안해 보통 몇 분을 넘지 않는 약간의 여유를 둘 수 있다
• 검증하는 쪽은 발급자의 시계로 환산한 뒤에 비교해야 한다

인증서 자동 갱신을 만료 직전이 아니라 여유를 크게 두고 미리 도는 이유는?

• 발급 기관의 속도 제한에 걸리지 않기 위해서다
• 시계 오차가 몇 분 있어도 유효 구간의 양쪽 끝 어디에도 걸리지 않게 하기 위해서다
• 갱신 실패 시 이전 인증서를 되돌릴 시간을 벌기 위해서다
• 인증서 투명성 로그에 등재되는 지연을 흡수하기 위해서다

캐시 만료를 절대 시각이 아니라 남은 초로 주는 편이 나은 이유는?

• 절대 시각은 형식이 여러 가지라 파싱 오류가 잦기 때문이다
• 남은 초로 주면 중간 프록시가 값을 고치지 못하기 때문이다
• 남은 초는 헤더 크기가 작아 전송량이 줄기 때문이다
• 받는 쪽이 자기 단조 시계로 세므로 시계 오차의 영향을 받지 않기 때문이다

토큰 검증의 여유(leeway)를 크게 늘리는 대책에 따르는 대가는?

• 만료된 토큰을 그 여유만큼 더 받아 주게 되어 재발급 기반의 취소가 늦게 듣는다
• 검증 비용이 늘어 인증 경로의 지연이 눈에 띄게 커진다
• 발급하는 쪽도 같은 여유를 알아야 해서 양쪽 배포를 맞춰야 한다
• 토큰 크기가 커져 헤더 길이 제한에 걸릴 수 있다