퀴즈: 멀쩡한 인증서가 거절당했다

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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